Separate environments and secrets

The Supabase CLI will happily run a destructive command against the wrong project. Environment separation is what makes that mistake hard instead of easy.

Use separate projects, or the platform’s supported branching workflows, for environments that must not share users or data. Local development runs on the CLI stack; staging and production are distinct hosted projects with their own project references. Record each project reference and its purpose somewhere visible — without recording credentials next to it:

abcdefghijkl  production  (real users, never experiment here)
mnopqrstuvwx  staging     (disposable data, safe to break)

The CLI acts on whatever project the directory is linked to:

supabase link --project-ref mnopqrstuvwx
supabase projects list
#   LINKED │ REFERENCE ID  │ NAME
#  ────────┼───────────────┼────────────
#          │ abcdefghijkl  │ production
#     ●    │ mnopqrstuvwx  │ staging

Check the marker before anything irreversible. CLI defaults differ between commands — some act on the local stack, some on the linked project — so pass local or linked targets explicitly for destructive or production-sensitive work:

supabase db reset --local            # rebuilds the local stack, always safe
supabase db push --linked --dry-run  # preview what would hit the linked project

The nightmare command is supabase db reset --linked. It rebuilds the linked project’s database from your local migration files — on production that is total data loss, and the confirmation prompt is the only thing between you and it. Review the linked project before pushing migrations, every time, even when you are sure.

Secrets follow the same split. Each environment gets its own values, set where that environment runs:

supabase secrets set RESEND_API_KEY=re_8fKm2Vw... --project-ref mnopqrstuvwx
supabase secrets list --project-ref mnopqrstuvwx

Never reuse production credentials in staging. The whole point of the split is that a staging mistake cannot touch production data — a shared API key quietly reconnects the two.

Close by writing the release checklist the exercise asks for: the source environment, the target project, the migration preview output, the smoke test to run after deploy, and who owns the rollback. Five lines in a markdown file beat memory under pressure.