Deploying to Vercel: From Development to Production in Minutes

My first Vercel deployment took four hours. Broken environment variables. Build errors that didn't exist locally. Edge function cold starts. DNS propagation mysteries.

Now I deploy in under three minutes. Every time. No surprises.

The difference is setup. You do it once. Then deploys are boring. Boring is good.

The One-Command Deploy

If your project is set up right, this is your entire deployment process:

git push origin main

That's it. Vercel watches your repo. Push to main, it builds and deploys. Push to a branch, it creates a preview deployment with its own URL.

But "set up right" is doing a lot of work in that sentence.

Project Configuration

// vercel.json - keep it minimal
{
  "framework": "nextjs",
  "regions": ["cdg1"],
  "headers": [
    {
      "source": "/api/(.*)",
      "headers": [
        { "key": "Cache-Control", "value": "no-store" }
      ]
    }
  ]
}

Most projects don't even need a vercel.json. Vercel auto-detects Next.js. I only add one for headers, region pinning, or redirects.

Don't over-configure. Every setting you add is a setting that can break.

Environment Variables: The Thing That Always Goes Wrong

Environment variables cause 80% of deployment failures. Here's how to not be that person.

Rule 1: Never put secrets in code. Ever. Not even in .env.example with placeholder values that someone will accidentally use.

Rule 2: Vercel has three environments. Development, Preview, Production. Set variables for each.

# Using the Vercel CLI (from your VPS, always with --token)
vercel env add ANTHROPIC_API_KEY production --token $VERCEL_TOKEN
vercel env add ANTHROPIC_API_KEY preview --token $VERCEL_TOKEN
vercel env add DATABASE_URL production --token $VERCEL_TOKEN

Rule 3: After adding env vars, redeploy. Vercel doesn't hot-reload environment variables.

vercel --prod --yes --token $VERCEL_TOKEN

Rule 4: Check your env vars before deploying. I have a pre-deploy script:

// scripts/check-env.ts
const required = [
  "ANTHROPIC_API_KEY",
  "DATABASE_URL",
  "NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY",
  "CLERK_SECRET_KEY",
  "STRIPE_SECRET_KEY",
  "STRIPE_WEBHOOK_SECRET",
];

const missing = required.filter((key) => !process.env[key]);
if (missing.length > 0) {
  console.error("Missing environment variables:", missing.join(", "));
  process.exit(1);
}
console.log("All environment variables present.");

Add it to your build command:

{
  "scripts": {
    "build": "tsx scripts/check-env.ts && next build"
  }
}

Build fails fast with a clear message instead of cryptic runtime errors.

Build Configuration

// next.config.ts
import type { NextConfig } from "next";

const config: NextConfig = {
  output: undefined, // Let Vercel handle this
  images: {
    remotePatterns: [
      { hostname: "images.unsplash.com" },
      { hostname: "img.clerk.com" },
    ],
  },
  experimental: {
    serverActions: {
      bodySizeLimit: "2mb",
    },
  },
};

export default config;

Don't set output: "standalone" unless you're deploying somewhere other than Vercel. It'll just complicate things.

The Pre-Deploy Checklist

I run through this mentally before every production deploy. Takes thirty seconds.

1. Types pass? npx tsc --noEmit - Zero errors.
2. Build works? npm run build locally. If it builds here, it builds there.
3. Env vars set? Check the Vercel dashboard or CLI.
4. Database migrations? If you changed the schema, migrate before deploying.
5. Webhook URLs updated? Stripe, Clerk, other services pointing to the right URL?

Preview Deployments Are Gold

Every pull request gets its own deployment. Its own URL. Its own environment.

Use this. Share preview URLs with clients for feedback. Test integrations in isolation. Run your QA against preview instead of staging.

I stopped maintaining a staging environment because of this. Preview deployments are better staging environments than staging environments.

Custom Domains

# Add a domain
vercel domains add app.example.com --token $VERCEL_TOKEN

# Vercel gives you DNS records to add
# After DNS propagation (~5 min), HTTPS is automatic

Point your DNS. Vercel handles SSL certificates. Automatic renewal. Zero maintenance.

Monitoring After Deploy

Vercel has built-in analytics and logs. But also set up:

Health check endpoint:

// app/api/health/route.ts
export async function GET() {
  const checks = {
    status: "ok",
    timestamp: new Date().toISOString(),
    database: await checkDatabase(),
    ai: await checkAIService(),
  };

  const allHealthy = Object.values(checks).every(
    (v) => v === "ok" || typeof v !== "string"
  );

  return Response.json(checks, {
    status: allHealthy ? 200 : 503,
  });
}

External uptime monitoring. Vercel can go down. Your monitoring should be somewhere else. I use a simple cron that hits /api/health every minute and alerts me on Telegram if it fails.

The Three-Minute Deploy

With all of this set up, here's what a deploy actually looks like:

1. Push to main (0:00)
2. Vercel detects the push, starts building (0:15)
3. Build completes (1:30 - 2:30 depending on project size)
4. Deployment goes live, traffic shifts (2:30 - 3:00)
5. Health check passes. Done.

No SSH. No Docker. No CI/CD pipeline to maintain. No server configuration.

Push code. Get a URL. That's the whole thing.

Do the setup once. Forget about deployment forever. Focus on building.