Migrations & Health
Apply database migrations safely in production and verify your services are healthy.
Migrations in production
Always apply migrations with a forward-only deploy — never push schema changes ad hoc against a production database.
- Studio runs migrations automatically as part of the deploy flow.
- Manually, apply your committed migrations against the production database before starting the new backend version. Use the deploy-style migration (apply existing migrations), not a development migration that creates new ones.
Never use a "push" or "reset" against a production database — those can drop data. Only apply committed migrations forward.
Switching database provider
If you change your database provider, update the config and regenerate before deploying:
pnpm db:select -- postgres
pnpm sk:generate
Health checks
The backend exposes a health endpoint your orchestrator (or Studio) can probe:
GET /api/health
A healthy response confirms the backend is up and able to serve requests. Wire this into your container health check and load balancer so traffic only routes to ready instances.
Seeding
Seed data is intended for development and demos. In production, avoid seeding live data — provision real records through your application flows instead.