How to deploy to Vercel from the CLI

Step 01: Install the CLI

npm i -g vercel        # or: pnpm i -g vercel
vercel --version

That is the official install. It runs the same on Windows, macOS and Linux; everything in this guide was run from Git Bash on Windows.

Step 02: Log in and link

vercel login
cd path/to/site
vercel link

vercel login signs you in once, through the browser. vercel link ties the current folder to one Vercel project and writes the IDs into a .vercel/ folder. Keep .vercel/ out of git: it holds your project and team IDs, and a copied .vercel/ folder is how you accidentally deploy one site over another.

Our habit is one deploy folder per site, never the repo itself. The build writes into _deploy/<site>/, and the CLI only ever sees finished files. That also means no framework detection surprises: Vercel serves a folder of HTML as-is.

Step 03: Deploy to production

vercel deploy --prod --yes

--prod sends it straight to the production domain instead of a preview URL, and --yes skips the setup questions so the command works in scripts. Here is a real run, from the scheduled retry we set up after the upload cap blocked three sites on September 30:

Two things in that log are worth knowing. The CLI does not upload every file every time: Vercel caches source files by content, so a redeploy of an unchanged 647-file site uploads only what changed. And the --archive=tgz flag turns the whole folder into one compressed upload (more in step 6).

Step 04: Verify, every time

curl -s -o /dev/null -w "%{http_code}" https://your-site.com/the-page-you-changed/

A deploy that prints "Ready" can still serve a 404 for the page you meant to add (wrong folder, wrong output path, a rewrite eating it). Our publish runbook will not mark anything done until the changed URLs answer 200, and the sitemap lists them.

Step 05: Ship less with .vercelignore

Everything in the folder that is not ignored is public. A .vercelignore file works like .gitignore, and it also supports an allow-list: start with /* to ignore everything in the root, then re-include what you mean to ship with !.

We learned this one the embarrassing way. On one of our sites, an internal go-to-market planning file sat in the deploy folder and was publicly reachable until a .vercelignore entry hid it. Deny-lists fail open; allow-lists fail closed.

Step 06: Big folders need --archive=tgz

The Limits page lists 5,000 uploads per day on Hobby (api-upload-free; 40,000 on Pro). On September 30, 2026 we moved more than a dozen GitHub Pages sites to Vercel in one afternoon. One of them, our tech-oracle dashboard, is about 7,600 files on its own. The cap stopped three sites that day.

The fix is in Vercel's deploy docs: --archive "compresses the deployment code into one or more files before uploading it" and "should be used when deployments include thousands of files." The trade-off, also from the docs: an archived deploy loses the per-file cache, so small redeploys can get slower. Our rule: plain vercel deploy --prod --yes for normal sites, --archive=tgz for anything with thousands of files. A one-time scheduled task re-ran the three blocked deploys with --archive=tgz the next afternoon; all three came back exit=0 and their test URLs answered 200.

Two more ceilings for CLI deploys: 15,000 source files per deployment (above that the deploy fails at the build step) and 100 MB of source on Hobby (1 GB on Pro).

Step 07: Roll back a bad deploy

vercel rollback                    # back to the previous production deployment
vercel rollback <deployment-url>   # Pro: any earlier production deployment

On Hobby, vercel rollback can only go back to the immediately previous production deployment; Pro and Enterprise can pick any deployment that was ever aliased to production. We also keep our own snapshot: the runbook copies the deploy folder before each production deploy, so a rollback never depends on Vercel's history alone.