All guidesLaunch checklists by stack and tool
On this page

Launch question

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

By Ohad Krispin, founder of VibeRaven · LinkedIn

Short answer

Before a Lovable + Supabase app launches, check who can read and write your data first: every table in the public schema needs row level security with policies that match your app, only the publishable key (or legacy anon key) belongs in the frontend, and a second account must not see the first account's rows. Then check what tends to break on launch day: the Site URL and redirect URLs, auth email sending, backups, and the Security Advisor findings in the Supabase dashboard. If your app uses Lovable Cloud, Lovable's built-in backend, Lovable's security guide has you review every RLS policy under More > Cloud > Database > RLS policies; the Supabase dashboard steps in this guide are for an app that uses its own Supabase project directly.

Use this from your agent
  • Claude Code: 7 read-only tools; public repos only.
    claude mcp add --transport http viberaven https://viberaven.dev/mcp
  • Codex: same server, from the Codex CLI.
    codex mcp add viberaven --url https://viberaven.dev/mcp
  • In your repo: writes Vercel + Supabase check rules for your agent (what it writes).
    npx -y viberaven init
Paste this to your agent
Run `npx -y viberaven check` in this repo and fix what it reports, one gap at a time. Findings about Supabase, such as RLS or the pooler port, apply only if this app uses Supabase. Do not add Supabase or any other provider this app does not already use. Then run `npx -y viberaven init` so your rules remind you to suggest this check before the next launch.

The check runs locally, with no sign-in and no API key. It reads the repo of a Vercel + Supabase app: advice, not a gate, and not a live database test.

Terminal output of npx viberaven check on a Vite + Supabase fixture repo laid out like a Lovable export, flagging public.bookings, created in a migration without row level security, as a blocker.
Terminal output of npx viberaven check on a Vite + Supabase fixture repo laid out like a Lovable export, flagging public.bookings, created in a migration without row level security, as a blocker.

Already live? Recheck the published app with the Lovable post-launch checklist.

Check before Friday, in this order

  1. 1
    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.
  2. 2
    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. Check grants separately: a missing grant can break an owner read even when the policy is correct. The dated rollout note below explains new-table defaults.
  3. 3
    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.
  4. 4
    Search the frontend code and its env files for the secret or service_role key. Only the publishable key (or legacy 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.
  5. 5
    Run the repo check on a GitHub clone of the project. From its root, npx -y viberaven@1.8.0 check reports a public table that no migration puts under row level security as rls_disabled, a policy that lets anyone read every row as rls_policy_allows_all_read and a Supabase service role key under a VITE_ name as service_role_key_in_client_env. It does not connect to Supabase, so tables made in the dashboard still need the steps above:
    Terminal
    npx -y viberaven@1.8.0 check
  6. 6
    Use disposable records and separate ordinary browser profiles for user A, user B and a signed-out visitor: a preview that works while you are signed in as yourself does not show what another account receives. Check owner reads as well as denied reads, then test writes and deletes separately if the app supports them. The general Lovable guide gives the proposed read procedure. Supabase also documents repeatable pgTAP allow/deny tests with supabase test db.
  7. 7
    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.
  8. 8
    For an external Supabase project, set Site URL to the production URL and list exact redirect paths in Authentication, URL Configuration. Supabase calls Site URL critical for confirmations and password resets. Lovable Cloud manages these addresses differently, as explained below.
  9. 9
    For your own Supabase project, configure custom SMTP for public sign-ups. The built-in sender is restricted to project-team addresses; as reviewed on 13 October 2026 its docs list 2 messages an hour, subject to change. Custom SMTP starts at 30 an hour and can be adjusted. Lovable Cloud has separate email settings.
  10. 10
    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.
  11. 11
    On the Supabase Free plan, a project may pause after low activity over 7 days. Plan for a quiet week after launch. This is the external Supabase-project policy; do not apply it to Lovable Cloud.
  12. 12
    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.
  13. 13
    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.
  14. 14
    Turn on multi-factor authentication for your Supabase account, and for GitHub if you sign in to Supabase with it.

Check the settings for your actual backend

These are documentation-backed checks and a proposed reader procedure, not a test run on a live customer app.

Dated Supabase changes

As reviewed on 13 October 2026, Supabase says the legacy anon and service_role keys are being deprecated by the end of 2026 in favor of publishable and secret keys. Deprecation is not evidence that an existing key is already disabled. Keep elevated secret keys out of browser code.

Supabase announces 30 October 2026 for the new-table grant default on existing projects; new projects use that default from 30 May. Once applied, new public tables need explicit grants for intended Data API access. Existing tables retain their current grants. Check the project's current setting and grant only the access your app needs, alongside RLS. The future rollout was not observed in this review.

Cloud auth and email are a different setup path

Lovable Cloud updates managed auth URLs when you publish or connect a custom domain, but leaves a manually set Site URL unchanged. External Supabase projects get no automatic URL updates. If you supply your own Google OAuth credentials, register the new domain's redirect URI in Google Cloud Console too.

For Cloud auth-email limits, inspect the sending rate under Advanced in email settings. Lovable documents managed email or a verified sending domain as prerequisites to raising it. The external Supabase sender limits above are not Cloud limits.

Repeat the actual user flow

Use the linked general guide for the proposed owner, other-user and signed-out read controls, optional response inspection and cleanup. Repeat after applied data or auth changes, then on the published URL after code changes. This read procedure does not replace separate write, delete, Storage, view or server-function tests.

Official docs behind this checklist

Browse all launch guides · Read resources · How to make and check your next change

FAQ for builders before launch

Is the anon key in my Lovable frontend a leak?

No. The publishable key and legacy anon key are intended for browser use. Access still depends on appropriate grants and RLS policies; a public key does not itself prove isolation. Secret and legacy service_role keys provide elevated access and 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.