Supabase Launch Checklist: 25 Essential Steps

Go to your Supabase dashboard or run `ALTER TABLE table_name ENABLE ROW LEVEL SECURITY` on every table. Tables without RLS enabled are publicly accessible to anyone with your anon key. There are zero valid reasons to leave RLS disabled in production.

Each table needs SELECT, INSERT, UPDATE, and DELETE policies. Default with RLS enabled is deny-all, which is safe but means nothing works. Write the minimum necessary policies. Test each policy in the SQL editor with `SET LOCAL role = 'authenticated'`.

Verify that users can only access their own data, admins can access all data, and unauthenticated users see only public data. Test edge cases: can user A update user B's record? Can a deleted user's token still access data? Use the Supabase SQL editor to test.

Always reference `auth.uid()` in RLS policies to identify the current user. Never trust a `user_id` column passed in the request body — it can be spoofed. The policy `USING (user_id = auth.uid())` ensures users can only access their own rows.

The `service_role` key bypasses all RLS policies. Never expose it in client-side code, environment variables accessible to the browser, or public repositories. Use it only in server-side code, Edge Functions, or backend services.

Enable email confirmation in Authentication > Settings. Without it, anyone can create accounts with fake email addresses. Customize the confirmation email template with your brand and a clear call to action.

Configure your production domain in Authentication > URL Configuration. Add all valid redirect URLs (login, callback, password reset). Remove localhost URLs before going live. Unrestricted redirects enable open redirect attacks.

If using Google, GitHub, or other OAuth providers, create production OAuth applications (not development ones). Set correct redirect URIs, configure consent screens, and verify domain ownership. Test the complete flow on your production domain.

Set appropriate JWT expiry times (3600s default is usually fine). Implement token refresh logic using `supabase.auth.onAuthStateChange`. Handle expired sessions gracefully — redirect to login with a clear message, do not show cryptic errors.

Supabase has built-in rate limits, but verify they are configured appropriately in your project settings. For additional protection, add rate limiting in your Edge Functions or middleware for custom auth flows. Monitor for brute-force login attempts.

Run `EXPLAIN ANALYZE` on your most frequent queries. Add indexes to columns used in WHERE, JOIN, ORDER BY, and RLS policy conditions. Missing indexes cause full table scans that become catastrophically slow as data grows.

RLS policy conditions like `user_id = auth.uid()` run on every query. Without an index on `user_id`, each query performs a full table scan even for single-row lookups. This is the most common performance bottleneck in Supabase apps.

Define foreign key relationships between tables to ensure referential integrity. Use `ON DELETE CASCADE` for child records that should be deleted with their parent. Foreign keys prevent orphaned records that cause application errors.

Move multi-step operations (transfer funds, update inventory) into PostgreSQL functions. Database functions run atomically within a transaction, preventing partial updates. Call them with `supabase.rpc('function_name', params)` from your client.

Use the pooled connection string (port 6543) for serverless environments and Edge Functions, not the direct connection (port 5432). Direct connections are limited and can be exhausted by serverless function cold starts, causing connection errors.

If you do not use Realtime, disable it in project settings. If certain tables should not be accessible via the REST API, revoke permissions from the `anon` and `authenticated` roles. Every enabled feature is an attack surface.

Use Zod or similar to validate request bodies, query parameters, and headers in every Edge Function. Never trust client input. Return 400 with clear error messages for validation failures. This prevents injection attacks and data corruption.

Configure CORS headers in your Edge Functions to allow requests only from your production domain. Return appropriate headers for preflight OPTIONS requests. Never use `*` for Access-Control-Allow-Origin in authenticated Edge Functions.

Wrap Edge Function logic in try-catch blocks. Return structured error responses with appropriate HTTP status codes. Log errors server-side with context (user ID, request params). Never return raw error messages or stack traces to clients.

Store API keys, webhook secrets, and third-party credentials as Supabase Edge Function secrets using `supabase secrets set`. Never hardcode secrets in function code. Access them via `Deno.env.get('SECRET_NAME')` at runtime.

Supabase Pro plans include daily backups. Verify backups are enabled in your project settings. For critical data, set up Point-in-Time Recovery (PITR). Test your recovery process by restoring a backup to a separate project before you need it in an emergency.

Monitor database size, connection count, API request volume, and error rates in the Supabase dashboard. Set up external monitoring with tools like Better Stack or Checkly to alert you when your API becomes unresponsive.

Use `supabase db diff` and `supabase migration new` to create migration files. Commit them to your repository. Never make schema changes directly in the production dashboard — all changes should go through migrations for reproducibility and rollback capability.

Choose a Supabase region closest to your users for lowest latency. Upgrade to a Pro plan for production — the free tier has limitations on backups, bandwidth, and uptime SLAs that are unacceptable for production applications.

Create a separate Supabase project for staging. Use `supabase link` to connect your CLI. Run all migrations on staging first, test with realistic data, and verify before applying to production. This catches migration issues before they affect real users.