What it does
Vercel deploys your Next.js app automatically from GitHub. You push code, your site updates. Zero server management, zero DevOps. Every pull request gets its own preview URL so you can test changes before they go live. Merge to main, and your production site updates within seconds.
Under the hood, Vercel handles everything you'd normally need a DevOps engineer for — SSL certificates, global CDN distribution, serverless function routing, edge caching, and automatic rollbacks if a deploy fails. You focus on building your product. Vercel handles putting it in front of users.
Why we use it
Vercel is built by the same team that makes Next.js. That means zero-config deploys— it knows how to handle server components, API routes, middleware, ISR, and every other Next.js feature out of the box. No Dockerfiles, no nginx configs, no build scripts to maintain.
The free tier is genuinely generous: 100GB bandwidth per month, 100 deployments per day, automatic HTTPS, and a global edge network. Most solo products never outgrow it. When you do need more, Pro is $20/month — not $200.
Preview deployments are the killer feature for solo builders. Every PR gets a unique, shareable URL. You can send it to a friend, test it on your phone, or share it with a beta user — all before a single line hits production.
Setup checklist
Create a Vercel account
Go to vercel.com and sign up with your GitHub account. This is important — signing up with GitHub means your repositories are automatically available for import. No extra OAuth steps or token configuration later.
If you already have a Vercel account with email, you can link your GitHub account in Settings > Git Integration. But starting with GitHub sign-up is the smoothest path.
Import your repository
Click Add New Projectfrom your dashboard, then select your GitHub repo from the list. Vercel auto-detects that it's a Next.js app and configures the correct build settings — framework preset, build command, output directory. You don't need to change anything.
Click Deploy. Your first build takes 1-2 minutes. When it finishes, you'll have a live URL at your-project.vercel.app. That's your app, running in production, with HTTPS and a global CDN. From one click.
Understand the deploy workflow
Here's how Vercel works from this point forward: every push to main triggers a production deploy. Every pull request gets a unique preview URL that updates with each push to that branch. No manual deploys, ever.
Preview URLs are full, working versions of your app with their own environment. You can share them with collaborators, test on mobile, verify API integrations — all before merging. When you merge the PR, Vercel automatically promotes the change to production.
If a production deploy breaks something, Vercel keeps your previous deploy available. You can instantly roll back from the dashboard with one click while you fix the issue.
Configure environment variables
Go to your project Settings > Environment Variables. This is where all your secrets live — API keys, database URLs, webhook secrets, third-party tokens. Never hardcode secrets in your code.
Vercel lets you set different values for three environments: Production, Preview, and Development. This matters. Your Stripe test keys should go in Preview/Development, and your live keys in Production. Same for Supabase URLs if you have separate staging and production projects.
Common variables you'll need: NEXT_PUBLIC_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_ANON_KEY, STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET, RESEND_API_KEY, and NEXT_PUBLIC_APP_URL (your production domain). The NEXT_PUBLIC_prefix makes a variable available in client-side code — only use it for values that are safe to expose.
Set up your custom domain
Go to Settings > Domains > Add. Type in your domain (e.g., yourapp.com). Vercel will give you DNS records to add at your domain registrar — usually a CNAME record pointing to cname.vercel-dns.com, or Arecords if you're using the apex domain.
Vercel handles SSL certificatesautomatically via Let's Encrypt. Both www and non-wwwversions will work — Vercel redirects one to the other based on your preference. DNS propagation can take up to 48 hours, but usually completes in under an hour.
Do this early in your project, even if you're not ready to launch. Sharing a yourapp.com link looks professional. Sharing a yourapp.vercel.applink tells people you haven't launched yet.
Configure preview deployments
Preview deploys are enabled by default for every PR. Each preview gets its own URL like your-project-git-branch-name.vercel.app. Vercel also posts the preview URL as a comment on your GitHub PR automatically.
If your preview deploys need different environment variables (like a staging database or test API keys), set those values with the Preview environment scope in your project settings. This keeps your production secrets completely separate from preview builds.
Set up deployment protection (optional)
If you're building something pre-launch and don't want the public stumbling onto preview URLs, go to Settings > Deployment Protection. You can password-protect preview deployments so only your team can access them.
This is especially useful if you're sharing preview links with beta testers or collaborators but don't want the wider internet to find your work-in-progress. You can also restrict access to Vercel team members only.
Understand Vercel's limits
The free tier includes: 100GB bandwidth per month, 100 deployments per day, serverless function execution with a 10 second timeout, and 100GB-hours of serverless compute. For most solo products, this is more than enough.
The Pro tier ($20/month) bumps the serverless timeout to 60 seconds, gives you 1TB bandwidth, 1000GB-hours of compute, and adds features like password protection and advanced analytics. Upgrade when you hit limits, not before.
The limit most people hit first is the serverless function timeout. If you have API routes that do heavy processing (image generation, large database queries, external API calls), optimize the operation — add caching, reduce database calls, or use edge functions for lightweight operations. Streaming responses reduce time-to-first-byte for the user but the function still runs for the full duration and counts against the timeout. If you genuinely need longer execution, upgrade to Pro for 60-second timeouts.
Configure build settings
Vercel auto-detects these, but it's worth understanding what they are. Go to Settings > General > Build & Development Settings. Framework Preset should be Next.js. Build command: next build. Output directory: .next. Root directory: leave empty unless you're in a monorepo.
The install command defaults to npm install. If you use pnpm or yarn, Vercel detects your lock file and switches automatically. You can also override the Node.js version in your project settings if you need a specific version.
Set up monitoring
Vercel has two built-in analytics tools. Speed Insightstracks Core Web Vitals — how fast your pages load, how responsive they are, and how stable the layout is. Web Analytics tracks page views and visitors without any cookie banners required.
Enable both from your project dashboard. They require zero code changes and give you real performance data from actual users, not synthetic benchmarks. Check them weekly to catch performance regressions before your users notice.
For serverless function monitoring, check the Functionstab in your project. It shows invocation counts, error rates, and execution duration. If a function is consistently slow or erroring, you'll see it here first.
Pro tips
Use vercel env pull from your terminal to sync your Vercel environment variables down to a local .env.local file. This saves you from manually copying values between the dashboard and your local setup. Run it once after adding new variables.
Create a vercel.jsonfile in your project root for rewrites, redirects, and custom headers. This is where you'd add security headers like Content-Security-Policy, HSTS, and X-Frame-Options. These apply at the edge before your app code even runs.
Preview deploys are your secret weapon for client or stakeholder review. Instead of screen-recording a feature, send the preview URL. They can click around, test it themselves, and give feedback on the real thing — not a screenshot.
Always run npm run buildlocally before pushing. A build that fails locally will fail on Vercel too, but you'll waste deploy minutes and time waiting. Catch type errors and build issues at your desk, not in a deploy log.
AI prompt to get started
I'm deploying my Next.js app to Vercel. Help me: 1) Create a vercel.json with security headers (Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options) 2) Set up proper redirects for www to non-www 3) List the environment variables I'll need for Supabase + Stripe + Resend, with which ones need NEXT_PUBLIC_ prefix and which don't 4) Write a pre-deploy checklist I can run through before every production push
Mistakes to avoid
- ✕Forgetting environment variables — the #1 cause of "works locally, broken in production". Double-check every variable your app reads is set in Vercel
- ✕Not testing preview deploys before merging — preview URLs exist specifically so you can catch issues. Click through the preview, don’t just check if the build passed
- ✕Deploying without running the build locally first — run npm run build before pushing to catch type errors and build failures at your desk
- ✕Using next export when you need dynamic features — Vercel handles SSR, ISR, and API routes natively. Don’t fight it with a static export
- ✕Not setting up a custom domain early — sharing a .vercel.app URL signals you haven’t launched. Get your real domain configured from day one
- ✕Not checking your function logs in the Vercel dashboard — when things break in production, the Functions tab shows exactly which function failed and why