Playbooks / How to rotate an API key without downtime

Playbook

How to rotate an API key without downtime

Rotating a key means replacing it with a new one and switching the old one off. Done in the right order, your app never notices. Done in the wrong order, production breaks until you find every place the old key lived.

This guide works for most providers: Stripe, OpenAI, Anthropic, Resend, GitHub tokens, cloud access keys and the rest. The rule is the same everywhere: the old key stays active until the new one is proven to work.

Before you start

The steps

  1. Generate a new key. Sign in to the account that owns the key and create the replacement in the provider dashboard, with the same permissions as the old one. Keep the old one active for now.
  2. Save the new value somewhere safe. Many providers only show a secret once. Store it in your password manager or vault before you close the page, not in a chat message or a scratch file.
  3. Update every deploy target. Replace the value in each environment variable that holds it: Vercel, Netlify, GitHub Actions secrets, your server's config. Then update anywhere else you use it.
  4. Redeploy. Most hosts only read environment variables when a build or deployment starts. A changed variable does nothing until you redeploy production (and re-run any workflow that reads the secret).
  5. Verify it works. Deploy or run a request, and check that nothing is failing. Watch your logs and the provider's dashboard for errors in every environment you changed.
  6. Revoke the old key. Only after verifying the new one. This is what makes the rotation count: if the old key ever leaked, it stops working now.
  7. Record the rotation. Note the date and set a reminder for the next one, or for the new key's expiry date if it has one.

Why the order matters

Each step protects the next one. If you revoke first, every request fails until the new key is deployed everywhere. If you skip the redeploy, the new value sits in your settings while the running app keeps using the old one, and revoking breaks production anyway. If you skip verification, you find the place you forgot when customers do.

Some providers let old and new keys overlap for a while after you rotate from their dashboard. That window is a safety net, not a plan: finish the switch and revoke as soon as the new key is confirmed. Provider details are on each provider page, for example Stripe, GitHub and OpenAI.

Places keys hide

Database passwords and domains

Database passwords work differently: many providers stop accepting the old password the moment you reset it. To switch over without downtime, create a second database user with the same permissions, move every connection string to it, verify the app connects, then drop the old user. If you reset the password in place, have every place that uses it ready to update first.

Domains don't rotate, they renew. The same habit applies: renew at the registrar before the expiry date, turn on auto-renew, check that a valid card is on file, and record the new renewal date.

How often to rotate

Rotate right away when someone with access leaves, when a key was shared somewhere it shouldn't be, or when a provider retires a key format. Otherwise, pick a schedule you will actually keep, such as every 90 days for production keys, and set a reminder. Tokens with a fixed lifetime, like many personal access tokens, force the schedule for you: the only question is whether you find out before your deploys fail.

Think the key leaked? That's a different order of work: speed matters more than a clean switch. Follow the leaked API key playbook instead.

Do this in StackHangar

StackHangar runs this same playbook against your own stack. Because your vault already knows which account owns the key, where it's deployed and when it's due, the steps come pre-filled for that key. Rotation reminders tell you when it's time.