# How to rotate GitHub tokens and deploy keys

> Reissue a GitHub fine-grained personal access token or a deploy key: create the replacement next to the old one, switch, delete, and close what a leaver keeps.

URL: https://crunu.com/rotate/github
Language: en
Updated: 2026-10-30

GitHub has no grace period for tokens or deploy keys, so the overlap comes from holding two credentials at once. For a fine-grained personal access token, generate a new one with the same resource owner, repositories and permissions, move every consumer to it, and delete the old one. For a deploy key, add a second deploy key with a fresh key pair, switch the server to it, then delete the first. Both tokens or both keys work during the switch, so nothing breaks.

Crunu doesn't create, revoke or delete anything on GitHub. It points out which GitHub values a departing person could read, stores the new token or private key as a new environment version, and delivers it to the programs that use it.

*Figure: Timeline of rotating the Fine-grained personal access token. Step 1: a new key is issued while the old one keeps working. Step 2: every place that uses the key is updated, with no downtime because both keys work. Step 3: the old key is revoked. After revocation the old key stops working at once.*

## Personal access tokens

GitHub prefixes every token with its type: `github_pat_` for a fine-grained personal access token, `ghp_` for a classic one, and `ghs_` or `ghu_` for GitHub App tokens ([GitHub docs](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/about-authentication-to-github)). GitHub recommends fine-grained tokens whenever possible. Each is limited to resources owned by a single user or organization, with permissions chosen one by one, while a classic token reaches every repository in every organization its user can access ([managing tokens](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens)).

Facts that change how you plan a reissue:

- **Approval can delay the switch.** An organization can require approval for fine-grained tokens. Until an owner approves it, a new token is marked pending and can only read public resources. Get the approval before production depends on the token.
- **Lifetime is your choice.** Tokens without an expiration are allowed unless a maximum lifetime policy blocks them, and GitHub highly recommends setting one. An expired or revoked token can't be restored.
- **GitHub revokes some tokens for you.** A token pushed to a public repository or gist is revoked automatically, and so is one unused for a year ([expiration and revocation](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/token-expiration-and-revocation)).
- **There is a ceiling.** One account can create up to 50 fine-grained tokens. For organization automation, GitHub points to a GitHub App instead.

## Reissue a token without downtime

1. Under **Settings** > **Developer settings** > **Personal access tokens**, generate a fine-grained token with the same resource owner, the same repositories and the same permissions as the old one, and an expiration date. Copy it right away.
2. Save it in the Crunu environment that held the old token, for example as `GITHUB_PAT` in `web-app / staging`. The save becomes a new version, and the history shows the changed variable by name.
3. Restart what uses it. Jobs that start through `crunu run` read the newest version at launch; a long-running bot started with `--restart on-change` restarts by itself.
4. Confirm the new token does real work: let the job that depends on it run once, and check that its request isn't pending approval.
5. Delete the old token from the same settings page. From then on it no longer authenticates Git or API requests.

## Reissue a deploy key

A deploy key is an SSH key with access to exactly one repository, read-only unless you allowed write access. You can't reuse one key for several repositories, it has no expiry date, and the private half usually sits on a server without a passphrase ([deploy keys](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/managing-deploy-keys)). To replace one, generate a new pair, add the public key under the repository's **Settings** > **Deploy Keys** > **Add deploy key**, give the server the new private key, test a fetch, and delete the old deploy key.

```sh
ssh-keygen -t ed25519 -C "deploy web-app" -f ./web-app-deploy
```

If the private key lives in a Crunu environment, `crunu pull` puts it on the server with mode 0600. It refuses paths inside `~/.ssh/` unless you pass `--allow-path` for that run, so pick a path outside it or allow it explicitly.

## What a departing developer still holds

This is where GitHub differs from most providers: the tokens are tied to the person's own account, which you don't control.

- **Fine-grained tokens.** Organization owners can view every fine-grained token that can reach organization resources and revoke its access. The token isn't deleted: it keeps read access to public resources, and SSH keys created by the token keep working. Its creator gets an email ([reviewing tokens](https://docs.github.com/en/organizations/managing-programmatic-access-to-your-organization/reviewing-and-revoking-personal-access-tokens-in-your-organization)).
- **Classic tokens.** Owners can't revoke them from that page. Unless the organization restricts classic tokens, they reach organization resources until they expire.
- **Deploy keys.** They aren't linked to membership, so a deploy key the person added stays active after they're removed. And if a token was used to create a deploy key, deleting that token deletes the deploy key as well, so check before you delete a leaver's automation token.

In Crunu, removing the person yields a reissue checklist of the values they received, such as a shared bot token or a deploy private key. [What to rotate when a developer leaves](https://crunu.com/guides/developer-offboarding-secret-rotation) gives the full order of work, and the [offboarding checklist](https://crunu.com/tools/offboarding-checklist) builds the list for your stack. Reissuing on a schedule follows the same steps, and expiration dates make sure it actually happens.

## FAQ

### Can an organization owner revoke a former member's personal access token?

Partly. Owners can revoke the access a fine-grained token has to the organization, and the token's creator gets an email. The token itself isn't deleted and can still read public resources. Classic tokens can't be revoked from that page.

### Do deploy keys stop working when the person who added them leaves?

No. A deploy key belongs to the repository, not to a person, so it stays active after its creator is removed. If they could read the private key, generate a new pair, add it as a new deploy key and delete the old one.

### Do GitHub personal access tokens expire on their own?

Only if they were given an expiration date. GitHub allows tokens without one unless a maximum lifetime policy blocks it, and it automatically removes tokens that haven't been used for a year.

### Does Crunu revoke GitHub tokens or deploy keys?

No. Crunu doesn't call GitHub. It lists the GitHub values a departing person received, stores the replacement token or private key as a new environment version, and hands it to your programs through crunu run or crunu pull.

## Sources

- [GitHub Docs: Managing your personal access tokens](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens) (accessed 2026-10-30)
- [GitHub Docs: Token expiration and revocation](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/token-expiration-and-revocation) (accessed 2026-10-30)
- [GitHub Docs: About authentication to GitHub](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/about-authentication-to-github) (accessed 2026-10-30)
- [GitHub Docs: Managing deploy keys](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/managing-deploy-keys) (accessed 2026-10-30)
- [GitHub Docs: Reviewing and revoking personal access tokens in your organization](https://docs.github.com/en/organizations/managing-programmatic-access-to-your-organization/reviewing-and-revoking-personal-access-tokens-in-your-organization) (accessed 2026-10-30)