Tech & AI, Explained

vercel-cli

5 min read

Vercel CLI cheat sheet

Status: 🟩 COMPLETE (🟦 LIVING — Vercel CLI updates frequently) Last updated: 2026-06-21 Plain-English tagline: Daily-use Vercel CLI commands grouped by intent. For the why, read Vercel.

Setup (once per machine)

npm install -g vercel                    # install globally
vercel login                             # authenticate via browser
vercel whoami                            # confirm you're logged in

You don’t actually need the CLI for most day-to-day work — git push triggers deploys via the dashboard. The CLI shines for env vars, logs, and quick one-off deploys.

vercel link                              # interactive: pick org + project
vercel link --yes                        # auto-link to most likely match

After linking, .vercel/project.json stores the IDs. Commit it (the file is harmless) or gitignore it consistently across the team.

Deploy

vercel                                   # deploy current dir to preview (interactive first time)
vercel --prod                            # deploy directly to production
vercel deploy --prebuilt                 # deploy a build you already ran locally
vercel --skip-domain                     # don't alias to the production domain

For most projects, you’ll prefer git push for production deploys (so the commit is the source of truth). Use vercel --prod for emergency hotfixes when CI is broken.

Environment variables

vercel env ls                                              # list all env vars
vercel env ls production                                   # filter by environment
vercel env add SUPABASE_SERVICE_ROLE_KEY production        # add (prompts for value)
vercel env rm SUPABASE_SERVICE_ROLE_KEY production         # remove
vercel env pull .env.local                                 # pull production env into local file
vercel env pull --environment=development .env.local       # pull dev env

vercel env pull is the killer feature. Keeps your local .env.local in sync with what Vercel knows. The pulled file is gitignored by default.

Deployments

vercel ls                                # list recent deployments
vercel ls --meta production              # filter by metadata
vercel inspect <deployment-url>          # full info about one deployment
vercel rollback <deployment-url>         # promote a previous deployment to production
vercel rm <deployment-url>               # delete a deployment

You can do all of this in the dashboard too — the CLI is just faster for habitual users.

Logs

vercel logs <deployment-url>             # function logs for one deployment
vercel logs --follow                     # tail recent deployment logs in real time
vercel logs --since 1h                   # last hour

Domains

vercel domains ls                                          # list your domains
vercel domains add stmarkbible.com                         # add a domain to your account
vercel alias <deployment-url> stmarkbible.com              # point a domain at a deployment
vercel domains buy <name>.com                              # buy via Vercel Domains

DNS

vercel dns ls stmarkbible.com                              # list DNS records
vercel dns add stmarkbible.com @ A 76.76.21.21             # add a record
vercel dns rm <record-id>                                  # remove

Most projects don’t need this — Vercel auto-manages DNS when you use Vercel Domains.

Functions / runtime

vercel dev                               # run your app locally with Vercel-like env
vercel build                             # produce the build that gets deployed

vercel dev differs from npm run dev — it simulates Vercel’s serverless/edge environments more faithfully. For Next.js projects you typically don’t need this; npm run dev is enough.

Common workflows

Pull production env into local dev

vercel link                              # if not already linked
vercel env pull .env.local
# now your local app uses the same env as production

Promote previous deployment (production rollback)

vercel ls --prod                         # find the last good production deployment URL
vercel rollback <good-deployment-url>    # instant rollback

(You can also do this with one click in the dashboard’s Deployments tab.)

Quick hotfix deploy without going through CI

# (fix code locally)
npm run build                            # confirm it builds
vercel --prod                            # deploy straight to production
# (then commit + push to keep main in sync)
git add -A
git commit -m "Hotfix: ..."
git push

This bypasses CI; use only when CI is broken and you need to ship now.

Common gotchas

  • vercel link is required before most commands. Run it once per project clone.
  • .vercel/ folder contains project IDs, not secrets. Committing it is fine; some teams gitignore it.
  • vercel env pull overwrites .env.local. If you have local-only env vars, set them up separately (the file overwrites entirely).
  • vercel dev doesn’t fully match production. It’s closer than next dev, but for the highest-fidelity test, deploy a preview and use that.
  • vercel --prod bypasses CI checks. Don’t use it as the normal path — git push is safer because it runs all your checks.
  • Function logs are limited to recent deployments. For deeper history, use Vercel’s dashboard log search.
  • Domain operations propagate via DNS. Changes can take minutes to hours to show up everywhere.
  • CLI version drift. npm install -g vercel@latest if a command behaves unexpectedly — your CLI might be old.
  • Hobby tier limits apply to CLI deploys. You can vercel --prod from CLI on Hobby, but commercial-use restrictions still apply.
  • The CLI uses your local credentials. Logging in as a different account = different deployments. vercel whoami to confirm.

See also

Sources

Graph View

Backlinks