Vercel Deployment

The simplest deploy on the planet

Connect a repo to Vercel; every push to main ships to production, every PR gets a unique preview URL. The platform was built by the team that builds the framework, so the defaults are correct.

What you get without configuring anything

Automatic builds + cache
Preview deployments per PR
Edge function support
Image optimization at the edge
ISR distributed across the global cache
Web Analytics and Speed Insights opt-in

Environment variables

Set them in the dashboard or via CLI. Three scopes: production, preview, development. Preview can have separate values from production — useful for staging databases.

Treat every Vercel deployment as an immutable candidate. Preview the exact commit, run migrations with an explicit compatibility plan, promote only after route and health checks pass, and keep the previous production deployment available for rollback.

Zero-config infrastructure does not mean zero operational decisions. Region placement, environment variables, cache behavior, function limits, domains, and database compatibility still belong to the application owner. Deploy a commit to preview, verify its commit SHA and environment, exercise one static route, one dynamic route, and one mutation, then promote. Confirm the production alias points to that deployment and rehearse rollback without reversing an irreversible migration.

Code

Two ways to deploy·bash

# Option 1 — CLI
npm i -g vercel
cd my-app
vercel             # interactive: link to org/project
vercel --prod      # promote to production

# Option 2 — Git integration
# Connect repo at vercel.com → push to main = production deploy

Env vars per environment·bash

vercel env add DATABASE_URL production
vercel env add NEXT_PUBLIC_API_URL preview development

# Preview URLs can use a staging DB while production uses live.

The simplest deploy on the planet

What you get without configuring anything

Environment variables

Code

External links

Exercise

Progress

Comments 0