·7 min read

How I Deploy Next.js Apps on Vercel — The Complete Setup (Domain, SSL, Analytics)

Deploying to Vercel takes 2 minutes. Setting it up properly takes 30. Here's the 30-minute version — custom domain, SSL, analytics, preview deploys, and rollback.

Next.jsVercelDeploymentWeb Dev

Deploying a Next.js app to Vercel takes 2 minutes. Connect your GitHub repo, click deploy, and you're live.

Setting it up properly takes 30 minutes — and that 30 minutes is the difference between a toy deployment and a production-ready setup with custom domains, automatic SSL, analytics, preview deployments for every PR, and one-click rollback when something breaks.

This is the 30-minute version. I deploy every client project this way.

Step 1: Connect your GitHub repo

The first step is the easy one, but it sets up the foundation for everything else.

  1. Push your Next.js project to GitHub (if it's not already there)
  2. Go to vercel.com, sign in with GitHub
  3. Click "Add New Project," import your repo
  4. Vercel auto-detects Next.js and configures the build settings

Click deploy. In 1-3 minutes, you have a live URL like your-project.vercel.app. That's the default — but you're not done.

Why this matters: connecting via GitHub means every push to main triggers a production deployment, and every pull request triggers a preview deployment. You never manually deploy again.

Step 2: Configure environment variables

This is where most people mess up. Your local .env.local file does not automatically sync to Vercel. You have to add each variable manually.

Go to your project → Settings → Environment Variables. Add each one:

  • DATABASE_URL — your database connection string
  • STRIPE_SECRET_KEY — payment keys
  • MAIL_PASS — email credentials
  • Any API keys your app uses

The mistake I made early on: I deployed, the site loaded, but contact forms silently failed because I forgot to add the email environment variable. The build succeeded. The page rendered. The form just didn't work. Always double-check your env vars after the first deploy.

Pro tip: Vercel lets you set different values for Production, Preview, and Development environments. Use a separate test database for Preview so PR deployments don't pollute your production data.

Step 3: Custom domain setup

The your-project.vercel.app URL is fine for testing. For a real site, you need your own domain.

Go to Settings → Domains → Add. Enter your domain (e.g., mefjudev.com). Vercel gives you DNS records to add:

For the apex domain (mefjudev.com):

  • Add an A record pointing to 76.76.21.21
  • Or add Vercel's nameservers if you want full DNS management on their side

For www:

  • Add a CNAME record pointing to cname.vercel-dns.com

The DNS propagation wait: changes can take 5 minutes to 48 hours to propagate globally. In practice, it's usually under an hour. Don't panic if your domain doesn't resolve immediately.

The redirect question: Vercel asks if you want to redirect www to apex or apex to www. Pick one and stick with it — I redirect www.mefjudev.com to mefjudev.com. Having both resolve without a redirect hurts your SEO (duplicate content).

Step 4: SSL — automatic, but know how it works

Here's the best part: SSL is automatic. The moment your domain resolves, Vercel provisions a Let's Encrypt certificate. No manual cert generation, no renewal headaches, no expired certificate emergencies.

You don't need to do anything. But you should know:

  • Vercel redirects all http:// traffic to https:// automatically
  • Certificates auto-renew before they expire
  • You can view certificate status under Settings → Domains

If your site shows "Not Secure" after setup, it's usually DNS not fully propagated yet. Wait an hour and check again.

Step 5: Vercel Analytics and Speed Insights

This is the step most people skip — and it's the one that pays off long-term.

Go to your project → Analytics tab → Enable. Same for Speed Insights.

Vercel Analytics shows:

  • Page views, unique visitors, top pages
  • Real user monitoring (not synthetic — actual visitor data)
  • Referrers (where your traffic comes from)
  • No cookie consent needed (privacy-friendly, no PII)

Speed Insights shows:

  • Core Web Vitals from real users (LCP, FID, CLS)
  • Performance by page and by country
  • Where your slowest users are

The free tier covers most small sites. The data is gold — you finally know if your site is actually fast for real users, not just on your fast laptop.

Step 6: Preview deployments for every PR

This is already set up by default, but most people don't use it effectively.

Every pull request gets its own preview URL: your-project-git-branch-yourusername.vercel.app. Share this URL with clients before merging. They can click around, test features, approve — all without touching production.

My workflow:

  1. Create a feature branch
  2. Open a PR
  3. Share the preview URL with the client
  4. Client reviews, leaves comments on the PR
  5. Merge to main → automatic production deploy

No more "let me deploy this to a staging server." Vercel handles it. Every PR is a staging environment.

Step 7: Production deployment and rollback

When you merge to main, Vercel deploys to production automatically. Usually takes 1-2 minutes.

When something breaks (and it will):

Go to your project → Deployments. You'll see a list of every deployment with timestamps. Find the last known-good deployment, click the "..." menu, and select "Instant Rollback."

Vercel switches the active deployment. No redeploy, no rebuild — it just points traffic to the previous version. Your site is back online in seconds.

I've used this twice in the past year when a deploy broke something I didn't catch in testing. It saved hours of "find the bug, fix it, redeploy, pray."

The mistake I made: not setting up preview deployments early enough

When I first started using Vercel, I pushed directly to main for everything. No branches, no PRs, no previews. I'd deploy a change, find a bug live, and scramble to fix it while the site was broken.

The fix: treat main as production-only. Every change goes through a branch and a PR. The preview deployment catches issues before they hit production. I haven't broken production since I adopted this workflow.

The complete checklist

Here's everything, in order:

  • Connect GitHub repo to Vercel
  • Add all environment variables (Production, Preview, Development)
  • Add custom domain + configure DNS
  • Verify SSL is active (automatic)
  • Set www ↔ apex redirect
  • Enable Vercel Analytics
  • Enable Speed Insights
  • Test a preview deployment (open a PR)
  • Test rollback (deploy something, then roll back)
  • Set up branch protection on main (via GitHub)

Total time: 30-45 minutes for the first project. After that, you can set up a new project in 10 minutes.

Deploying is easy. Setting up a deployment workflow that scales — preview environments, rollback, analytics, proper env var management — is what separates hobby projects from production sites.

Need help deploying your Next.js app?

I deploy Next.js apps for clients every week — domains, SSL, analytics, the full setup. Let's talk.

← Back to blog