Tech & AI, Explained

vercel

13 min read

Vercel

Status: 🟩 COMPLETE (🟦 LIVING — Vercel ships changes weekly) Last updated: 2026-06-20 Plain-English tagline: A hosting platform that turns “git push” into “live on the internet” — built by the team that makes Next.js, and optimized for it.

In plain English

When you finish building a webapp, it lives on your laptop at localhost:3000. For anyone else to use it, it needs to run on a computer connected to the public internet. That computer needs to be reliable, fast, properly configured, kept secure, and reachable at a memorable address.

You could rent a virtual server from Amazon AWS or Google Cloud and set all that up yourself — and people do — but it’s roughly two weeks of full-time work the first time, and ongoing maintenance forever. Vercel does it for you, for free for most projects, with an interface so simple that “deploying” feels like nothing happened at all.

You connect your GitHub repository to Vercel. Every time you push code, Vercel:

  1. Pulls the latest version
  2. Builds it
  3. Tests it for type errors and build failures
  4. If it passes, replaces the live site with the new version
  5. Keeps the old version available in case you need to roll back

That’s it. No SSH, no server admin, no configuration files (usually), no security patches.

Vercel is the company that makes Next.js. Vercel + Next.js + Supabase is the most common modern webapp stack for solo developers and small teams in 2026.

Why it matters

Three reasons:

  1. The integration with Next.js is unmatched. Every Next.js feature works perfectly on Vercel because the same people build both. Image optimization, edge functions, ISR, streaming, server actions — all “just work” on Vercel with zero configuration. On other platforms, you sometimes need workarounds.

  2. The free tier is genuinely usable. Many real production apps run on Vercel’s free tier indefinitely. (For Hobby projects only — see the Pricing section for restrictions.)

  3. The developer experience is best-in-class. Preview URLs for every branch. Instant rollbacks. Live function logs. Built-in analytics. Custom domains in 60 seconds. Everything you actually need to ship and operate a small-to-medium webapp.

How a Vercel deployment actually works

When you push to a Git branch connected to Vercel:

git push origin main
       ↓
GitHub notifies Vercel via webhook
       ↓
Vercel spins up a build container (typically Linux + Node.js)
       ↓
Pulls your repo, runs `npm install`, then `npm run build`
       ↓
The build output gets uploaded to Vercel's storage + CDN
       ↓
Vercel switches the live URL to point at the new build
       ↓
You get a notification + a unique deployment URL

The whole cycle typically takes 60–180 seconds for a Next.js app. Subsequent builds are faster due to caching.

Crucially, the old deployment doesn’t get deleted. Vercel keeps every deployment forever (or until you delete the project), each at its own permanent URL. If the new version is broken, you click “promote” on the previous deployment and the live site instantly goes back to that version.

Three environments: development, preview, production

Vercel automatically distinguishes three environments:

EnvironmentWhen it’s usedWhere it’s served
DevelopmentYour local npm run devlocalhost:3000 (Vercel doesn’t run this, but your local app can use Vercel env vars via vercel env pull)
PreviewEvery push to a non-production branch (e.g. PR branches)A unique URL like my-app-git-feature-x-yourname.vercel.app
ProductionThe branch designated as Production (usually main)Your custom domain + the project’s main .vercel.app URL

Environment variables can be scoped to one or more environments. A DATABASE_URL might be different in production vs preview vs development. You set this in the Vercel dashboard: Settings → Environment Variables → check which environments each variable applies to.

This three-tier setup is one of the most useful things Vercel does for you. Every pull request automatically gets its own deployable URL — you can share it with non-developer stakeholders, test on a real device, run automated tests against it.

Vercel Functions and Fluid Compute

When you write a Next.js Server Component, Server Action, or Route Handler, the server-side code runs on Vercel Functions.

In 2025, Vercel introduced Fluid Compute — a major upgrade to how functions run. Fluid Compute is now the default for new projects (since April 2025). The change matters:

FeatureBefore (classic serverless)After (Fluid Compute)
ConcurrencyOne function instance handles one request at a timeOne instance handles many concurrent requests
Cold startsEvery new request might pay the cold-start costFar fewer cold starts; reused instances are warm
Cost modelPay per invocationPay for compute time used, including concurrent requests
Best forBurst workloadsRealtime, streaming, AI inference, anything I/O-bound

Practical impact for you: Your Vercel functions are now faster, cheaper for most workloads, and behave more like traditional servers — but you still don’t have to manage anything. You write code the same way; Vercel runs it more efficiently.

There are two kinds of functions you can write:

Serverless (Node) Functions

Full Node.js runtime. Can use any npm package. Long-running (up to 800 seconds with Pro). Ideal for most server work.

Edge Functions

