Deploy to Vercel using CLI with token authentication

Vercel CLI with Tokens guides deployment and project management without relying on vercel login. It starts with credential discovery, then establishes the intended team and project before choosing a deployment path. Beyond deployment, it covers environment variables, domain management, deployment inspection, runtime and build logs, and troubleshooting.

The credential workflow checks whether VERCEL_TOKEN is configured, then looks for an approved local environment-file entry under that name or another Vercel-related variable. A missing or expired token requires private configuration or rotation rather than disclosure in chat. The instructions keep the token in the environment and prohibit passing it as a command-line token argument.

Project targeting can use VERCEL_ORG_ID together with VERCEL_PROJECT_ID. Both must be set; supplying only one produces an error. When those identifiers are available together, the CLI can target the project without a local .vercel directory. Otherwise, the workflow checks the existing Git remote and local link files before linking.

Use this skill for requests to deploy to Vercel, configure its CLI, add environment variables, or manage a project using access tokens. Default to preview deployments and use production only when explicitly requested. Confirm deployment authority even for previews, because previews can expose code or data and incur costs. A command's automatic-confirmation flag does not establish permission.

Git-backed deployment requires approval before pushing. For a linked repository, a push triggers Vercel's build, and non-production branches receive preview deployments. Without a Git remote, the workflow uses a scoped CLI deployment. For remote repositories, it describes cloning, linking, and then selecting Git or CLI deployment according to access.

Do not detect an unlinked project's state by invoking commands that prompt or silently create a link. Inspect the local link files first. Listing deployments is safe in an unlinked directory and defaults to the scope's deployments; the identity command is safe anywhere.

Inputs include the configured token, team scope, project identifiers or project name, repository location, and intended environment. Linking by repository uses the Git remote to find a matching Vercel project and creates .vercel/repo.json. Plain linking creates .vercel/project.json. Read the stored orgId to confirm team selection, and let the CLI manage these files.

Deployment output includes a URL that must be inspected after readiness. A queued or no-wait result needs an authorized read-only HTTP or browser check before it counts as live completion. Build-log inspection requires Vercel CLI v35 or later; runtime logs follow requests by default, with a no-follow option for a single snapshot. JSON-formatted deployment listings support structured follow-up.

The environment-variable workflow adds values for all environments or a specific production, preview, or development target; lists entries; pulls local settings; and removes variables. Domain handling distinguishes a linked directory from an unlinked directory, where the project is an additional positional argument.

For a project with a Git remote, repository-based linking is shown as:

vercel link --repo --scope <team-slug> -y

Stripe Projects can manage Vercel plan changes. Confirm the resource's actual local name and obtain authorization before paid upgrades or destructive downgrades. Historical plan allocations require checking current official terms. Troubleshooting covers authentication, wrong-team selection, missing dependencies or environment values, framework configuration for Next.js, Remix, and Vite, and installation of the Vercel CLI.