My Lovable + Supabase app launches Friday. What should I check first?

Why this matters

Supabase serves tables in the public schema through its Data API, and the publishable key your frontend ships is meant to be public. Row level security is what keeps one user out of another user's rows. A Lovable preview that works while you are signed in as yourself does not show whether that holds for a stranger.

Check before Friday, in this order

• Open the Security Advisor in the Supabase dashboard and resolve every error. "Table publicly accessible" (rls_disabled_in_public) means a table in the public schema has no row level security.
• Confirm every public table has RLS enabled and a policy for each operation the app uses. Once RLS is on, the publishable key reaches no rows until a policy allows them, and a policy written to anon using (true) gives every signed-out visitor read access to every row the role can reach through grants.
• Look for views over protected tables. Supabase notes that views bypass RLS by default; on Postgres 15 and above, create them with security_invoker = true so they follow the table policies.
• Search the frontend code and its env files for the secret or service_role key. Only the publishable or anon key belongs in the browser; the secret key bypasses RLS and stays in server code such as an Edge Function. Rotate any secret key that ever shipped.
• Test with two accounts and a signed-out browser: create a row as user A, then try to read, change and delete it as user B and while signed out. Supabase's RLS guide goes further with pgTAP tests (supabase test db) that assert allow and deny for anon and authenticated.
• If users upload files, add RLS policies on storage.objects that limit each user to their own files. Supabase Storage allows no uploads to a bucket without RLS policies.
• In Authentication, URL Configuration, change the Site URL from localhost to your production URL and list exact redirect URLs. Supabase calls the Site URL critical for email confirmations and password resets, and recommends exact paths over wildcards in production.
• Set up custom SMTP before launch. The built-in sender only delivers to your project's team members and is currently limited to 2 messages an hour; with custom SMTP, Supabase starts you at 30 messages an hour, which you can raise under Rate Limits.
• Decide how you will recover data. Free plan projects have no downloadable backups, so Supabase recommends regular exports with supabase db dump; paid plans get daily backups. Database backups do not include the files in Storage.
• On the Free plan, Supabase may pause a project after low activity over 7 days. If a quiet week after launch would take the app down, upgrade before Friday.
• In Lovable, run the Deep scan from the Security view. The Quick scan runs when you publish and covers database access rules and dependencies; the Deep scan also reviews your app code. Lovable says neither can guarantee complete security.
• If you charge with Stripe, register a live mode webhook endpoint and confirm the handler verifies the signature. Test mode objects such as products, plans or coupons are not usable in live mode.
• Turn on multi-factor authentication for your Supabase account, and for GitHub if you sign in to Supabase with it.

Optional repo check

For AI-built Vercel + Supabase apps, such as a Lovable project synced to GitHub and deployed on Vercel, `npx -y viberaven@1.5.3 check` reads your clone of the repo and lists launch gaps it can see in files: public tables that no migration puts under row level security, policies whose condition is a bare `true`, a Supabase service role key in client code, and env vars the code reads that `.env.example` does not list (it cannot see Vercel settings). It is advice, not a gate, and a repository check, not a live database test: it does not connect to Supabase, so tables made in the dashboard are outside its view and every dashboard step above stays on your list. It exits with code 1 when it finds a blocker and writes a `.viberaven` folder that it does not add to `.gitignore`.

Sources

• Supabase, Production Checklist
• Supabase, Row Level Security
• Supabase, Advisors (rls_disabled_in_public)
• Supabase, API keys
• Supabase, Storage Access Control
• Supabase, Redirect URLs
• Supabase, Custom SMTP
• Supabase, Database Backups
• Lovable, Security overview
• Lovable, Sync your project with GitHub
• Stripe, Go-live checklist

Is the anon key in my Lovable frontend a leak?

No. Supabase says the publishable key, and the legacy anon key it replaces, is safe to expose in a browser because it only reaches what row level security allows. The secret key and the legacy service_role key are the ones that must never ship to the browser.

Does the Lovable security scan replace this checklist?

No. Lovable says its Quick and Deep scans help find common issues but cannot guarantee complete security, and it suggests a professional review for apps that handle sensitive data. The two-account test and the Supabase dashboard settings are still yours to do.

What if I find a table without RLS on launch day?

Enable RLS on it in a migration, add a policy for each operation the app needs, and repeat the two-account test. Once RLS is on, the publishable key reaches no rows until a policy allows them, so expect parts of the app to stop loading until the policies are in.