How to Rotate API Keys Without Downtime

You know you should rotate your API keys. Your security audit says so. Your compliance framework requires it. That blog post about the $73,000 AWS bill from a leaked key convinced you. But every time you think about actually doing it, a voice in your head says: "What if something breaks?"

That fear is rational. A botched key rotation can take down production faster than most security incidents. If you update the key in your application but the service provider still has the old key, or vice versa, your service stops working. For APIs that handle payments, authentication, or critical data, even 60 seconds of downtime is unacceptable.

The good news: zero-downtime key rotation is a solved problem. Here is the pattern.

The Dual-Key Rotation Pattern

The core idea is simple: instead of swapping one key for another in a single atomic operation (which is impossible across distributed systems), you overlap two valid keys during the transition period.

Step 1: Generate a New Key

Create a new API key from the service provider while keeping the old key active. Most providers (Stripe, AWS, SendGrid, OpenAI) support having multiple active keys simultaneously.

At this point, both the old key and the new key are valid. Your application is still using the old key. Nothing has changed in production.

Step 2: Deploy the New Key to Your Application

Update your application configuration to use the new key. If you use environment variables (which you should), update the variable in your secrets manager, CI/CD pipeline, or deployment platform.

Deploy the change. During the rolling deployment, some instances will use the old key and some will use the new key. Since both keys are valid, all instances continue to work.

Step 3: Verify the New Key Is Working

Monitor your application after deployment. Verify that API calls are succeeding with the new key. Check logs, error rates, and response times. Give it enough time to be confident (at least one full request cycle across all services).

Step 4: Revoke the Old Key

Once you are confident the new key is working everywhere, revoke the old key at the service provider. This is the point of no return, but by now you have already verified that the new key works.

Step 5: Document the Rotation

Record when the rotation happened, which key was replaced, and who performed it. This audit trail is essential for compliance and for debugging if issues arise later.

The Timeline

The entire process should be planned to minimize risk:

T+0:    Generate new key (both keys active)
T+5m:   Update application config with new key
T+10m:  Deploy to staging, verify
T+30m:  Deploy to production (rolling)
T+60m:  Monitor, verify all services using new key
T+24h:  Revoke old key (after full confidence)

The gap between deploying the new key and revoking the old key is your safety window. If anything goes wrong with the new key, you can roll back to the old key instantly because it is still active.

Handling Services That Only Allow One Key

Some API providers only allow one active key at a time. This makes zero-downtime rotation harder but not impossible:

Option A: Maintenance Window

Schedule a brief maintenance window. Generate the new key (which immediately invalidates the old one), update your application, and deploy. The downtime is the deployment time.

Option B: Proxy Pattern

Route API calls through a proxy service you control. Update the proxy's configuration with the new key. The proxy handles the key swap without requiring a full application deployment.

Option C: Feature Flag

Use a feature flag to control which key your application uses. Deploy the code with the new key as an alternative. Flip the flag to switch keys. If problems occur, flip back.

Automating Rotation

Manual rotation works but does not scale. If you have 50 API keys across 10 services, manual rotation every 90 days means someone is rotating a key almost every week. Automation is essential.

What to Automate

Using ConfigShield for Rotation

ConfigShield stores your secrets centrally, so updating a key means changing it in one place. Every service that pulls from ConfigShield gets the new key on its next deploy or restart.

The workflow:

# Update the secret
configshield set --project my-app --env production STRIPE_SECRET_KEY=sk_live_new_key

# Deploy services (they pull latest secrets on startup)
# Verify everything works
# Revoke old key at the provider

The audit trail in ConfigShield shows exactly when the key was changed, by whom, and which services have pulled the new value.

How Often Should You Rotate?

Industry best practices suggest:

• •Immediately if a key may have been compromised
• •Every 90 days for production API keys (NIST recommendation)
• •Every 30 days for highly sensitive keys (payment processors, root credentials)
• •On every team change when someone with access leaves

The harder rotation is, the less often it happens. If rotation is a one-command process, doing it every 90 days is trivial. If it is a manual, multi-hour process, it will be perpetually delayed.

Start Making Rotation Easy

The biggest barrier to key rotation is not technical knowledge — it is the friction of updating keys across multiple systems. A centralized secrets manager eliminates that friction.

ConfigShield gives you one place to store and update secrets, with CLI access for every service that needs them. Rotation becomes: update once, deploy, verify, revoke.