How to rotate a Cloudflare API token

Create a second API token with the same permissions as the one you're replacing, switch your deploy scripts and services to it, confirm it works, and then delete the old token. Two tokens can live side by side, so nothing has to stop. The quicker Roll action does something different: it keeps the token's permissions, issues a new secret and invalidates the previous one (Cloudflare docs). Anything still holding the old value fails until you update it, which is fine for a leak and a nuisance for a planned change.

Crunu doesn't create, roll or delete Cloudflare tokens, and it has no Cloudflare integration. It tells you which tokens a departing person could read, keeps the replacement as a new version of the environment, and passes it to the commands that need it.

Three kinds of Cloudflare credential

Which procedure you follow depends on what you are holding.

• User API token, created under My Profile > API Tokens. It acts on behalf of one person and inherits a subset of their permissions. New tokens use a scannable format with the cfut_ prefix, so credential scanners can recognize a leaked one (create a token).
• Account-owned token, created under Manage Account > API Tokens by someone with API Token Provisioning rights or Super Administrator status. It acts as a service principal with its own permissions, starts with cfat_, and is meant for long-running integrations such as CI/CD, so it keeps working after the person who configured it has left (account tokens). Super Administrators see all of them; other members see only their own.
• Global API Key, a legacy credential with exactly the same permissions as its user. Only one can exist per user, so there is no overlap to work with: Change replaces it outright. Cloudflare says it isn't recommended for new customers and asks existing ones to move to API tokens (Global API Key).

If your production deploys run on someone's user token or Global API Key, a departure is a good moment to move them to an account-owned token.

Reissue without downtime

crunu run --env web-app/production -- sh -c \
  'curl -s https://api.cloudflare.com/client/v4/user/tokens/verify -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"'

The verify endpoint shown here is the one Cloudflare documents for checking the status of a user token.

Roll when it leaked, create when it didn't

Rolling is the right move when a token may be in the wrong hands. It invalidates the previous value, and the replacement uses the scannable format, so an older token that predates the prefix gains it on the way. Accept that every consumer fails until it has the new secret, and update production first.

For a planned reissue, after a departure or on a schedule, creating a twin is calmer. Both tokens work while you switch, and you can compare their use before deleting the old one.

When to reissue Cloudflare credentials

• Someone leaves. List the user tokens they created under their own profile, the account tokens they created or could read, and their Global API Key if they ever shared it. In Crunu, removing the person produces a reissue checklist of the values they received, with a link to Cloudflare's token page next to recognized Cloudflare values.
• A leak. Roll the token at once, then look at what changed in the zones it could edit.
• A narrower scope. If a token turns out to be broader than its job, a reissue is a cheap way to fix it: the new token gets only the zones and permission groups it needs, a client IP filter for your CI or office ranges, and a TTL.

What to rotate when a developer leaves covers the order of work for a whole departure, and the offboarding checklist builds the list for your own tools.

Crunu records who saved each new version of the environment and when, so the switch to the new token is traceable. Creating, rolling and deleting the token on the Cloudflare side remain your steps in the dashboard.