Your Lovable App Is Built. Production Lives Below the Waterline, in Supabase

A Lovable app running on Supabase is closer to production than most engineers who review it will admit, and further from it than the founder who built it believes. Both mistakes cost money. The first one buys a rewrite nobody needed. The second one ships a database that answers anyone who asks.

I write this from the seat that inherits these codebases. I spent years in enterprise DevOps and incident response before Conectia, and today our engineers take over AI-built products and harden them for real users. The pattern I see with Lovable is consistent enough to write down: the screens are fine, the schema is usually reasonable, and almost everything that carries risk sits in one layer the founder has never looked at.

In a Supabase app, the row-level security policy is the backend. Once you understand why, the rest of the audit falls into order.

The browser talks straight to Postgres, and that is the whole design

A typical Lovable app is a React front end that calls Supabase directly with a public key. There is no API server in between written by you. Supabase exposes your tables over HTTP, and the only thing deciding which rows a given request can read or write is the set of Postgres policies on each table.

That design is not a flaw: it is why a founder can ship a working product in a weekend, and it holds up at scale when the policies are right. Supabase's own docs are blunt about the condition: tables without RLS and sensible policies let any client access and modify their data. Lovable's documentation says the same thing from the other side: «Missing RLS policies are the most common way app data gets exposed».

This has already happened at scale. In May 2025 a researcher scanned 1,645 apps from Lovable's public showcase and found 170 of them with tables readable or writable using nothing but the public key. It was logged as CVE-2025-48757. Lovable has since added automatic security scans on publish, and its own security page says what any honest vendor would: these tools «do not replace a thorough security review».

I covered what breaks in AI-built MVPs in general in an earlier post. Lovable on Supabase fails in specific enough ways to deserve its own list.

Before any fix, find out what you actually own

The first audit question is not technical: where does this thing live, and who holds the keys?

• Lovable Cloud or your own Supabase project? Since Lovable made Cloud its default backend, many founders have never opened a Supabase dashboard. Lovable's docs suggest connecting your own Supabase project if you want «direct ownership, your own billing, or full access to the Supabase dashboard». On Cloud, the region is fixed once enabled and there is no one-click migration to your own Supabase project. Decide early, before the data grows.
• The repository. Connect GitHub and move the repo into a company organisation, not the founder's personal account. Lovable syncs both ways, but only one branch at a time. Once engineers commit to the same repo, decide who owns main. If branch protection rejects a Lovable push, it lands on a lovable-sync branch for someone to merge: correct behaviour, and a surprise the first time.
• What Git does not carry. The repo holds the code and the migration files; data and uploaded files are exported separately. Your backup strategy cannot be «it's on GitHub».
• Who can log in. MFA on GitHub and on the Supabase organisation, more than one owner, and a list of everyone with dashboard access. The Supabase production checklist asks for exactly this, and it takes twenty minutes.

Where the policies break, in the order I find them

The problems repeat from one Lovable database to the next. None is exotic, and each is an hour or two of senior work once found.

1. Tables with RLS disabled. Usually a table added late, or created by hand in the SQL editor. Supabase's Security Advisor flags them; run it first.
2. RLS enabled and wide open. A policy that says «any authenticated user can read everything» passes the scanner's «RLS is on» check and still leaks every row to every customer who signs up.
3. Multi-tenant isolation by convention. The app filters by organization_id in the front end, while the policy only checks that the user is logged in. The correct shape is a membership table and a policy that derives the tenant from auth.uid(), never from a value the client sends.
4. Policies that trust user_metadata. Users can edit their own metadata, and Supabase warns explicitly against authorising on it. Roles belong in app_metadata or in your own tables.
5. Views and functions that bypass RLS. Views created by the postgres user ignore policies unless they set security_invoker = true. A security definer function exposed over RPC runs with its owner's rights. Both are legitimate tools, and both are holes when nobody chose them on purpose.
6. Public storage buckets. Invoices and ID documents in a public bucket are a URL away from anyone. Storage has its own policies on storage.objects; audit them like tables.
7. Policies that are correct and slow. An unindexed column in a policy turns every read into a sequential scan, and calling auth.uid() without wrapping it in a select evaluates it per row. Invisible with fifty users; a support ticket with fifty thousand.

Keys, edge functions and the limits nobody mentions at launch

The secret key bypasses RLS. Supabase now separates a publishable key, safe in the browser, from a secret key that «bypasses Row Level Security, so it must never leave your control». Search the built bundle for service_role and sb_secret_. And note the date: Supabase is deprecating the legacy anon and service_role keys by the end of 2026, so an app still shipping them has a migration due regardless of anything else in this post.

Every edge function is an authorization boundary. Lovable writes edge functions for anything that needs a secret: payments, emails, LLM calls. Lovable stores the keys as Supabase secrets, out of the repository, and that part is done well. The gap is inside the function: it often runs with elevated rights and trusts the payload. Each one should verify the caller's JWT and check that this user may do this thing before it touches the secret key.

