Deploying to Vercel in Under 5 Minutes

After this lesson, you will be able to: Push a Next.js + Supabase app to GitHub, deploy it to Vercel in under five minutes, configure environment variables per environment, set up a custom domain, and use preview deployments for every pull request.

Vercel is the company that builds Next.js, and Next.js deploys to Vercel with zero configuration. Connect a GitHub repo, click Deploy, and you have a live URL. Every push creates a new deployment; every pull request gets its own preview URL. This lesson takes you from never having deployed a Next.js app to a live `your-app.vercel.app` (and optionally `yourdomain.com`) in under 30 minutes.

Prerequisites:API Routes in Next.js

Why Vercel for Next.js

Vercel is the easiest path because Next.js IS Vercel's product. Every Next.js feature works out of the box: Server Components, Edge Functions, image optimization, ISR caching, preview deployments, edge runtime. Other hosts (Netlify, Cloudflare Pages, Railway) can run Next.js too, but the integration is tightest here. Free tier supports hobby projects (unlimited deployments, 100GB bandwidth/month). When you have real traffic, pricing is predictable and per-usage.

Step 1 — push to GitHub

Vercel deploys from a Git repo. Push your local project up first.

tsx

# In your Next.js project
git init
git add .
git commit -m "Initial commit"

# Create a new repo on github.com first (empty, no README),
# then connect it as origin:
git branch -M main
git remote add origin https://github.com/your-username/your-repo.git
git push -u origin main

Step 2 — deploy on vercel.com

Go to vercel.com, sign in with GitHub, click 'Add New → Project,' pick your repo. Vercel detects Next.js, sets the build command and output directory for you, and starts the first deploy. If you have environment variables (Supabase URL, anon key, etc.), add them in the same screen before deploying. First deploy takes ~60-90 seconds. When it's done, click Visit. You're live.

Step 3 — environment variables, per environment

Vercel separates env vars by environment (Production / Preview / Development). Add them in Settings → Environment Variables. The `NEXT_PUBLIC_` prefix tells Vercel a variable is safe to expose to the browser; everything else is server-only.

tsx

# Production env vars (set in Vercel dashboard)
NEXT_PUBLIC_SUPABASE_URL=https://your-project.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=ey...      # safe to expose
SUPABASE_SERVICE_ROLE_KEY=ey...           # SECRET, server-only

# Common pattern: separate Supabase project for production and preview/dev,
# so PR previews can't accidentally write to real user data.

Step 4 — custom domain

In Project Settings → Domains, type your domain. Vercel tells you the DNS records to add (typically a CNAME for `www` and an A record for the apex). Set those in your registrar (Namecheap, Cloudflare, Squarespace, wherever you bought the domain). Within a few minutes the domain resolves and Vercel issues a free SSL cert automatically. You can buy domains directly through Vercel too, but using your existing registrar is cheaper.

Preview deployments — every PR gets a URL

Every pull request you push to GitHub gets its own Vercel deployment at a unique URL. This is the killer feature for collaborative work: open a PR, get a live link to the change, share it with reviewers or designers before merging. The same comment-in-the-PR shows up automatically with the preview URL. No screenshots, no 'works on my machine.' This is how every team that uses Vercel reviews work.

💡 Common mistakes only experienced devs catch

Five deploy-time traps. (1) **Committing `.env.local`** — secrets leak to GitHub forever (even if you delete the file in a later commit, git history keeps it). Add `.env*.local` to `.gitignore` from day one and double-check on first push. (2) **Wrong `NEXT_PUBLIC_` boundary** — putting a secret behind `NEXT_PUBLIC_` exposes it to every visitor. Conversely, forgetting `NEXT_PUBLIC_` on a value the browser needs makes the app crash with 'undefined.' (3) **Preview and production hitting the same Supabase project** — a preview PR can corrupt or wipe production data. Use separate Supabase projects per environment. (4) **Forgetting to add env vars to Preview environment** — the first PR preview crashes with missing keys. Add to all three environments (Production / Preview / Development) when in doubt. (5) **DNS pointing to the apex without an A/ALIAS record** — yourdomain.com (no www) needs an A record or ALIAS to Vercel's IPs, not just a CNAME (most registrars don't allow CNAME on the apex). Use Vercel's exact recommended records.

←Connecting Supabase: Database and Auth

Back to React and Next.js

Capstone: Full-Stack App on Vercel→