Getting a web app from your laptop to the internet used to require renting a server, installing Node.js on it, configuring Nginx as a reverse proxy, setting up SSL certificates with Let's Encrypt, writing a deployment script, and then debugging why everything works locally but not in production. That whole process took hours, and it could go wrong in a dozen different ways.
Vercel collapses that entire process to: push to GitHub, done.
What Vercel Is
Vercel is a cloud platform built specifically for frontend and full-stack web applications. It was created by the same team that built Next.js, which means Next.js on Vercel is as close to zero-configuration deployment as exists today.
When you deploy to Vercel, it handles:
- Build process — runs
next build(or whatever build command your framework needs), compiles TypeScript, bundles assets - CDN (Content Delivery Network) — serves your static assets from servers close to each visitor worldwide, so your app loads fast whether the user is in New York or Nairobi
- HTTPS / SSL — automatically provisions and renews TLS certificates. Your site is always on
https:// - Custom domains — point your domain to Vercel and it handles the rest
- Preview deployments — every pull request gets its own unique live URL
- Serverless functions — your
app/api/routes in Next.js become serverless functions automatically, no server management required - Scaling — if your app suddenly gets ten thousand visitors, Vercel scales. You do not configure anything
What the Free Tier Includes
Vercel's Hobby plan is intended for personal, non-commercial use. Check the current eligibility rules and included usage before choosing it for a project. A free plan is a useful way to learn deployment, but it is not a general entitlement to host any commercial workload without a paid plan.
Limits can depend on the product, runtime, and configuration. Consult the current function-limit documentation rather than assuming every Hobby request has a 10-second timeout. Monitor the project's usage and review what happens when an included allowance is exhausted.
Deploying a Next.js App: Step by Step
Before deploying, make sure your code is on GitHub. If you are new to Git and GitHub, the beginner guide to Git and GitHub walks through pushing your first project.
Step 1: Create an account
Go to vercel.com and click "Sign Up." Choose "Continue with GitHub." Authorize Vercel to access your repositories.
Step 2: Import your project
On the Vercel dashboard, click "Add New Project." You will see a list of your GitHub repositories. Click "Import" next to the one you want to deploy.
Step 3: Configure the project
Vercel automatically detects Next.js and pre-fills:
- Framework preset: Next.js
- Build command:
next build - Output directory:
.next - Install command:
npm install
You generally do not need to change any of these for a standard Next.js app. If you have environment variables (database URLs, API keys), add them here in the "Environment Variables" section before deploying.
Step 4: Deploy
Click "Deploy." Vercel clones your repository, runs npm install, runs next build, and deploys the result to its global CDN. The whole process takes approximately 30–90 seconds for a typical Next.js app.
Step 5: Get your URL
When the deployment finishes, Vercel shows you a URL like your-project-name.vercel.app. Click it. Your app is live.
Environment Variables in Vercel
Every real app has secrets it needs to keep out of the codebase: database connection strings, API keys, payment processor keys. In Vercel, you manage these in the project's Settings.
Go to your project → Settings → Environment Variables.
You will see three scopes:
- Production — values used when deploying the main branch (what real users see)
- Preview — values used for pull request preview deployments
- Development — values pulled down when you run
vercel devlocally (optional)
For a typical Next.js app you would set something like:
| Variable | Production value | Preview value |
|---|---|---|
DATABASE_URL | postgresql://prod-server/myapp_prod | postgresql://staging-server/myapp_staging |
STRIPE_KEY | sk_live_xxx | sk_test_xxx |
NEXTAUTH_SECRET | a long random string | a different long random string |
This is the environment separation pattern covered in the guide to production, staging, and development environments. Vercel makes it easy by building environment scoping directly into the dashboard.
Preview Deployments: The Killer Feature
Every time you open a pull request on GitHub, Vercel automatically builds and deploys that branch to a unique URL that looks like:
your-project-git-feature-branch-name-your-username.vercel.app
This URL is posted as a comment on your GitHub pull request. You can click it and see exactly what the change looks like in a real browser, with real environment variables, before merging.
This is enormously useful for:
- Reviewing UI changes without pulling the branch locally
- Sharing a work-in-progress with a designer or client before it is merged
- Running manual QA on a specific feature branch
- Getting stakeholder sign-off before a release
Preview deployments use the "Preview" environment variable scope, which means you can configure them to hit a staging database instead of production — giving you a full staging environment automatically for every pull request.
Custom Domains
Once your app is live on .vercel.app, adding your own domain takes about five minutes.
- Go to your project → Settings → Domains
- Type your domain (e.g.,
myapp.com) and click Add - Vercel shows you the DNS records to add at your domain registrar (usually an A record and a CNAME)
- Add those records at wherever you bought your domain (Namecheap, Cloudflare, Google Domains, etc.)
- Wait for DNS to propagate — anywhere from a few minutes to 48 hours, though usually under an hour
- Vercel automatically provisions an SSL certificate. Your site is now live at
https://myapp.com
Vercel also supports subdomains (api.myapp.com, www.myapp.com) and wildcard domains (*.myapp.com for multi-tenant apps).
The Vercel CLI (Optional but Useful)
Vercel has a command-line tool that lets you deploy and preview from your terminal.
Install it:
npm install -g vercel
Authenticate:
vercel login
Deploy a preview (from your project directory):
vercel
Deploy to production:
vercel --prod
Run your app locally using the linked project’s development configuration:
vercel dev
vercel dev is particularly useful because it loads your environment variables from Vercel's dashboard, so you do not need to maintain a local .env.local file manually.
Serverless Functions
If you have ever written a Next.js API route — a file at app/api/something/route.ts — that file automatically becomes a serverless function when deployed to Vercel. You do not configure anything. It scales automatically. You pay only for the compute time it uses.
The default runtime is Node.js. You can also opt into Vercel's Edge Runtime, which is a leaner JavaScript runtime that runs at the CDN edge (geographically close to your users) with lower latency but fewer Node.js APIs available.
Use Node.js runtime for:
- Database queries
- Anything that needs full Node.js APIs (
fs,crypto, etc.) - Functions that call external services with complex SDKs
Use Edge Runtime for:
- Simple request transformation
- Authentication checks
- Geolocation-based routing
- Anything where sub-100ms response time matters
Specify the runtime at the top of your route file:
export const runtime = 'edge'; // or 'nodejs' (default)
When to Upgrade From Free
Choose a plan based on eligibility, team needs, expected usage, and required features. A commercial project may need a paid plan even before it approaches a bandwidth or compute allowance. A personal project may stay on Hobby while remaining within its supported use and limits.
Before upgrading, inspect current plan documentation and your actual usage. Distinguish the subscription from metered charges, and set the appropriate usage controls for your account. Plan names and listed prices alone do not determine the cost of an application that calls external APIs or uses paid storage.
Alternatives to Vercel
Netlify — nearly identical to Vercel for frontend deployments. Strong ecosystem, slightly different DX. Worth knowing if Vercel's pricing becomes a factor.
Railway — better choice when you need persistent servers, background workers, or databases. Vercel uses serverless functions; Railway runs always-on processes. Many teams use Vercel for the Next.js frontend and Railway for the database and any backend workers. The beginner guide to Railway covers that use case in detail.
Fly.io — deploys Docker containers globally with persistent VMs. More control, more configuration, better for compute-intensive workloads.
Cloudflare Pages — similar to Vercel, with strong edge computing support via Cloudflare Workers. Free tier is very generous.
For most beginners building with Next.js, Vercel is the right first choice. It handles much of the deployment infrastructure while you still own application configuration, verification, and usage. You will know when you have outgrown it.
A successful build still needs a live check
Open the deployment and complete the main user flow. Check a page that calls an API, an intentionally invalid input, and any image or download the application needs. A green build means the build completed; it does not establish that production credentials, external services, or browser behavior work.
Compare Preview and Production configuration deliberately. A missing variable can affect only one scope, and an updated value may require a new deployment before the running application uses it. Use the Vercel environment-variable reference when diagnosing that boundary.
Keep the deployed revision identifiable and save the previous working deployment. If a release fails, restore service using the project's deployment workflow and inspect the failing revision separately. Do not confuse rollback with repairing the underlying code or any external state the application already changed.
Before committing to a plan, check Hobby eligibility and current function limits. Workload, runtime, and plan matter more than a fixed timeout copied from an old tutorial.