Edge functions have hard limits: 2 seconds of CPU per request, 256 MB of memory, and 150 or 400 seconds of wall clock depending on plan. A PDF export, a long LLM chain or a nightly import does not belong there; it belongs in a worker with a queue.

Rate limits protect Supabase Auth, not your functions. Auth endpoints ship with sensible per-IP limits. An edge function that calls a paid model API has none until you write them, which makes it a billing endpoint open to anyone with a session. Then there is the one that breaks launch day: without custom SMTP, Supabase's built-in email sender is capped at two emails per hour. It exists for testing. Configure your own SMTP before the first campaign, or sign-up confirmations stop arriving at the worst possible hour.

Migrations, environments and backups: the plumbing a demo never needs

Lovable writes schema changes as reviewed migrations under supabase/migrations/, which is better than most hand-built MVPs I have audited. The drift comes from everything done outside Lovable: a column added in the dashboard, a policy edited by hand at midnight. The fix is a baseline: diff the live schema against the migration folder with the Supabase CLI, commit the difference, and from then on change the schema only through migrations.

Then environments. One project serving development and production is the norm in these apps, and it is how a test script ends up deleting real rows. Supabase branching gives you a preview database per pull request and persistent branches for staging, and its GitHub integration applies migrations to production on merge. Add CI that type-checks, runs the tests, and runs policy tests against a branch database, because a policy without a test is a policy someone will loosen by accident.

Backups decide how bad your worst day is. On the free plan there are no downloadable backups and the project can be paused after a week of inactivity. Paid plans keep daily backups (seven days on Pro), and point-in-time recovery brings the worst case down to about two minutes of lost data. Restore once into a branch before you need to. An untested backup is a hope.

Last, observability and cost: error tracking on the front end, a request ID in every edge function log, pg_stat_statements for slow queries, and a daily ceiling on anything that calls a model. At scale the bill rarely comes from the database itself; it comes from undersized compute, storage egress and functions nobody rate-limited.

When to keep Supabase, and when to move the backend

Someone, often your first senior hire, will propose rewriting the backend «properly». I have seen that advice burn a quarter of runway more than once. The honest answer to it: Supabase is Postgres, and Postgres is not the part that fails. Keep Supabase when the product is mostly data with permissions, the policies can be written and tested, and auth fits your users. That describes most Lovable apps I have seen.

Move business logic to a service — Python or Node, the stacks we run — when the domain stops fitting in policies: multi-step transactions across many tables, long-running jobs beyond edge limits, heavy third-party integrations, or a compliance requirement that needs one auditable API in front of the data. Even then, you rarely leave Supabase. The database, auth and storage stay; the browser stops writing to the sensitive tables directly and calls your service instead, one path at a time. That is the same incremental approach I recommend for monolith versus microservices at the MVP stage: move the boundary where the risk is, not everything at once.

What I'd audit first, in this order

If your Lovable app were landing on my desk on Monday, this is the order. The order matters more than the list, because each step makes the next one safe.

1. Ownership, day one. Repo in a company GitHub organisation, Supabase project (or Lovable Cloud) inventoried, MFA everywhere, access list written down.
2. Exposure, days one and two. Security Advisor, then every table's RLS and policies, storage buckets, views, security definer functions, and a search of the bundle for secret keys. Rotate anything that was ever exposed.
3. Edge functions. JWT verification and authorization in each one, rate limits on anything that spends money, long jobs moved out.
4. Auth configuration. Custom SMTP, email confirmation on, short OTP expiry, redirect URLs restricted to your domains, CAPTCHA on sign-up.
5. Backups. Paid plan, PITR if the data matters, and one tested restore.
6. Migrations and environments. Baseline the schema, staging via branching, CI with policy tests on the paths that touch money or personal data.
7. Observability and cost ceilings. Error tracking, request IDs, slow-query review, a daily cap on model spend.
8. Then the backend decision, with evidence from the first seven steps rather than from taste.

A senior engineer who has done this before covers steps one to five in the first week or two. In the opposite order, features first and the perimeter later, the same work takes a quarter.

The hull is built. Check below the waterline before launch

Think of a ship on blocks in the yard: painted, fitted out, finished to anyone walking past. Nobody launches it before someone has inspected below the waterline. Lovable built your hull quickly and well, and it answered the hard question of whether anyone wants the product. What remains is the part no demo shows, done in a known order.

If you are weighing who should do it, I have compared the firms that take AI-built MVPs to production. Or, if that is the question in front of you now, this is the team we put on startup products: senior engineers vetted at a 3% acceptance rate, starting with a Blueprint week that audits what you have, sets the architecture and leaves a written plan you can execute with us or without us.