# 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:

1.  You authorize Vercel to access your GitHub repo.
    
2.  Vercel auto-detects your framework and pre-fills the build command and output directory.
    
3.  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.json` scripts.
    

## 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.