Deploy

Environments

Env	App URL	Supabase project	Branch
Staging	https://app-staging.aimabel.ai/	tmdzcgbsywfguhfbzzxt	staging
Production	https://app.aimabel.ai/	fngfzfultusfacfhfztv	production

How a change reaches each environment

PR → CI checks → merge to staging → staging deploy
                                  ↓
                       (smoke-test)
                                  ↓
                   merge staging → production → production deploy

Frontend (Vercel)

Vercel watches both staging and production branches and deploys on push. No GitHub Action involved — pushes to those branches automatically trigger Vercel builds.

Docs site (Vercel)

A second Vercel project (platform-docs) builds docs-site/ — a Docusaurus renderer that points at the repo-level docs/ folder. Same trigger: push to staging or production → Vercel rebuilds. The renderer is intentionally separate from the main app so a docs-only change can't break a feature deploy.

Browse the rendered docs at the Vercel preview URL (or docs.aimabel.ai once configured).

Database + Edge Functions (GitHub Actions)

Two near-identical workflows:

• .github/workflows/staging.yml — runs on push to staging
• .github/workflows/production.yml — runs on push to production

Each does:

supabase link --project-ref $SUPABASE_PROJECT_ID
supabase db push                # apply new migrations
supabase functions deploy --project-ref $SUPABASE_PROJECT_ID

Required GitHub secrets:

Secret	Used by
SUPABASE_ACCESS_TOKEN	both workflows
STAGING_DB_PASSWORD, STAGING_PROJECT_ID	staging.yml
PRODUCTION_DB_PASSWORD, PRODUCTION_PROJECT_ID	production.yml

PR checks (.github/workflows/ci.yml, database-tests.yml)

Every pull request runs:

1. supabase db start (local stack in CI)
2. npm install
3. npm run gentypes — and the workflow fails if the diff isn't empty, forcing you to commit regenerated types
4. supabase test db — runs every .sql file under supabase/tests/database/

So before opening a PR, always run npm run precommit locally. It does the same steps the CI does, plus regenerates docs/schema/*.md.

Background workers (tasks/)

The TypeScript services in tasks/ are deployed manually to a VPS — they aren't part of the GitHub Actions pipeline. Each has its own README.md describing how to ship it. They share the same Supabase database as the web app, just with a different access pattern.

Rolling back

• Migrations: there's no automatic rollback. Write a forward migration that reverses the change, commit it, and let the same pipeline ship it. Never edit a migration that's already been pushed to staging or production.
• Edge Functions: redeploy the previous commit's function code (git checkout <sha> -- supabase/functions/<name> → push to the target branch).
• Frontend: Vercel's dashboard has one-click rollback to any previous deploy.

Things to never do

• Push to production without it first being live on staging for at least one working day.
• Run npm run reset against anything that isn't 127.0.0.1. The check-if-production-database npm script refuses to run when SUPABASE_URL contains supabase.co, but a stray env var can defeat it.
• Edit a migration after it's been merged. Always add a new migration on top.