Run on Vercel’s edge network — close to the user, globally distributed. Limited runtime (no Node APIs, only Web Platform APIs). Smaller bundle sizes. Lower latency. Ideal for things that need to be fast and don’t need heavy computation: header rewrites, A/B testing, redirects, geolocation.

You choose which kind by exporting a runtime config:

export const runtime = "edge"; // Edge Function
// OR
export const runtime = "nodejs"; // Serverless Function (default)

Environment variables

Configuration that changes between environments — and especially secrets — lives in environment variables.

Setting them:

  1. Vercel dashboard → your project → Settings → Environment Variables
  2. Click “Add New”
  3. Enter the name, value, and check which environments (production/preview/development) it applies to
  4. Save
  5. Redeploy for changes to take effect (existing deployments don’t auto-update)

The NEXT_PUBLIC_ rule (Next.js-specific but critical):

  • Without NEXT_PUBLIC_ prefix → server-only. Safe for secrets.
  • With NEXT_PUBLIC_ prefix → baked into the client bundle. Visible to the browser. Never put secrets here.

Local development: You can pull production env vars into a local .env.local file with the CLI:

vercel env pull .env.local

This is the right way to keep your local app in sync with what Vercel knows. The pulled file is gitignored by default.

Regions — where your functions actually run

When you create a Vercel project, it has a default function region (usually iad1 — Washington, DC). For latency-sensitive apps, this matters: if your database is in Sydney but your functions are in DC, every database query crosses the Pacific.

Set the region in vercel.json at your project root:

{
  "regions": ["syd1"]
}

Common regions:

  • iad1 — Washington, DC (US East) — default
  • sfo1 — San Francisco
  • lhr1 — London
  • fra1 — Frankfurt
  • syd1 — Sydney
  • gru1 — SĂŁo Paulo
  • nrt1 — Tokyo
  • sin1 — Singapore

Match the region to your database for best latency. The St Mark’s Bible Quest project pins functions to syd1 to match its Supabase project in Sydney.

Note: Edge Functions don’t have a single region — they automatically run at the location closest to each user.

Domains

By default, every Vercel project has a <project-name>.vercel.app URL. You can connect a custom domain in three steps:

  1. Buy a domain (anywhere — Namecheap, Google Domains, Vercel Domains, etc.)
  2. In Vercel: Settings → Domains → Add your domain
  3. Follow the DNS instructions Vercel gives you (usually pointing your domain’s nameservers at Vercel, or adding specific CNAME/A records)

DNS propagation can take anywhere from 10 minutes to 48 hours. SSL certificates are auto-issued by Vercel via Let’s Encrypt — you don’t have to manage them.

If you buy your domain through Vercel Domains, the connection is one click — no DNS configuration needed.

Logs and observability

Three places to check what’s happening:

ToolWhat it shows
DeploymentsBuild status (Ready, Failed, In Progress). Build logs for each.
Functions / Runtime LogsLive log stream from your serverless and edge functions. Filterable by deployment, route, status code.
AnalyticsWeb Vitals (Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint), page views, top pages, traffic sources

For production apps, the Runtime Logs tab is where you’ll spend the most time debugging. It’s a real-time view of every console.log, every error thrown, every request handled. Filterable, searchable.

Image optimization

The Next.js <Image> component automatically serves optimized images on Vercel:

  • Resized to the size the user’s device actually needs
  • Converted to AVIF/WebP if the browser supports them
  • Lazy-loaded by default
  • Served from the Vercel CDN

You don’t have to do anything except use <Image> instead of <img>. Vercel handles the rest. (On other hosting providers, image optimization either doesn’t work or requires extra setup.)

Preview deployments — the underrated superpower

Every branch other than your production branch gets a preview deployment. Every commit to that branch gets a unique URL.

Why this is valuable:

  • Share work in progress without merging. Send a link to a non-developer for feedback.
  • Test on a real device. Your phone’s browser can hit the preview URL, no tunneling needed.
  • Run E2E tests against real infrastructure. GitHub Actions can spin up a preview, point Playwright at it, and tear it down.
  • Compare versions side by side. Production at your-domain.com, preview at your-app-git-feature-x.vercel.app. Same data, different code.

Pull requests on GitHub get a comment from Vercel with the preview URL automatically.

Pricing (as of mid-2026)

TierCostWhat you get
Hobby$0Unlimited deployments, 100GB bandwidth/month, 100GB-hours of function compute, 1 team member. Only for non-commercial projects.
Pro$20/month per userCommercial use, more bandwidth (1TB), more compute, custom domains, password-protected previews, team features
EnterpriseCustomSOC 2 + HIPAA, dedicated support, SLA, advanced features

Critical detail: the Hobby tier is non-commercial only. Strictly read: a personal blog is fine, a side-project that doesn’t generate revenue is fine, but a project that takes money (even $1) needs Pro. Many people miss this; Vercel enforces it.

