Web development

Vercel CLI from the terminal: deploy, logs and environment variables

Install, log in and deploy from the terminal: what vercel link writes, how to read logs, and how a token removes every prompt in CI.

Key points

  • `vercel login` stores the token once; `vercel` ships a preview and `vercel --prod` ships production, with the CLI under Apache 2.0.
  • `vercel link` writes `.vercel/project.json` with `orgId` and `projectId`: a local reference that belongs in `.gitignore`.
  • In CI, `pull`, `build` and `deploy --prebuilt` with `--token` remove every prompt and rebuild the same artefact.

Short answer: from the project root run vercel login once, then vercel for a preview deployment and vercel --prod for production. The CLI does the same work as the dashboard, without a browser.

Install and first deploy

npm i -g vercel@latest
vercel login
vercel
vercel --prod

Login asks you to confirm the email address and stores a token in ~/.vercel. The first vercel asks three questions: scope, project name and folder. From the second run on, the command asks nothing.

The CLI creates a .vercel folder holding project.json, which carries orgId and projectId. They tie the folder to the right project. Put .vercel in .gitignore: it is a local reference, not shared configuration.

Logs and inspections from the terminal

vercel list
vercel inspect https://my-app-abc123.vercel.app
vercel logs https://my-app-abc123.vercel.app

list prints the latest deployments with state and date, inspect shows build, duration and regions, logs follows the runtime logs of that deployment. Those are the three reasons people open the dashboard.

Environment variables, one environment at a time

vercel env add DATABASE_URL production
vercel env ls
vercel env pull .env.local

env add asks for the value and stores it encrypted. env pull writes a local file with the development values: do not commit it, it holds real secrets rather than placeholders.

Non-interactive deploys in CI

vercel pull --yes --environment=production --token=$VERCEL_TOKEN
vercel build --prod --token=$VERCEL_TOKEN
vercel deploy --prebuilt --prod --token=$VERCEL_TOKEN

With a token the CLI opens no prompt: pull fetches the variables, build builds locally, deploy --prebuilt uploads the artefact. The pattern is in the CLI documentation; the CLI code is Apache 2.0 in the vercel/vercel repository.

A named limitation

vercel dev does not reproduce the edge network, the ISR cache or the production execution limits. Behaviour that passes locally can change after the deploy: measure latency on the real domain, not on localhost.

Where to continue

The catalogue holds the Vercel AI Elements library, the system monitor record and the logs table. For the rest read 404 after deploy in App Router, the common build errors and the comparison Vercel analytics or self-hosted.

Frequently asked questions

Do I need a Vercel account to use the CLI?

Yes. The CLI authenticates an account or a team: without login the deploy commands return an authentication error. The free plan is enough for a personal project with preview deployments.

Where does the access token go?

Into a configuration file in the user home folder, under .vercel. It is not in the repository: on a shared machine, log out with vercel logout at the end of the session.

Can I use the CLI without a global install?

Yes. npx vercel runs the same version without a global install, and in CI you should pin the version in package.json rather than depend on the latest release.

How do I read the logs of a deployment already online?

Use vercel logs followed by the deployment URL. The command keeps listening: for a single check, vercel inspect prints build, duration and regions and then exits.

Is a CLI deploy different from a Git deploy?

The artefact is the same, the origin is not: a CLI deploy is not tied to a commit and does not update pull request state. For production, keep one channel rather than two.