How to rotate a Vercel access token

Create a new access token on the Account Tokens page with the same scope as the old one, or a narrower one, give it to your CI and scripts, confirm that a request succeeds, and then remove the old token. Tokens are independent, so both work while you switch. Vercel's own advice for replacing a token runs in this order too: issue and distribute the new token before revoking one that is still in use, because any script using a revoked token stops authenticating (Vercel guide).

Crunu doesn't create or remove Vercel tokens, and it has no Vercel integration. It finds the Vercel values a departing person could read, keeps the replacement as a new version of the environment, and passes it to the Vercel CLI and your scripts.

Scope is the decision that matters

Every token has one of three scopes (access tokens):

A project-scoped token is refused for any other project, for team-level resources and for user-level resources. If an old CI token is Full Account and its job deploys one project, the reissue is the right time to narrow it. Team and project tokens also make the teamId parameter unnecessary, because Vercel infers the team and project from the token; Full Account tokens still need ?teamId= to reach a team.

Some teams require two-factor authentication or SAML before you can create tokens scoped to them, and the dashboard tells you when you select the team.

Tokens always belong to a person

You create every token from your personal account settings, even one scoped to a team or a single project. A team's CI token is therefore always someone's token. Vercel's documentation doesn't say what happens to a team or project token when its owner leaves the team, so don't rely on either outcome. When a person who created CI tokens leaves, reissue those tokens from an account that stays, and remove the old ones.

Where the old token hides

Before removing the old token, list its copies. The usual places are a CI secret that runs the Vercel CLI, a --token flag inside a deploy script, a shell profile on someone's laptop, and server code that calls the REST API. Vercel's own example keeps the token in server-side environment variables, never in client-side code. Once each of these runs under crunu run, the next reissue has a single copy to replace: the one in the Crunu environment.

Reissue without downtime

crunu run --env web-app/production -- sh -c \
  'curl -s https://api.vercel.com/v9/projects -H "Authorization: Bearer $VERCEL_TOKEN"'
vercel tokens ls --format json
vercel tokens rm tok_abc123

To create tokens from the command line, vercel tokens create "GitHub Actions deploy" --project prj_abc123 makes a project-scoped token. That command needs a classic personal access token with account-level scope: sessions from vercel login can't create tokens, and team-only or project-only tokens are rejected (vercel tokens). The CLI prints the new value once, to standard output.

When to reissue a Vercel token

• A departure. Reissue the tokens they created for shared automation and any token they could read. In Crunu, removing them produces a reissue checklist of those values by name, with Where to reissue pointing to Vercel's token page.
• A leak. Remove the token at once, then deploy the replacement. Scripts that still hold the old value stop authenticating.
• Expiry. Once the expiration date passes, the token stops working even if nobody revoked it. Put the date in your calendar, or the pipeline will tell you on the day.

What to rotate when a developer leaves covers the full order of work, and the offboarding checklist lists what to reissue for your stack. Tokens are created and removed in Vercel; the record of when the new one reached each environment is kept in Crunu.