Deploying Next.js to Vercel: the complete production checklist

Deploying a Next.js app to Vercel takes about five minutes for the first push — but production-ready deployment involves more than connecting a GitHub repo and clicking Deploy. You need to wire up environment variables, configure a custom domain, understand how preview deployments work, and know how to diagnose the failures that always seem to happen at the worst time.

This is the checklist we use for every new SaaS project: from the initial GitHub connection through post-deployment verification.

Step 1: Connect GitHub to Vercel

If you do not have a Vercel account, create one at vercel.com — the free Hobby plan is sufficient to start. Then:

1. Click Add New → Project in the Vercel dashboard
2. Select Import Git Repository and authorize Vercel to access your GitHub account (or select an existing connection)
3. Choose the repository you want to deploy. Vercel auto-detects Next.js and sets the framework preset automatically.
4. Leave Build Command and Output Directory as auto-detected unless you have a custom setup.

Do not click Deploy yet. Add your environment variables first — a deploy without them will fail or produce a broken app.

Step 2: Add environment variables before the first deploy

In the project setup screen, expand Environment Variables before clicking Deploy. Add every variable your app needs. For a typical Next.js SaaS stack:

# Auth
NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY
CLERK_SECRET_KEY
NEXT_PUBLIC_CLERK_SIGN_IN_URL
NEXT_PUBLIC_CLERK_SIGN_UP_URL
NEXT_PUBLIC_CLERK_AFTER_SIGN_IN_URL
NEXT_PUBLIC_CLERK_AFTER_SIGN_UP_URL

# Database
NEXT_PUBLIC_SUPABASE_URL
NEXT_PUBLIC_SUPABASE_ANON_KEY
SUPABASE_SERVICE_ROLE_KEY

# Payments
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY
STRIPE_SECRET_KEY
STRIPE_WEBHOOK_SECRET

# Email, analytics, etc.
RESEND_API_KEY
NEXT_PUBLIC_POSTHOG_KEY
NEXT_PUBLIC_POSTHOG_HOST

Set the Environment dropdown for each variable. Use your Stripe test keys for Preview and Development, and live keys for Production only. This keeps test traffic from mixing with real payments.

After the initial project setup you can manage variables under Settings → Environment Variables at any time. Changes to server-only variables take effect on the next deploy; changes to NEXT_PUBLIC_ variables require a new build because they are inlined at compile time.

Step 3: Configure a custom domain

Every Vercel project gets a free *.vercel.app subdomain immediately. To attach your own domain:

1. Go to Settings → Domains in your project
2. Enter your domain (e.g. getlaunchpad.net) and click Add
3. Vercel shows you the DNS records to add — typically an A record for the apex domain and a CNAME for www
4. Add those records in your domain registrar (Namecheap, Cloudflare, GoDaddy, etc.)
5. DNS propagation takes 5–60 minutes. Vercel automatically provisions a TLS certificate via Let's Encrypt once it detects the DNS change.

If you use Cloudflare, set the proxy status to DNS only (grey cloud) for the records pointing to Vercel. Cloudflare proxying plus Vercel can cause TLS certificate conflicts.

After adding the domain, update any hardcoded URLs in your env vars. For example, Stripe webhook endpoints and Clerk redirect URLs often reference the production domain and need to match.

Step 4: Understand preview deployments

Every pull request gets its own preview deployment at a unique URL like your-app-git-feature-branch-yourname.vercel.app. Preview deployments:

• Use your Preview environment variables — so they hit your test Stripe keys, staging database, etc.
• Are deployed automatically when you push to any non-main branch
• Can be shared with teammates or clients for review before merging
• Support Vercel's Comments feature for leaving feedback directly on the deployed page

For solo projects, preview deployments are still useful — they give you a production-like environment to test Stripe webhooks, OAuth redirects, and third-party integrations that do not work on localhost.

To test Stripe webhooks against a preview deployment, update your Stripe webhook endpoint in the Stripe dashboard to point at the preview URL, or use the Stripe CLI to forward events locally while developing.

Common deployment errors and fixes

Build fails: “Cannot find module” or TypeScript errors

Run npm run buildlocally before pushing. Vercel's build environment is stricter than development — TypeScript errors that are suppressed by next dev will fail the production build. Also run npx tsc --noEmit to catch type errors before they reach CI.

npm run build
npx tsc --noEmit
npm run lint

Runtime error: environment variable is undefined

The build succeeded but a page crashes at runtime. Open Vercel → Functions → Logs and look for the error. If it says something like Cannot read properties of undefined in a Supabase or Stripe client initialization, a required env var is missing.

Go to Settings → Environment Variables, add the missing variable, and trigger a new deployment via Deployments → Redeploy.

Auth redirects to localhost in production

Clerk, Supabase Auth, and OAuth providers often need to know the production URL for redirect callbacks. Check that:

• Clerk's Allowed redirect URLs in the Clerk dashboard include your production domain
• Supabase's Authentication → URL Configuration → Site URL is set to your production domain
• Any NEXT_PUBLIC_SITE_URL or similar variable points to the production URL, not http://localhost:3000

Stripe webhooks not firing in production

After deployment, register a new webhook endpoint in the Stripe dashboard pointing at https://yourdomain.com/api/stripe/webhook. Copy the webhook signing secret (whsec_...) and add it as STRIPE_WEBHOOK_SECRET in your Vercel Production environment variables. Without the correct signing secret, webhook signature verification will reject every event.

Deployment is cached — changes are not showing

Vercel caches aggressively. If you push a change and it does not appear, check that you are looking at the Production deployment (the one with the green checkmark) and not an older preview URL. If the production URL still shows old content, trigger a manual redeploy from the Vercel dashboard with Redeploy → Use existing build cache: off.

Post-deployment checklist

After every significant deployment to production, run through this checklist before announcing anything:

• Sign up as a new user. Verify the welcome email arrives, the database row is created, and the dashboard loads.
• Complete a test purchase. Use Stripe test card 4242 4242 4242 4242 (any future expiry, any CVC). Confirm the subscription activates and any post-payment email is sent.
• Check the Vercel Function logs. Look for any 500 errors or unexpected warnings in Deployments → [latest] → Functions.
• Verify the custom domain TLS certificate. Visit https://yourdomain.com and confirm the browser shows a padlock. If it shows a certificate warning, check the Vercel Domains settings — the cert may still be provisioning.
• Test on mobile. Responsive issues that are invisible on desktop show up immediately on a phone.
• Check analytics are firing. Open PostHog (or your analytics tool) and confirm events are appearing from the production domain, not localhost.
• Confirm the Stripe webhook is active. Go to Stripe Developers → Webhooks and check the endpoint status shows no recent failures.

Useful Vercel CLI commands

The Vercel CLI lets you inspect deployments and pull environment variables without touching the dashboard:

# Install the CLI
npm i -g vercel

# Pull production env vars to .env.local (useful for debugging)
vercel env pull .env.local

# List recent deployments
vercel ls

# Inspect a specific deployment
vercel inspect <deployment-url>

# View real-time logs
vercel logs <deployment-url> --follow

vercel env pull is especially useful when you have a lot of variables and do not want to copy them manually — it pulls the current values from Vercel and writes them to your local .env.local. Note that secret values are redacted by default; you will need to re-enter sensitive values locally.

The production deployment setup described here — Vercel project configuration, environment variable separation between Preview and Production, custom domain, and the post-deployment checklist — is what ships in every project built on GetLaunchpad, a Next.js 16 SaaS boilerplate. The hard parts of auth, payments, and email are already wired together so you can focus on the deployment that actually matters — your product.