Guide · Supabase · Checked against Supabase's docs, October 2026 · Updated October 11, 2026

The Supabase launch checklist

Many AI-built apps keep their data in Supabase, and Lovable's built-in backend runs on it too. That's a good foundation, but the security depends on settings the AI may never have touched. Here are the ten things to check, where each lives in the Supabase dashboard, and a prompt to give your AI.

Built with Lovable Cloud? Many of these live inside Lovable instead. See the Lovable launch checklist.

1. 01

   Your data

   Table Editor

   Open the Table Editor and make sure every table matches something real in your app. Supabase's advisors flag structural problems like a table with no primary key, which usually means the AI guessed at the design.

   Paste into your AI

   Describe my Supabase data model in plain English: every table, what it stores, its primary key, and how the tables connect. Flag anything you assumed instead of being told.

   Copy prompt
2. 02

   Accounts

   Authentication → settings

   Supabase's production checklist says to turn on email confirmations and keep one-time codes short-lived (an expiry of 3600 seconds or less). Deleting a user takes server-side code, because only a secret key can remove accounts, so ask for it to be built in an edge function, not in the app.

   Paste into your AI

   Walk me through every account flow: sign up, email confirmation, sign in, forgot password, sign out and delete account. Which are missing? Build account deletion in a server-side function that removes the user and their data.

   Copy prompt
3. 03

   Permissions

   Policies and edge functions

   A hidden button isn't a lock: the browser talks to your database directly, so every rule has to live on the server. One trap Supabase's Security Advisor flags specifically: a policy that relies on user_metadata, which users can edit themselves. Never base a role like "admin" on it.

   Paste into your AI

   For every piece of private data and every admin action, show me the RLS policy or server check that enforces it. Flag any policy that reads user_metadata, and anything only protected by hiding it in the UI.

   Copy prompt
4. 04

   Database rules (RLS)

   Advisors → Security Advisor

   Supabase's rule: enable row-level security on all tables. A table in an exposed schema without RLS can be read and written by anyone with your public key. With RLS on and no policies, nothing is reachable until you add them. The Security Advisor flags tables that are publicly accessible and views that bypass RLS. Clear every warning.

   Paste into your AI

   List every table and view, whether RLS is enabled, and each policy in plain English: who can read, insert, update and delete. Flag tables someone who isn't signed in can reach, and any SECURITY DEFINER view.

   Copy prompt
5. 05

   API keys

   Project Settings → API Keys

   The publishable key is safe in your app; it can only do what your policies allow. Secret keys and the legacy service_role key skip every RLS policy, so they must never be in front-end code. If one leaks, Supabase's order is: create a new key, replace it everywhere, then delete the old one.

   Paste into your AI

   Search this project for Supabase keys and other secrets. For each one, tell me its name (not its value), whether it's publishable or secret, and where it's used. Any secret or service_role key in front-end code must move to a server-side function.

   Copy prompt
6. 06

   When things break

   Edge Functions

   AI builds the happy path. Work that touches money or another service should run in an edge function, where the server can finish or undo it if the person closes the app halfway.

   Paste into your AI

   For sign up, save, pay and upload: what happens if it fails halfway or the connection drops? Show me what the person sees, and make sure retrying can't create duplicates or double charges.

   Copy prompt
7. 07

   What leaves your app

   Authentication → SMTP and rate limits

   Supabase's built-in email service is rate-limited by default (Supabase lists 2 emails per hour), so confirmation and reset emails quietly stop arriving once a launch brings real sign-ups. Set up custom SMTP from a trusted domain before you launch, and test webhooks and payments in test mode.

   Paste into your AI

   List everything this app sends out: auth emails, other emails, notifications, payments, webhooks. For each, what triggers it, what limits apply, and how do I test it without reaching a real person or charging a real card?

   Copy prompt
8. 08

   Uploads

   Storage → Policies

   Storage has its own RLS policies on storage.objects: by default nobody can upload until you add one. Files in a public bucket can be opened by anyone with the link, so keep private files in private buckets and give out short-lived signed links.

   Paste into your AI

   For each storage bucket: is it public or private, what policies control upload, read and delete, and what are the size and file-type limits? Make private files private and use signed URLs for them.

   Copy prompt
9. 09

   Hosting and cost

   Organization → Billing and Usage

   Free projects pause after 7 days of low activity and can be restored from the dashboard for 90 days. Free projects also have no database backups. Paid projects are never paused for inactivity, and the Pro plan's spend cap stops surprise overage bills by restricting usage instead.

   This happened to me: my walking game was live on the App Store while its Supabase project sat paused, so the app did nothing, and no one told me. I moved it to a free organization, resumed it, and added a tiny daily request so it never looks inactive again.

   Paste into your AI

   Which Supabase plan is this project on, what does it cost per month at current usage, and what happens when I hit each limit? Does my app get enough daily activity to avoid pausing, and how would I restore a backup?

   Copy prompt
10. 10

    Knowing when it breaks

    Advisors → Health, Logs

    The Health Advisor watches error rates, and Logs show what happened, but nobody reads logs until something's wrong. Add an outside check that does what a real user does every day, and keep track of keys and domains that expire.

    Paste into your AI

    How would I find out right now if this app stopped working? Suggest a simple daily check that tests a real user action against Supabase, and list any keys, certificates or domains that will expire.

    Copy prompt

Before you launch

1. Clear the Security Advisor. Fix every security finding, not just the red ones, and re-run it after each change.
2. Turn on SSL enforcement and network restrictions. Both live in your database settings and are on Supabase's own production checklist.
3. Protect the account itself. Turn on multi-factor authentication for your Supabase login, and add a second owner to your organization so you're never locked out.
4. Set up custom SMTP and review auth rate limits. Supabase's production checklist also recommends CAPTCHA on sign-up, sign-in and password reset.
5. Decide on backups. Free projects have none. Supabase suggests point-in-time recovery once a database grows past 4 GB.

Common questions

Sources

• Supabase: Production Checklist
• Supabase: Row Level Security
• Supabase: Database advisors
• Supabase: API keys
• Supabase: Storage access control
• Supabase: Project pausing
• Supabase: Cost control (spend cap)

An independent guide, not affiliated with Supabase, and not a professional security audit. Dashboards change often; if a menu has moved, the prompts still work. Written by Andrew Adams, based on the Vibe Coding Checklist. Other guides: Lovable · Bolt · Cursor and Claude Code · Supabase · Firebase.