Before you start
You need three things: a Next.js project in a GitHub (or GitLab or Bitbucket) repository, a Vercel account (free to create at vercel.com using your GitHub login), and your environment variable names and values written down. You don't need the Vercel CLI for a basic deploy — the dashboard handles everything.
Vercel supports Node.js 20 and 22 for Next.js in 2026. If your project has an .nvmrc or an "engines" field in package.json, Vercel reads it automatically. If not, it defaults to the current LTS — usually fine unless your project has pinned an older version.
Step 1: Push your project to GitHub
Vercel deploys from a Git repository. If your project isn't already in one, create a new repository on GitHub (public or private — Vercel works with both), then push your local code:
- git init (if not already a git repo)
- git remote add origin https://github.com/your-username/your-repo.git
- git add . && git commit -m "Initial commit"
- git push -u origin main
Step 2: Import the project on Vercel
Go to vercel.com → New Project → Import Git Repository. Vercel lists your GitHub repositories — select your Next.js project and click Import. On the configuration screen, Vercel detects Next.js automatically and pre-fills the framework, build command (next build), output directory (.next), and install command based on your lockfile (npm, yarn, or pnpm).
Leave everything as-is for a standard Next.js project. The only thing you might adjust is the root directory if your Next.js app is in a subdirectory of a monorepo.
Step 3: Add environment variables
This is the step most people get wrong. Do not commit your environment variables to Git in a .env file — that exposes secrets. Instead, add them in Vercel's UI during the import step (or afterwards in Project Settings → Environment Variables).
Vercel scopes variables per environment: Production, Preview, and Development. NEXT_PUBLIC_ prefixed variables are baked into the client bundle — everything else stays server-only and encrypted at rest.
- Add database URLs, API keys, and secrets here — never in .env files committed to Git.
- NEXT_PUBLIC_ variables are visible to browsers — only use this prefix for safe-to-expose values.
- After adding or changing variables, redeploy for them to take effect.
- Your local .env.local file is for local development only — Vercel does not read it.
Step 4: Deploy and verify
Click Deploy. Vercel runs your install command, then next build, and packages the output as serverless functions and static assets. A typical Next.js app builds in 2–5 minutes on the first deploy; subsequent deploys are faster because Vercel caches dependencies and build artifacts.
When the build finishes, Vercel gives you a .vercel.app URL. Every deployment — including this first one — gets its own immutable URL. Test it thoroughly before wiring up your custom domain.
Step 5: Add a custom domain
In your project's Settings → Domains, type your domain and click Add. Vercel shows you two DNS records to create at your domain registrar: an A record pointing to 76.76.21.21 for the root domain, and a CNAME pointing to cname.vercel-dns.com for www.
DNS propagation takes up to 24 hours but is usually minutes. Vercel provisions your TLS certificate automatically via Let's Encrypt once propagation completes — no manual SSL setup required.
Preview deployments — test before you merge
Every pull request on your repository automatically gets a unique preview URL. You can share it with a client for review, run end-to-end tests against it, or check a visual diff before merging to production. Preview deployments use Preview environment variables, so they can point at a staging database rather than your live one.
This is one of Vercel's most valuable features — teams that use preview deployments essentially never break production accidentally, because the entire change is tested in isolation first.
Production best practices for 2026
Once your app is live, a few settings separate a production deployment from a side project:
- Enable Vercel Speed Insights and Analytics — surfaces Core Web Vitals per page route with one line of code.
- Use next/image for all images — Vercel's CDN serves the right size and format (WebP/AVIF) automatically.
- Use Next.js ISR (revalidate) or on-demand revalidation to avoid unnecessary serverless function invocations on static-ish pages.
- Set your main branch as protected in GitHub — Vercel only deploys to production from main, so PRs always go through preview first.
- Check function cold-start times in Vercel Analytics — routes that are slow on first request benefit from edge runtime or static generation.
- Use Vercel's built-in DDoS protection and middleware for rate limiting, auth checks, and redirects without a separate service.