How to Rotate API Keys Without Downtime After a Leak

How to rotate API keys without downtime: create the replacement first, deploy it everywhere the old key is used, confirm traffic has moved to it, then revoke the old key and review what it did while it was exposed. Revoke immediately instead only when you have evidence of misuse, and accept the outage. Railway's security disclosure of 21 October 2026, which asked every customer to "immediately roll all environment variables, including any API keys", is the reason many small teams are doing this right now.

Disclosure: ZeroRaised publishes this guide and appears in the final section. Steps and limits come from each provider's own documentation as fetched on 22 Oct 2026, and from Railway's disclosure and follow-up guides. Dashboards and defaults change, so check the linked page before you act on a live key. This is general guidance, not a security audit of your system. ZeroRaised has no affiliate deal with any company named here.

TL;DR#

If you have evidence a key is being abused, revoke first and fix what breaks afterwards. The sections below cover each step, provider differences and prevention.

What happened: Railway's security disclosure, 21 October 2026#

On 21 October 2026 (the post shows "Oct 21, 2026"; its published timestamp is 20:44 UTC), Jacob Cooper published Security Disclosure: Wednesday October 21st on the company blog. Railway is a hosting platform many solo makers use to run apps and databases, and environment variables are where those apps keep their keys.

The post says Railway "detected anomalous activity involving systems that store customer environment variables", and that its investigation so far "indicates that an unauthorized third party may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents." It adds that "Environment variables may contain secrets such as API keys or database and registry credentials", and that Railway believes the attack is "part of a series of attacks recently targeting platform companies with the aim of compromising AI inference providers" (Railway disclosure).

Railway says its initial analysis "suggests the impact may be limited to a subset of users", but it asked everyone to act anyway: roll all environment variables and private registry credentials, and "review logs for those services for unusual activity." It also said that "All deployments are paused while we investigate", and that it had notified upstream providers "to revoke all keys proactively."

The next day Railway published a set of provider-specific guides, written by Mykal Machon, for Stripe, OpenAI, Anthropic, AWS and several databases. Each one follows the provider's own incident guidance, so they are useful even if you have never used Railway.

Two details from the incident shape the advice below:

• You may not be able to deploy when you need to. Rotating a key usually means changing a variable and redeploying. On 22 October, Railway's status page said "Builds remain available for Pro and Enterprise workspaces" while it worked on "enabling builds for Hobby, then Free and Trial." A team on those plans could create new keys but not ship them.
• Providers may revoke keys for you. If an upstream provider kills a key before you have replaced it, your product breaks on their timetable, not yours.

We do not know how many accounts were affected; Railway says it will contact affected customers directly. Nothing here suggests other hosts are safer. The point is narrower: any service that holds your secrets can have a bad day, so rotation has to be quick.

How to rotate API keys: the order that avoids downtime#

The safe order is the same at every provider. The common mistake is revoking first, then finding that a cron job, a staging site and a laptop all used the key.

List every place the key lives#

Write down each service, each environment (production, preview, staging), CI and deploy pipelines, local .env files, and any third-party tool you pasted the key into. Stripe's best practices page says periodic rotation "confirms that you know where each key is used and that your team can replace a key on short notice." Anthropic's key guide adds that when you upload a key to a web-based IDE, cloud provider or CI platform, "you are giving the developer of that tool access to your Claude Console account." Those tools belong on the list.

Decide between rotating and revoking now#

Stripe draws the line clearly (best practices): "Exposure means the key became visible somewhere it shouldn't have been, such as a public repository, a log file, or an email", while "Compromise means there's evidence of unauthorized use of the key." Either way, rotate immediately "even if you aren't sure anyone saw it." What changes is how long the old key may live. Railway's Stripe guide says that for a confirmed leak you pick "Now so the old key is deleted immediately", and for a precautionary rotation "a window long enough to redeploy and verify." A short outage costs less than an attacker issuing refunds on your account.

Create, deploy, confirm#

Create the new key in the same project or workspace with the same or narrower permissions, and copy it straight into your secret store. Several dashboards show a new secret only once: Stripe displays a new live secret key "one time before you save it" (Stripe keys), and Railway's guides note the OpenAI dashboard and Claude Console do not show a new key again.

Then update the variable everywhere on your list and redeploy. On most hosts a changed variable does nothing until the next deployment; Vercel's docs say changes "are not applied to previous deployments, they only apply to new deployments." Check your app logs and, where offered, the provider's per-key logs. Stripe suggests you expire the old key "only after its request volume has been at zero for a few hours or days" (Stripe keys).

Revoke, then review#

