Rotating a key without downtime

Rotation replaces a key with a new one. The mechanism is trivial. The sequencing is where people take their site down.

The wrong order

Rotate, then deploy.

Between those two steps your live site is holding a key that no longer exists, and every call is refused. Depending on your deploy time that is anywhere from two minutes to an afternoon, and it is an afternoon on precisely the day your build is slow.

The right order

1. Make the key a runtime value, not a build-time one.
2. Rotate.
3. Update the value.
4. Confirm every server, region and cached build has it.

Step one is the whole trick. With BuildAPI the new key is created *at* rotation, so you cannot literally deploy it beforehand. What you can do is make applying it a one-value change that takes seconds — an environment variable read at runtime, not a constant compiled into a bundle.

If your key is inlined at build time, your rotation window is as long as your slowest build. If it is read at runtime, the window is as long as a config push. Same rotation, two very different afternoons.

When rotation is not optional

• A key has appeared in a public repository. Rotate now and take the gap. It is shorter than the alternative.
• Someone with access has left. Not because you distrust them, but because access that outlives a relationship is how audits go badly.
• You are transferring a key to a different domain. Rotation is part of that flow deliberately: the new domain should not inherit a credential the old domain's operators have seen.

The one that is not an emergency

Scheduled rotation with no incident behind it.

Worth doing. Worth doing calmly, on a Tuesday morning, with somebody watching the error rate — not at five on a Friday because a compliance checklist said this quarter.

Afterwards

Check your usage graph for refusals. A forgotten deployment holding the old key shows up immediately as a wall of invalid_key, and it is much easier to find in the first ten minutes than in a support ticket next week.