Guides

Deploying to production

Portrait of Sarah Mitchell
Sarah Mitchell
Product Engineer & Developer Advocate ·
A laptop showing a deployment dashboard

The starter is built to deploy itself. Every pull request gets an isolated preview — its own database branch and URL — and merging to main promotes the same build to production.

Environment variables

Local development reads the committed .env. Preview and production values live in your hosting provider and CI environment, never in the repo. The validated schema in src/env.ts is the single source of truth for what's required:

import { serverEnv } from "@/env";

// Throws at build time if a required variable is missing.
const url = serverEnv.DATABASE_URL;

Migrations

Schema changes are generated into version-controlled migration files:

pnpm db:generate   # create a migration from schema changes
pnpm db:migrate    # apply pending migrations

CI runs db:migrate against the preview database branch before each deploy, so a broken migration fails the build instead of reaching production.

Preview, then ship

Open a pull request and the pipeline builds the app, provisions a fresh database branch, applies migrations, and posts the preview URL on the PR. Once it's green, merge — production migrates and deploys automatically.

Start building

Ready to build your product? Start from a production-ready foundation with auth, organizations, and i18n already wired up.

Portrait of Sarah Mitchell

About the author

Sarah Mitchell

Product Engineer & Developer Advocate

Sarah Mitchell is a product engineer and developer advocate who writes about shipping, deployment workflows, and building for the long term.

Product EngineeringDevOpsDatabasesDeveloper Experience

More stories