Production Deployment

Production needs a PostgreSQL database, a stable public origin, an auth secret and credentials for the providers you selected. NEXT_PUBLIC_* values are built into browser bundles, so changing one requires a new build and deployment.

Server or container

From the repository root:

bun install --frozen-lockfile
bun run db:generate
bun run --cwd packages/database db:migrate
bun run build
bun run --cwd apps/web start

Set DATABASE_URL, BETTER_AUTH_SECRET, NEXT_PUBLIC_SITE_URL and selected provider credentials through the deployment environment before these commands. Use reviewed migrations against the intended database. Schema changes must remain compatible with old and new app versions during a rolling deployment; applying a migration alone does not guarantee zero downtime.

The checked-in Dockerfile has separate build, migration, operations, and web-runner stages. docker-compose.yml can run the local full stack with its app profile; its operations service starts after migrations. Its sample credentials and MOCK_SERVICES=true are for local development.

Trusted edge and readiness

Leave TRUST_PROXY_HEADERS unset unless the application is reachable only through an edge that appends the verified downstream client IP to X-Forwarded-For. With the setting enabled, VibeKit uses the last valid IP in that header for network rate limits. A proxy that forwards client-supplied values, or an exposed application port, lets clients influence the bucket and must not use this setting.

Use /api/health/live for process liveness and /api/health/ready for required configuration, database reachability, and migration state. In production without MOCK_SERVICES=true, readiness also requires a worker heartbeat younger than two minutes and a scheduler heartbeat younger than two hours. MOCK_SERVICES=true explicitly bypasses those operations checks for the local sandbox; it does not prove a production worker exists. Readiness deliberately does not test paid-provider reachability. Configure monitoring and verify each enabled provider's complete flow on the final domain instead of treating a green health endpoint as provider proof.

Managed hosting

Configure a monorepo-aware Next.js project with apps/web as the application and access to the root workspace dependencies. Run the repository build and database-generation steps, then verify that the host serves the output from apps/web/.next. Provider-specific root/output settings differ; this repository does not supply a universal Vercel deployment configuration.

Keep migrations in an explicit deployment step, configure OAuth callback and webhook URLs for the final origin, and verify login, protected pages and actual provider workflows after deployment. A successful build does not prove live integrations. The selected host's scheduler, backups, alert destination, and job execution still need configuration and final-domain proof.

Durable worker and maintenance

The web process does not drain the durable job queue. Configure the selected host to supervise one bun scripts/ops-worker.mjs --schedule process. It processes jobs, schedules hourly maintenance through deterministic UTC keys, and writes the readiness heartbeat. The repository's docs/OPERATIONS.md lists the current handlers, the separate queue/provider/mailbox states for invitation email, deletion waiting behavior, and the production evidence still required. A locally started worker or container is not proof that the final host runs it.

See Configuration and Database Migrations.