Apply Supabase migrations from CI

[ericzakariasson]

Summary

Adds a GitHub Actions workflow so database migrations are no longer applied to production by hand.

• Pull requests that touch supabase/ apply every migration to a fresh database (supabase db start), so broken SQL fails before merge.
• Merges to main apply the migrations that merge added to production (supabase db push), once a maintainer approves the production environment.
• Manual runs report what production is missing and never apply anything.

Safeguards

• Only files added by the merge get applied. Earlier migrations were applied by hand and may never have been recorded. If production is missing anything else, the job stops instead of replaying old migrations, several of which rewrite data.
• The CLI's own checks also stop the job if production has a migration the repo doesn't, or if a new file is older than the last applied one.
• Off by default. The production job is skipped until the SUPABASE_PROJECT_ID repository variable is set.
• Secrets stay protected. They live on the production environment, which pull requests (including forks) never reach.

Before turning it on

The full steps are in README → Database migrations:

1. Add a scoped Supabase access token and the database password as production environment secrets. Then require reviewers and limit deployment branches to main.
2. Line up production's migration history with the repo, using supabase migration list and supabase migration repair. Migrations so far were applied by hand (Replace Vercel Workflow with Supabase Queues + duplicate detection #389, Fix duplicate companies: enforce unique names + searchable company picker #400), so the history probably doesn't match.
3. Set SUPABASE_PROJECT_ID, then run the workflow by hand once to confirm nothing is pending.

Vercel deploys merges in parallel with this job, so a migration has to work with both the old and the new code. The README spells that out.

Testing

All local, with Supabase CLI 2.121.0 (the version the workflow pins):

• Fresh database: supabase db start on an isolated database applied all 14 migrations in about 17 seconds. A migration with a syntax error failed the run (exit code 1).
• Production check: I replayed the "Check pending migrations" step against a local database in six scenarios:

Scenario	Result
The merge adds one migration	Applied
Production is also missing an older migration the merge didn't add	Stopped, nothing applied
The merge adds a migration and edits an already-applied one	Applied the new one, warned about the edit
Nothing pending	Nothing applied
Manual run with something pending	Reported only
Production has a migration the repo doesn't	The CLI stopped it and printed the repair command

• Lint: actionlint and shellcheck are clean, and bunx biome ci . passes.

  

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
cursor-directory	Error		Oct 14, 2026 11:21pm UTC