HomeServicesWorkBlogAboutContactGet Started
How to Deploy a Next.js App to Vercel
// Deployment

How to Deploy a Next.js App to Vercel

A practical guide to deploying Next.js on Vercel with environment variables, preview deployments, custom domains, and the production checks that matter.

VercelVercel

Vercel was built by the same team that created Next.js, which means the integration is close to frictionless. A standard next build output deploys with a single CLI command. Preview deployments happen automatically on every pull request. Edge caching is configured without touching a config file.

That said, there's a difference between getting something on Vercel and having it production-ready. This guide covers both — the fast path and the configuration that actually matters.

Prerequisites

  • Node.js 18.x or laternode --version to confirm
  • A Next.js project — Next.js 14 or 15, App Router or Pages Router both work
  • A Vercel account — the free Hobby plan is sufficient to start
  • Git — Vercel deploys from your repository, so this is required

Step 1: Install the Vercel CLI

npm i -g vercel

Verify it's installed:

vercel --version

You should see Vercel CLI 39.x.x or similar. The CLI handles authentication, deployments, environment variable management, and log access — worth having locally.

Step 2: Authenticate

vercel login

This opens a browser for OAuth. Once complete, your credentials are stored and the CLI is ready. You can also authenticate with an email/password flow if you prefer to stay in the terminal.

Step 3: Configure Your Project

Before deploying, confirm your next.config.js (or next.config.ts) is set up correctly. For most Vercel deployments, the defaults work. The most common misconfiguration is setting output: 'export' when you intend to use Vercel's serverless runtime — static export disables Server Components, API routes, and ISR.

If you're doing a standard Vercel deployment with server-side rendering:

/** @type {import('next').NextConfig} */
const nextConfig = {
  // No output field needed — Vercel handles this automatically
}

module.exports = nextConfig

Reserve output: 'export' for cases where you're deploying to a static host (S3, Cloudflare Pages, etc.) and don't need server-side functionality.

Step 4: Deploy

From your project root:

vercel

The CLI will ask:

  1. Link to existing project? — No for a first deploy
  2. Project name — accept the default or set your own
  3. Source directory — usually ./

Vercel then builds the project, runs next build, and deploys to a preview URL. Your first deployment output looks like:

Inspect: https://vercel.com/[team]/[project]/[id]
Preview:  https://[project]-[hash].vercel.app

For production, add --prod:

vercel --prod

Step 5: Environment Variables

This is where most teams have issues. Environment variables need to be set per-environment — development, preview, and production are separate in Vercel.

Via CLI:

vercel env add DATABASE_URL

The CLI will ask which environments to apply to and whether the value is sensitive (secret). Sensitive values are encrypted and not visible in logs.

Via Dashboard: Project → Settings → Environment Variables. This is easier for managing many variables or bulk imports.

Important: Next.js variables prefixed with NEXT_PUBLIC_ are exposed to the browser. Everything else is server-only. Be explicit about this distinction — leaking server secrets to the client is a common misconfiguration.

After adding variables, redeploy for them to take effect:

vercel --prod

Step 6: Custom Domain

vercel domains add yourdomain.com

Or via the Dashboard: Project → Settings → Domains → Add.

Vercel walks you through the DNS configuration. For most providers, you add a CNAME pointing your subdomain to cname.vercel-dns.com, or update your nameservers for apex domains. SSL is provisioned automatically via Let's Encrypt — no manual certificate management.

Preview Deployments (The Feature Most Teams Underuse)

Connect your Git repository in the Vercel Dashboard and every pull request automatically gets a unique preview URL. This is genuinely useful:

  • Reviewers test features without pulling branches locally
  • Stakeholders see changes before merge
  • Environment variables can be scoped to preview deployments

The workflow becomes: push branch → Vercel builds → reviewer gets a live URL → merge → Vercel auto-deploys to production. No manual deploy steps.

Common Issues and Fixes

Build fails with "Module Not Found"

Almost always a dependency that's in devDependencies but used in production code. Move it to dependencies, or check if you've excluded it from the build via .vercelignore.

Environment variables missing in production

Variables added after the last deploy won't be available until the next deploy. Run vercel --prod again after adding new variables.

404 on dynamic routes after deploy

If you're using output: 'export', dynamic routes need generateStaticParams() to pre-render at build time. Without it, there are no HTML files to serve. If you need dynamic routes that aren't pre-rendered, remove the static export config and use Vercel's serverless runtime.

Function timeout errors

Vercel's Hobby plan has a 10-second function timeout. If you're running long operations (PDF generation, heavy database queries), either optimise them or upgrade to a Pro plan with 60-second limits.

What Good Looks Like

A well-configured Vercel project has:

  • All environment variables set correctly across production and preview environments
  • Preview deployments enabled on the main branch and feature branches
  • Custom domain with automatic SSL
  • No secrets exposed with NEXT_PUBLIC_ prefix
  • Logs and monitoring configured (Vercel integrates with Datadog, Sentry, and others via the marketplace)

The deployment itself takes minutes. The configuration that makes it production-ready takes an hour the first time, less if you know what you're doing.

Getting It Right From the Start

If you're wiring up Vercel alongside a Supabase database, auth provider, and environment configuration for the first time, the number of moving parts adds up quickly. Getting environment variables consistent across local, preview, and production is often where projects break.

At Junctd, we set up production-ready Vercel deployments as part of broader infrastructure work — including the database, auth, environment config, and monitoring. If you want someone to do it properly the first time, get in touch. Based in Brisbane, working with teams across Australia.