Staging Environment Setup

Overview

main → production (shikshaos.triverseinfotech.com)
staging → staging (staging-shikshaos.vercel.app or custom subdomain)

One-time setup

1. Create a staging Supabase project

Go to supabase.com → New project → name it shikshaos-staging. Apply all migrations to it:

migrations/0000_migration_tracking.sql
migrations/0001_ux_polish.sql
migrations/0002_infrastructure.sql

2. Create the `staging` git branch

git checkout -b staging
git push -u origin staging

3. Configure Vercel

In the Vercel dashboard for this project:

Settings → Git → Production Branch — keep as main
Settings → Environment Variables — for each variable in .env.staging.example, add it scoped to Preview and set Git branch = staging

Key env vars to scope to staging only:

Variable	Value
`NEXT_PUBLIC_SUPABASE_URL`	staging project URL
`NEXT_PUBLIC_SUPABASE_ANON_KEY`	staging anon key
`SUPABASE_SERVICE_ROLE_KEY`	staging service role key
`CRON_SECRET`	a different secret from prod
`NEXT_PUBLIC_APP_VERSION`	`staging`

Variables that can be shared with production (same values):

NEXT_PUBLIC_LIVEKIT_* — can point to same LiveKit instance
SENTRY_DSN — same project, different environment tag

4. Verify the staging deploy

git checkout staging
git push origin staging

Vercel auto-deploys the staging branch to a preview URL. Check the Vercel dashboard for the URL.

Deploy workflow

feature-branch → PR → staging (QA) → merge to main → production

Develop on a feature branch
Open PR against main — Vercel creates an ephemeral preview URL
After review, merge to staging for full integration testing
When QA passes, merge staging → main to ship to production

Running crons against staging

Vercel Cron Jobs only run on production deployments. To test cron jobs against staging:

curl -H "Authorization: Bearer $CRON_SECRET" \
  https://your-staging-url.vercel.app/api/cron/fee-reminders

Database migrations on staging

Always run migrations on staging first. Point DATABASE_URL at the staging project (Supabase dashboard → Project Settings → Database → Connection string → URI), then:

npm run migrate:status   # what is pending
npm run migrate          # apply it

The runner applies each migration and records it in schema_migrations in the same transaction, so the two cannot drift. A failure rolls that migration back and stops; earlier ones stay applied, so you fix the SQL and re-run. The script prints the database host before doing anything — read that line before confirming, so you never apply a staging migration to production.

Baselining an existing database

Production predates this runner: ~80 migrations were applied by hand and almost none were recorded. Run this once per existing database, which marks every migration as applied without executing any of it:

npm run migrate -- --baseline

Only correct when the database genuinely already has those migrations. A fresh staging project should be migrated normally instead, not baselined.

​Staging Environment Setup

​Overview

​One-time setup

​1. Create a staging Supabase project

​2. Create the staging git branch

​3. Configure Vercel

​4. Verify the staging deploy

​Deploy workflow

​Running crons against staging

​Database migrations on staging

​Baselining an existing database