Deployment

OpenScouter is deployed on Vercel. Deployments are automated through GitHub integration. No manual deployment steps are required for standard releases.

Environments

Production

The production environment serves live traffic at openscouter.com.

Vercel automatically deploys the main branch to production whenever a commit is pushed. This means main must always be in a deployable state. Never push directly to main. All changes go through a pull request.

Preview

Every pull request opened against main gets its own preview deployment. The URL is posted automatically by Vercel as a comment on the pull request.

Preview deployments use their own environment variables, isolated from production. They are safe to share with stakeholders for review before merging.

The dev branch, when it exists, also deploys to a named staging environment for longer-lived integration testing.

Environment Variables

All secrets and configuration are managed through the Vercel dashboard, not in code or in committed files.

To add or update a variable:

1. Open the Vercel dashboard for the openscouter project.
2. Go to Settings > Environment Variables.
3. Add the variable and select which environments it applies to (Production, Preview, Development).
4. Redeploy the affected environment for the change to take effect.

Never commit secrets to the repository. Never paste environment variable values into pull request descriptions, comments, or issue trackers.

If a secret is accidentally exposed, rotate it immediately and update the value in the Vercel dashboard.

Database Migrations

OpenScouter uses Prisma for database schema management. Migrations are applied as part of the deployment process.

The migration workflow is:

1. Make schema changes in prisma/schema.prisma.
2. Generate a migration with npm run db:migrate:dev. This creates a SQL migration file in prisma/migrations/.
3. Commit the migration file alongside the code change.
4. On deployment, the build step runs npm run db:migrate:deploy to apply pending migrations.

Never edit migration files by hand after they have been committed. If a migration needs to be revised, create a new one.

Test migrations against a copy of the production schema before merging. Migrations that drop columns or tables require extra review.

Rollbacks

If a deployment introduces a regression, Vercel allows instant rollback to any previous deployment from the dashboard.

For database changes, rollbacks are more involved. Design migrations to be backward-compatible where possible. If a rollback would require reversing a migration, coordinate with the team before proceeding.

Build Checks

The CI pipeline runs the following checks on every pull request before merge is permitted:

• TypeScript compilation (npm run typecheck)
• ESLint (npm run lint)
• Unit and integration tests (npm run test)
• E2E tests (npm run test:e2e)
• Production build (npm run build)

All checks must pass. The merge button is disabled until they do.