Supabase Prod Checklist

Supabase Production Deployment Checklist

Overview

Actionable 14-step checklist for taking a Supabase project to production, based on Supabase's official production guide. Each step below carries its verification checklist inline; the full SQL, TypeScript, and CLI commands for every step live in references/step-commands.md.

Prerequisites

• Supabase project on Pro plan or higher (required for PITR, network restrictions)
• Separate production project (never share dev/prod)
• @supabase/supabase-js v2+ installed
• Supabase CLI installed (npx supabase --version)
• Domain and DNS configured for custom domain
• Deployment platform ready (Vercel, Netlify, Cloudflare, etc.)

Instructions

Work top to bottom. Every checkbox must be satisfied before go-live. Each step names the commands to run; copy them from references/step-commands.md.

Step 1: Enforce Row Level Security on ALL Tables

RLS is the single most critical production requirement. Without it, any client with your anon key can read/write every row. Start with the audit query — it must return zero rows before going live:

-- Find tables WITHOUT RLS enabled (must return zero rows before launch)
SELECT schemaname, tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public' AND rowsecurity = false;

Then ALTER TABLE ... ENABLE ROW LEVEL SECURITY and add per-command policies — full CREATE POLICY patterns in step-commands.md.

• RLS enabled on every public table (zero rows from audit query above)
• SELECT, INSERT, UPDATE, DELETE policies defined for each table
• Policies tested with both authenticated and anonymous roles
• No tables use USING (true) without intent (public read tables only)

Step 2: Enforce Key Separation — Anon vs Service Role

The anon key is safe for client-side code. The service_role key bypasses RLS entirely and must never leave server-side environments. See the two-client setup in step-commands.md.

• Anon key used in all client-side code (NEXT_PUBLIC_ prefix)
• Service role key used only in server-side code (API routes, Edge Functions)
• Service role key not in any client bundle (verify with grep -r "service_role" dist/)
• Database password changed from the auto-generated default

Step 3: Configure Connection Pooling (Supavisor)

Supabase uses Supavisor for pooling. Serverless functions (Vercel, Netlify, Cloudflare Workers) MUST use the pooled connection string (port 6543) to avoid exhausting the database connection limit — direct connections (port 5432) are for migrations and admin tasks only. Connection strings and client config in step-commands.md.

• Application code uses pooled connection string (port 6543)
• Direct connection reserved for migrations and admin tasks only
• Connection string in deployment platform env vars (not hardcoded)
• Verified pool mode: transaction for serverless, session for long-lived connections

Step 4: Enable Database Backups

Supabase provides automatic daily backups on Pro plan. Point-in-time recovery (PITR) enables granular restores.

• Automatic daily backups enabled (Pro plan — verify in Dashboard > Database > Backups)
• Point-in-time recovery configured (Dashboard > Database > Backups > PITR)
• Tested restore procedure on a staging project (do not skip this)
• Migration files committed to version control (supabase/migrations/ directory)
• npx supabase db push tested against a fresh project to verify migrations replay cleanly

Step 5: Configure Network Restrictions

Restrict database access to known IP addresses. This prevents unauthorized direct database connections even if credentials leak.

• IP allowlist configured (Dashboard > Database > Network Restrictions)
• Only deployment platform IPs and team office IPs are allowed
• Verified that application still connects after restrictions applied
• Documented which IPs are allowed and why

Step 6: Configure Custom Domain

A custom domain replaces the default *.supabase.co URLs with your brand domain for API and auth endpoints.

• Custom domain configured (Dashboard > Settings > Custom Domains)
• DNS CNAME record added and verified
• SSL certificate provisioned and active
• Application code updated to use custom domain URL
• OAuth redirect URLs updated to use custom domain

Step 7: Customize Auth Email Templates

Default Supabase auth emails show generic branding. Customize them so users see your domain and brand.

• Confirmation email template customized (Dashboard > Auth > Email Templates)
• Password reset email template customized
• Magic link email template customized
• Invite email template customized
• Custom SMTP configured (Dashboard > Auth > SMTP Settings) — avoids rate limits and improves deliverability
• Email confirmation enabled (Dashboard > Auth > Settings)
• OAuth redirect URLs restricted to production domains only
• Unused auth providers disabled

Step 8: Understand Rate Limits Per Tier

Supabase enforces rate limits that vary by plan. Hitting these in production causes 429 errors.

• Rate limits documented for your plan tier
• Client-side retry logic with exponential backoff for 429 responses
• Auth email rate limits understood (use custom SMTP to increase)
• Realtime connection limits planned for expected concurrent users

Step 9: Review Monitoring Dashboards

Supabase provides built-in monitoring. Review these before launch to establish baselines, and deploy a health check endpoint (full route handler in step-commands.md).

• Dashboard > Reports reviewed (API requests, auth, storage, realtime)
• Dashboard > Logs > API checked for error patterns
• Dashboard > Database > Performance Advisor reviewed and recommendations applied
• Health check endpoint deployed and monitored (uptime service)
• Error tracking configured (Sentry, LogRocket, etc.)
• Alerts set for: error rate spikes, high latency, connection pool exhaustion

Step 10: Deploy Edge Functions with Proper Env Vars

Edge Functions run on Deno Deploy. Set environment variables via the Supabase CLI or Dashboard, not hardcoded. Secret commands and a webhook function template in step-commands.md.

• All Edge Functions deployed to production (npx supabase functions deploy)
• Environment secrets set via npx supabase secrets set (not hardcoded)
• SUPABASE_URL and SUPABASE_SERVICE_ROLE_KEY available automatically (no need to set)
• Edge Functions tested with npx supabase functions serve locally before deploying
• CORS headers configured for Edge Functions that receive browser requests