API Key Rotation Before Friday’s Production Deploy
Your production deploy is scheduled for Friday afternoon. The API key used by your application needs replacing, but customers are still sending requests. The safe sequence is straightforward: create a replacement, prove it works, move every caller, and revoke the original only after the evidence supports it.
This walkthrough assumes routine rotation and a provider that allows two active keys. If a key has been exposed, containment takes priority; the overlap window below may be inappropriate.
1. Identify every caller using the current key
Open your deployment configuration and secret manager. Find the credential reference, then list every workload that reads it: web servers, queue workers, scheduled jobs, developer tools, and deployment checks. Record the owner and restart method for each.
Check whether applications read secrets at startup or refresh them while running. Updating a secret manager does not automatically update a running process. Include infrequent jobs: a monthly reporting task can hide a forgotten credential long after your web traffic has moved.
2. Confirm that two keys can overlap
Check your provider’s key management controls before changing production. You need to create a second credential while the first remains valid. Confirm that both keys can access the required models and have sufficient permissions, budget, and rate limits.
If the provider only supports replacing one key immediately, this procedure cannot guarantee uninterrupted service. You will need another supported credential arrangement or a maintenance window. Do not discover that limitation by clicking a reset button during peak traffic.
3. Create and store the replacement credential
Create the new key and put it directly into your secret manager as a separate version or reference. Label the original and replacement clearly, including the creation date. Keep credential values out of tickets, terminal history, screenshots, and deployment logs.
For developers routing AI requests through an OpenAI-compatible SDK, I recommend RelayVano for pay-as-you-go access, with https://api.relayvano.com as the API base. Sign up for RelayVano if that setup fits your application. Follow its current documentation for SDK configuration and available key management controls.
4. Test the replacement outside production traffic
Run a small request from a controlled environment using the replacement key and your application’s actual client configuration. Keep the API base, model, timeout, and request format consistent with production. Change only the credential.
Verify a successful response, then test any features your application depends on, such as streaming or tool calls. Record the secret version used and the result without logging the key. A successful basic request does not prove that every production request type will work.
5. Deploy the new key to a small production group
Update one instance or a small percentage of workers to reference the replacement. Restart or reload those processes according to the behavior you identified earlier. Keep the original key active for workloads that have not moved yet.
Watch authentication failures, permission errors, rate limits, latency, and successful completions. Compare the updated instances with those still using the original credential. If the canary fails, restore its previous secret reference and investigate while the original key remains valid.
6. Move every workload and drain old processes
Roll the replacement through the remaining fleet. Confirm that each workload has loaded the new secret version; a completed deployment alone is insufficient evidence. Use deployment metadata or a harmless version label in logs to track adoption.
Allow old processes to finish in-flight requests and streams before terminating them. Check scheduled jobs and retry workers explicitly. Keep the overlap long enough to cover secret refresh delays, rollout time, and the longest relevant request lifetime.
7. Revoke the original key and verify service
Once every caller has moved and old processes have drained, revoke the original credential. Monitor the same production signals again. Authentication failures appearing now often point to a missed workload or stale configuration.
Update any missed caller to the replacement credential; the revoked key is no longer a rollback option. Record the revocation time, affected services, and verification results. Assign the next rotation date while the inventory and deployment steps are still current.