Delete, expire or deactivate the old key. Until you do, anyone holding it can still use it. Prefer a reversible option first where there is one: Railway's AWS guide says to "Deactivate first rather than delete, so you can reactivate briefly if a service you forgot about breaks." Then review what the old key did, which has its own section below.

Provider by provider: what rotation looks like#

The key difference is whether old and new keys can work side by side. Where deletion is instant, deploy the new key before you press delete.

Stripe#

Stripe's key docs say that when you rotate in the Dashboard, "both the old and new keys work for up to 7 days"; if you need longer, "create a new key manually, migrate to it, then expire the old one". Two details catch people out. Webhook signing secrets are separate, so rotating an API key leaves them unchanged; Railway's Stripe guide says to update that variable too if you rotated it. And the same guide says to "Rotate every other secret and restricted key on the account too", not only the one you know about. A pk_ key in your frontend is not a leak: Stripe says "Only publishable keys are safe to expose outside your application's backend."

OpenAI and Claude#

Both delete keys instantly, so create and deploy the replacement first unless you are cutting off active misuse. Railway's OpenAI guide notes that project keys and legacy user keys "live on different pages", so check both. Its Anthropic guide gives the Claude Console steps: confirm the workspace, select "Delete API key", and create a replacement scoped to the same workspace.

Both companies also catch some leaks for you. The OpenAI guide says "OpenAI disables keys it finds on the public internet or inside published apps." Anthropic's help article says that if a Claude key "is detected in a public GitHub repository, GitHub immediately notifies Anthropic", which "automatically deactivates the exposed API key" and emails you. If that email arrives, your app is already failing, so deploy the replacement first and review usage second.

Supabase#

Supabase's API key docs say it "is deprecating the anon and service_role keys by the end of 2026" in favour of publishable and secret keys, and warn that "A leaked secret key exposes all of your project's data" because it bypasses Row Level Security. Its leak procedure starts with "Don't rush. Fix the root cause of the leak before you rotate anything." Then create a new secret key, replace the old one everywhere, confirm every component uses it, and retire the old one. Deleting a secret key "can't be undone"; deactivating a legacy key "is reversible, so you can re-enable them if you find a client you missed."

AWS and Google Cloud#

AWS allows "a maximum of two access keys per user", which is what makes an overlap possible, and recommends that you "use temporary security credentials (such as IAM roles) instead of creating long-term credentials like access keys." Google's service account key guidance pushes the same way, and explains why rotation matters: "If a key is leaked, it might take bad actors days or weeks to discover the key."

Keys that are meant to be public#

Supabase publishable keys are "Safe to expose online", with access controlled by Row Level Security (Supabase). Firebase says "API keys restricted to Firebase services do not need to be treated as secrets", but tells you to "never include the Gemini Developer API in the allowlist for a publicly accessible API key" (Firebase docs). A browser key that can call Gemini is a secret that has already leaked.

After you rotate: check what the old key did#

Anything done with the old key before you revoked it still stands. A paid API key can run up a bill. A payment key can issue refunds, add a bank account or create a webhook that copies your events elsewhere. Work out the exposure window, from the earliest moment the key could have leaked to the moment you revoked it, and check that period.

Railway's guides each end with a misuse review based on the provider's own advice. For Stripe, look in the old key's request logs for "IP addresses, endpoints, and request volumes that don't match your integration", then check payments, payouts, bank accounts and webhooks, because "An attacker-added endpoint receives a copy of every event" (Railway Stripe guide). For Claude, group usage by key and compare the model mix: "If a key you only use with one model suddenly shows another, that's a strong signal" (Railway Anthropic guide).

If you find activity you did not generate, save the logs and contact the provider's support. Railway's Anthropic guide says to "save the usage and cost data you found and contact Anthropic support", and its OpenAI guide gives the same advice for OpenAI.

Revoke before you rewrite Git history#

If the leak was a commit, the instinct is to scrub history. GitHub's secret scanning docs put the priority the other way round: "rotate the affected credential immediately to prevent unauthorized access. While you can also remove secrets from your Git history, this is time-intensive and often unnecessary if you've already revoked the credential."

Where your keys live: hosts, CI and your laptop#

Most small products keep keys in three places: the host's environment variables, the CI or deploy pipeline, and a .env file on a developer's machine. Each needs its own step during a rotation.

On your host#

Environment variables are the standard way to hand keys to an app, but the host is one more party holding the values, which is the lesson of the Railway incident. Two host features make rotation faster:

• Shared variables. Railway's shared variables are defined once in project settings and referenced by each service. Its Stripe guide points out that you then "edit it once in Project Settings and every service that references it picks up the change." Pasted copies have to be found one by one.
• Write-only secrets. Vercel's docs say "Secret values are write-only after saving. Use them for passwords, API keys, and tokens." Nobody with dashboard access can read them back.

