Deploying the Frontend with Vercel: From Localhost to a Live URL
If you've ever built something on localhost:3000 and felt that flicker of "now what?" — this is the "now what." Vercel is the fastest, most painless way to take a static site or a frontend framework live, and once it's wired up, you'll never zip a build folder and email it to anyone again.
Prerequisites
Your code is already pushed to a GitHub repository (public or private) — this post assumes you know how to do that.
A Vercel account (sign up with your GitHub account — it's one click and saves you a step later).
If you're deploying a framework (React, Next.js, Vite, etc.), it should already build and run correctly on your machine.
That's it. No Git commands here — just the deployment layer on top of code you've already committed.
Why Vercel for the Frontend
Vercel is built by the team behind Next.js, but don't let that fool you into thinking it's Next-only. It happily deploys plain static HTML, React, Vue, Svelte, Astro — basically anything that produces static assets or runs at the edge. You get a global CDN, automatic HTTPS, and zero server management, all on a free Hobby tier that's genuinely usable for real projects (not just toy demos).
Connecting GitHub to Vercel: The CI/CD Magic
This is the part that should make your eyes widen a little. When you import a project into Vercel:
You authorize Vercel to access your GitHub repo.
Vercel auto-detects your framework and pre-fills the build command and output directory.
You click Deploy.
From that point on, Vercel is watching your repository. Every time you push to your main branch, Vercel automatically rebuilds and redeploys — no manual trigger, no FTP, no "let me just upload the new build." This is instant CI/CD, for free.
Even better: push to any other branch or open a pull request, and Vercel spins up a unique preview deployment — a live, shareable URL for that exact branch. Want a teammate or mentor to review a feature before it hits production? Send them the preview link instead of a screenshot.
Environment Variables & Build Config
If your frontend needs API keys or config values, add them under Project Settings → Environment Variables in the Vercel dashboard before you trigger a build — variables added after a deployment won't retroactively apply to it. You can scope variables differently for Production, Preview, and Development if needed.
Standing Out: Attach a Custom Domain
By default, your project lives at yourproject.vercel.app — perfectly functional, but forgettable. Attaching a custom domain (something like yourname.dev) takes about five minutes in the dashboard and instantly makes your portfolio or side project look like a real product instead of a class assignment. Vercel provisions the SSL certificate automatically — you don't manage certs yourself. A .dev domain in particular signals "I ship things" the moment someone sees it on your resume.
Common Pitfalls
Monorepos: if your frontend lives in a subfolder, set the correct Root Directory in project settings, or the build will fail looking in the wrong place.
Missing env vars: a build that works locally but fails on Vercel is almost always a missing environment variable.
Build command mismatches: double-check the auto-detected build command actually matches your
package.jsonscripts.
Up Next
Your frontend is live — but it's not talking to anything yet. In Part 2, we deploy the backend API that actually powers your app, using Render.