For the Bible Quest project (non-commercial, free to use), Hobby is the right tier.

Project structure and vercel.json

Most Next.js projects don’t need a vercel.json at all — defaults are correct. But when you do customize, it lives at the project root:

{
  "regions": ["syd1"],
  "framework": "nextjs",
  "buildCommand": "npm run build",
  "outputDirectory": ".next",
  "redirects": [
    { "source": "/old-page", "destination": "/new-page", "permanent": true }
  ],
  "headers": [
    {
      "source": "/(.*)",
      "headers": [{ "key": "X-Frame-Options", "value": "DENY" }]
    }
  ]
}

Most settings can also be configured in the Vercel dashboard (Settings → Build & Deployment). Use vercel.json when you want the config in version control (which is usually preferable).

The Vercel CLI

npm install -g vercel

What you use it for:

CommandWhat it does
vercelDeploy the current directory (interactive prompts the first time)
vercel --prodDeploy directly to production (skips preview)
vercel env pullPull production env vars into .env.local
vercel logs <deployment>Stream logs from a specific deployment
vercel listList recent deployments
vercel domains listManage custom domains
vercel linkConnect a local directory to an existing Vercel project

For most day-to-day work, you don’t need the CLI — git push + the dashboard cover almost everything. The CLI shines for env-var management and debugging.

A concrete example: the day a project goes live

  1. Day 1 — npx create-next-app@latest locally. git init, git push to a new GitHub repo.
  2. Day 1, 10 min later — Go to vercel.com/new, import the GitHub repo. Click Deploy. Live URL: my-cool-app.vercel.app.
  3. Day 1, 30 min later — Add a Supabase connection. Add env vars in Vercel dashboard. Redeploy.
  4. Day 1, 60 min later — Buy mycoolapp.com from Vercel Domains. One click to connect. Live at https://mycoolapp.com with auto-renewing SSL.
  5. Every day after — Make a change locally, git push. Vercel auto-deploys in ~90 seconds. If something breaks, click “Promote” on the previous deployment and you’re back.

That entire workflow used to take a team of three a month, and a six-figure infrastructure budget. Now it’s an afternoon for one person.

Common gotchas

  • Hobby tier is non-commercial only. If your project takes any payment (even tips), you need Pro. Vercel enforces this.

  • Build succeeds locally but fails on Vercel. Almost always one of three things:

    1. Case sensitivity. Vercel builds on Linux, which treats Button.tsx and button.tsx as different files. macOS and Windows often don’t. Verify your imports match file names exactly.
    2. Missing env vars. process.env.FOO is undefined because you forgot to add FOO in Vercel Settings → Environment Variables.
    3. Type errors. TypeScript may be more strict in production builds. Run npm run build locally; it catches these.

  • Env var changes don’t apply to existing deployments. You need to redeploy. Go to Deployments → ”…” → Redeploy.

  • NEXT_PUBLIC_ exposes variables to the client. A NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY is a catastrophic security mistake. Never. Use the NEXT_PUBLIC_ prefix only for values that are genuinely safe to put in a browser bundle (project URL, anon keys).

  • Default region is iad1 (Washington, DC). If your database is elsewhere, you’ll have high latency until you set "regions" in vercel.json.

  • Free domain renewals are easy to miss. If you bought a domain through Vercel Domains, auto-renew is on by default — but if the card on file expires, you can lose the domain. Set a calendar reminder.

  • localhost:3000 and the production build behave differently. Caching, error boundaries, image optimization, certain Suspense behaviors all differ between next dev and a production build. Test with npm run build && npm run start locally before relying on something that only works in dev.

  • Functions have time limits. Hobby: 10s. Pro: 60s default, configurable up to 800s. Long-running tasks (heavy AI inference, big file processing) need to be designed with this in mind — break them up, use background jobs, or move to a different runtime.

  • Deployment logs are noisy by default. Filter the Runtime Logs by route, status code, and deployment to make them useful.

  • Preview deployment URLs are public. Anyone with the URL can visit. For sensitive previews, enable Vercel password protection (Pro feature) or use Vercel Authentication.

  • The “promote” / rollback button is your best friend. Get comfortable with it before you need it. When a deploy breaks production, hitting “promote previous deployment” is 5 seconds of recovery time instead of 5 minutes of panic.

What to do when something breaks in production

The standard checklist:

  1. Is the Deployments page showing a recent failed build? If yes, read the build logs.
  2. Are there errors in Runtime Logs? Filter by the affected route.
  3. Did an environment variable change recently? Check Settings → Environment Variables → “last modified.”
  4. Did a third-party service (Supabase, an API you depend on) go down? Check their status pages.
  5. If you can’t find it in 10 minutes, just roll back. Click promote on the previous good deployment. Investigate calmly. Re-deploy when fixed.

See also

Sources

Graph View

Backlinks