When you cannot deploy#

The Railway incident showed the awkward case: a host asks you to rotate, but its deploys are paused or limited. When Railway's status page was checked on 22 Oct 2026, builds were available for Pro and Enterprise workspaces, with Hobby, Free and Trial still to follow. If you are stuck like that:

1. Revoke the most dangerous keys anyway. A payment or cloud key that can move money or create servers is worth an outage. Let that feature fail until you can deploy.
2. Cap what a key can spend. Anthropic recommends spend limits and rate limits as "a safeguard against unexpected usage due to leaked keys or errant scripts" (Anthropic key guide). OpenAI says a hard spend limit stops "affected API traffic when tracked spend reaches the limit" (OpenAI production guide).
3. Narrow where a key works. Stripe access policies can restrict a key to "one or more specific IPv4 addresses or CIDR ranges" (Stripe keys).

These buy time. They do not replace rotation.

In CI and on laptops#

Deploy pipelines often hold your most powerful credentials: registry tokens, cloud keys and the host's own deploy token. Railway's disclosure named "private registry credentials" alongside API keys, so rotate CI secrets with the rest. Locally, Anthropic says that if you use dotenv, "you must add your .env files to your source control ignore file". Update your own .env after a rotation too.

If you built quickly with AI tools, our vibe coded app security checklist covers finding secrets in bundles, logs and history before launch.

How often to rotate API keys, and when to do it today#

There are two kinds of rotation: the one an event forces on you, and the one you schedule so the forced one goes smoothly.

Rotate now when a key has appeared anywhere it should not (a public repo, a log, a screenshot, a support ticket), when a host or tool holding it reports a breach, when a provider tells you it found or deactivated the key, or when someone with access leaves. Stripe's rule is to treat "any exposure as a potential compromise" (Stripe best practices).

On a schedule, Anthropic's key guide suggests rotating "on a consistent schedule (for example, every 90 days) by creating new ones and deactivating old ones." OWASP's Secrets Management Cheat Sheet gives the reason: "You should regularly rotate secrets so that any stolen credentials will only work for a short time." It adds that rotating by hand "can lead to mistakes", and recommends automation where you can.

For a one-person product, the real value of scheduled rotation is rehearsal. Stripe asks you to "Write down a contingency plan" for an exposure (Stripe best practices). The first rotation of a key is always the slow one, so do it on a quiet afternoon, not during an incident.

Make the next rotation small#

You cannot stop every leak, especially one at a provider you depend on. You can make a leak expose less, and make replacing a key take minutes.

• Restricted keys instead of full secret keys. Stripe says that because you cannot limit a secret key's permissions, "we don't recommend using secret keys for new use cases" (Stripe keys).
• One key per component. Supabase: "Use a separate secret key for each backend component. If one component leaks its key, you only rotate that one" (Supabase API keys).
• Leak checks before code ships. GitHub's push protection for individual users "Is enabled by default" and "Stops you from pushing secrets to public repositories on GitHub." When GitHub finds a partner's key, it notifies that provider "so they can take action, such as revoking the credential" (GitHub secret scanning).

If your product issues tokens to others#

Many indie products sit on the other side: you give users API keys, or you install into someone else's platform and hold their tokens. Two patterns help everyone rotate safely:

• Expiring tokens with refresh. Slack's token rotation makes an app's access token expire every 12 hours and replaces it with a refresh token. Slack warns it "may not be turned off once it's turned on", so test it in development first. If you are building for Slack, our Slack Marketplace page covers listing and review.
• OAuth before pasted keys. Zapier's authentication docs call OAuth v2 the preferred scheme and API keys "next best", and say Zapier "will automatically refresh OAuth v2 and session authentications when refresh token functionality is enabled". Our Zapier App Directory page covers what Zapier asks for before listing an integration.

Either way, let people hold more than one key at a time. Two live keys is what makes a rotation without downtime possible. If you sell an API, how to market an API covers the developers who will judge you on details like this.

Where ZeroRaised fits#

Key hygiene matters most when people are looking, such as during a launch. If you are preparing to launch an AI product, how to launch an AI app covers the testing that goes with it, and how to handle traffic spikes covers the paid dependencies that a launch can hit.

ZeroRaised is a free launch site for bootstrapped makers whose products have no institutional VC or accelerator equity. Once your keys are where they should be, you can submit your product for review. The maker perks page lists separate offers for eligible makers, and the launch sites directory lists other places to list by audience.

So, how to rotate API keys in one line: create the new key, deploy it everywhere, confirm traffic has moved, revoke the old one, then check what it did. Practise that once per key before you need it.