Deploy from the CLI

vercel deploy, or just vercel, uploads the current folder and creates a Preview deployment. Add --prod and it targets Production instead. That one flag is the whole difference between a safe experiment and a live release, so let’s be deliberate with it.

When the CLI makes sense

Git integration covers most projects. The CLI is for the rest: a repository on a Git host Vercel can’t connect to, a quick experiment you don’t want to push, or a deploy step inside your own automation. It can also build locally with --prebuilt and upload only the output, which is useful in CI.

Preview first

From the linked Field Notes folder:

npx vercel@latest deploy

The CLI uploads the files, waits for the build, and prints two URLs. One is the unique deployment URL, something like https://field-notes-3h7kq9p2d-flavio.vercel.app. The other is the inspect URL for the dashboard. Save the first one. Open it, run through the smoke checks, read the build log if anything looks off.

Only when that artifact is good:

npx vercel@latest deploy --prod

Then confirm the production domain really moved:

npx vercel@latest inspect field-notes.vercel.app

Don’t type --prod by reflex. Preview, inspect, then promote.

The CLI deploys your folder, not your commit

This is the trap. Git deployments build a commit. CLI deployments upload whatever is on disk, including edits you haven’t committed and files Git ignores.

So before every CLI deploy, run git status. If the tree isn’t clean, you’re about to ship something that exists nowhere else. Sometimes that’s what you want. If so, write down the commit and what differs, because the next Git push will build without your local change and silently undo it.

Check the link too. .vercel/project.json decides where the upload goes, and the terminal won’t warn you if it’s the wrong project.

In automation

Pin the CLI version in scripts. @latest is fine on your laptop, but a CI job should name a specific version and bump it on purpose. A CLI that changes behavior in the middle of a release is not a surprise you want.

If a CLI release goes wrong, move traffic back to the recorded known-good deployment, then either commit the local change or throw it away. Don’t leave the folder and the repository disagreeing.

Try this on your own project: change a visible build label in the footer, deploy it with npx vercel@latest deploy, check the returned URL, and then decide whether that exact source deserves --prod.