Workflow: rotate CI auth tokens without breaking uploads

Workflow: rotate CI auth tokens without breaking uploads

Source-map uploads and release creation authenticate from CI. When that credential rots, every deploy silently ships without maps. Rotate on a schedule, not after a failure.

1. Use organization tokens

Organization tokens are the recommended credential for CI. Personal tokens belong to a user; when that user leaves or rotates their token, every pipeline using it breaks at once. If any pipeline still uses a personal token, migrating it is step zero.

2. Scope minimally

Create the token with only the scopes CI needs: release management and artifact upload for the projects it serves. A token that can also manage org members is a breach waiting for a log leak.

3. Rotate with overlap

1. Create the new token alongside the old one. Both are valid during the overlap.
2. Update the CI secret in one repo, run a full pipeline, and confirm source maps upload and the release associates.
3. Roll the secret update across remaining repos over a few days.
4. Only then revoke the old token.

Never revoke-then-replace. The gap between revocation and secret propagation is exactly when a deploy ships without maps.

4. Keep the inventory

Maintain a list of every repo and pipeline using the token. The rotation checklist is only as complete as the inventory; the repo everyone forgot is the one that breaks.

5. Detect rot automatically

Add a CI step that fails loudly if the upload auth fails, rather than continuing with a warning. A red build gets fixed today; a warning gets fixed never.

Verify

After rotation, the old token is revoked, every pipeline in the inventory has run green with the new token, and a spot check of recent releases shows artifacts attached. Schedule the next rotation now, not when someone remembers.

Researched against live Sentry docs 2026-09-26. The auth tokens page (docs.sentry.io/account/auth-tokens/) documents organization tokens as the recommended credential for CI/CD and notes personal tokens are tied to a user and can fail when the user leaves. The CLI configuration page (docs.sentry.io/cli/configuration/) documents how the CLI consumes tokens via env vars and config files.