Lovable + Supabase in production: 12 things we fix before real users log in

A Lovable app talks to its database straight from the browser, using a public key that ships with the page. That is how Supabase is designed. The safety comes from Row Level Security: rules in the database that decide, row by row, who can read and write. Supabase's docs put it plainly: enable RLS on every table in an exposed schema (Supabase docs).

When those rules are missing or too loose, the public key opens the table. In March 2025 a researcher scanned 1,645 apps from Lovable's showcase and found 303 exposed endpoints across 170 of them, about 10%. Exposed data included emails, phone numbers, payment details and developers' API keys. On one site an attacker could insert a record marked as paid (Matt Palmer, CVE-2025-48757, published 29 May 2025).

Lovable has added checks since. On 15 November 2026 its docs said a quick scan runs on every publish and flags tables without per-record access control and rules that let everyone through. A deeper code scan runs on demand. The same page says these tools "cannot guarantee complete security" and do not replace a review (Lovable docs).

One more thing to know: Lovable Cloud, the default backend for new projects, is built on Supabase (Lovable docs). Everything below applies whether you connected your own Supabase project or not.

What we do on every client app:

• 1. Turn on RLS for every table in the public schema. With RLS on and no policy, the table is closed to the public key. Then open exactly what each screen needs.
• 2. Write policies against the row's owner. A rule like "the user is authenticated" is almost never enough. Compare the row's owner or company column with the signed-in user.
• 3. Decide who may sign up. For an internal tool, close sign-up and invite people. For a public app, require email confirmation and add a CAPTCHA, which Supabase supports on sign-up, sign-in and password reset.
• 4. Clean out before launch. Test users, seed data and tables from abandoned features. Back them up, then delete them.

• 5. Move heavy queries into views or SQL functions, and index what policies filter on. Supabase's docs recommend an index on every column a policy filters on, and wrapping auth.uid() in a select so it runs once per query. One trap: views skip RLS by default because they're created by the postgres user. On Postgres 15 and later, create them with security_invoker = true so they follow the table's rules (Supabase docs).
• 6. Separate tenants in the database. When several client companies share one app, every row carries a company id and every policy checks it. The Predictive SCS planning app served 3–5 client companies, with admin-approved users tied to one company each.
• 7. Keep file buckets private. Use signed links for files a user should see. Our Morning Portal copies saved images into a private bucket instead of linking to the public originals.

• 8. Keep outside API keys on the server. Anything in the browser can be read. In the 2025 scan, exposed data included Google Maps, Gemini and eBay keys. Supabase's own secret key (service_role) skips every RLS rule, and its docs say never to use it in the browser. On the kitchen visualizer, the browser never calls the image model. The pipeline does, and logs token use for every run. That's how we know each render costs about $0.138.
• 9. Run batch work outside the app. Imports, transcriptions and nightly syncs belong in a pipeline, a scheduled function or a small server. At NextEnergy, recordings arrive on FTP and a pipeline transcribes and checks each one against 30+ compliance criteria. The Lovable app on top only reads the results for 5,000+ calls. Nobody has to keep a browser tab open for the work to finish.

• 10. Make schema changes as migrations in Git. A table changed through a chat leaves no record. A numbered SQL file in the repo says what changed and when, and can rebuild the database from scratch. Our Morning Portal's schema lives in numbered migrations next to its code. Lovable's two-way GitHub sync makes this possible for a Lovable app too.
• 11. Put the project in the client's accounts. The Supabase organisation, the hosting and the domain should belong to the business, with us invited. Baltoro's Supabase sits in Baltoro's own organisation. The UK funding broker's two apps moved to the client's own Vercel team on 24 October 2026.
• 12. Run the checks, then read the rules yourself. Supabase's Security Advisor emails a summary of what it finds. Atlas People forwarded us theirs when the backend went live, in January 2025. Lovable's scan runs on every publish. Both are a starting list. The 2025 disclosure found that Lovable's scanner at the time checked whether a policy existed, not whether it was right. Only a person reading the policy against the screens can tell.

• Money moves through it, and nobody has reviewed the rules. Payments, payouts, refunds. In the 2025 case, a writable table let a stranger mark an order as paid.
• It holds health, legal or financial records. Lovable's own docs say apps with sensitive data need an additional professional security review. Get one.
• The logic is mostly background work. If the screens are 20% of the app and the jobs are 80%, start in code.
• Nobody will own it after launch. A database with no owner drifts. Someone has to read the advisor emails.

The code path is short. Connect GitHub in Lovable, clone the repo and keep working in Claude Code, with migrations and jobs in the same repo. If the app runs on Lovable Cloud, moving to your own Supabase project is an export and restore plus new storage, logins and secrets; Lovable doesn't do it in one step. We compare the two tools in Lovable vs Claude Code.