Deploying to Vercel

A project that only runs on localhost:5173 is invisible to everyone else, including the people deciding whether to hire you. Deploying turns the Watchlist into a URL you can put on your CV, send to a friend and open on your phone. For a Vite app on Vercel this takes a few minutes, and once it’s set up, every git push deploys automatically.

What you’re deploying

npm run build turns your project into a folder of static files: dist/index.html, one or two JavaScript bundles and a CSS file, with hashed file names like index-B3f9xk2a.js so browsers can cache them forever. There’s no server code. Any static host can serve it; Vercel is popular because it detects the framework, builds on every push and gives you preview URLs for free on the Hobby plan.

Before deploying, check the production build locally:

npm run build
npm run preview

preview serves dist/ on http://localhost:4173. If something breaks only in production, such as a wrong asset path or a missing environment variable, you find out here instead of on the live site.

Option 1: import from GitHub (recommended)

1. Push your project to a GitHub repository. If you committed in the Building the Watchlist lesson, create an empty repository on GitHub and follow its instructions to git remote add origin … and git push -u origin main.
2. Sign in to Vercel with your GitHub account and choose Add New… → Project.
3. Import the watchlist repository. Vercel detects Vite and fills in the build command (vite build, which is what npm run build runs) and the output directory (dist). Leave them as they are.
4. Click Deploy. About a minute later you get a production URL like watchlist-yourname.vercel.app.

From now on, the repository drives deployments:

• Every push to main builds and deploys to production.
• Every push to another branch, and every pull request, gets its own preview deployment with a unique URL, posted as a comment on the pull request.

Preview deployments change how you work. You restyle the filter bar on a branch, open a pull request, and click the preview link on your phone before merging. Production never sees unfinished work.

Option 2: the Vercel CLI

If you’d rather deploy from the terminal, or the code isn’t on GitHub yet:

npm install -g vercel
vercel          # first run: log in, link the project, deploy a preview
vercel --prod   # deploy to production

The first vercel run asks a few questions (scope, project name, which directory) and detects Vite the same way. It creates a .vercel folder that links your directory to the project; keep it out of Git. The CLI is handy for quick experiments. For a project you’ll keep working on, the Git integration is better, because deployments happen without anyone remembering to run a command.

Environment variables

Sooner or later you’ll want configuration, such as an API base URL. Vite exposes environment variables to your code only if they start with VITE_:

const apiUrl = import.meta.env.VITE_API_URL;

Locally, put them in a .env.local file (already git-ignored by the Vite template). On Vercel, add them under Project Settings → Environment Variables, then redeploy, because Vite inlines the values when it builds.

Routing on a static host

The Watchlist has one page, so every request is for / and Vercel serves index.html. If you later add client-side routing with React Router, a URL like /watched exists only inside your JavaScript. Refreshing on it asks the server for a /watched file that doesn’t exist, and you get a 404. The fix is a rewrite that serves the app shell for any path:

{
  "rewrites": [{ "source": "/(.*)", "destination": "/index.html" }]
}

Real files in dist/, such as your JavaScript and CSS, are still served normally; the rewrite only applies when no file matches.

The Watchlist is live. In the last lesson, you’ll look back at what you’ve learned and plan what to learn next.