Your host leaked env vars: rotate your keys in 15 minutes

On October 21, 2026, Railway published a security disclosure about customer environment variables and recommended that every user rotate their secrets. If your app runs on Railway, this is a short, practical order of operations. Every Railway fact below comes from Railway's own posts, and every rotation step links to the provider's official docs.

What Railway said

From the disclosure, Security Disclosure: Wednesday October 21st (Railway Blog, Oct 21, 2026):

• Railway "detected anomalous activity involving systems that store customer environment variables," and its investigation "indicates that an unauthorized third party may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents."
• "While our initial analysis suggests the impact may be limited to a subset of users, we are nevertheless recommending that all users take the actions described below as a precaution."
• What to do: "we strongly recommend that you immediately roll all environment variables, including any API keys, stored in Railway, as well as any private registry credentials, and review logs for those services for unusual activity."
• "All deployments are paused while we investigate," and "As we confirm which accounts were affected, we will contact those customers directly by email with additional details."

From the Railway status page:

• Railway reset storage bucket credentials (Oct 21, 22:37 UTC) and, on Oct 22 at 04:17 UTC, said it had "invalidated all Railway API tokens." If you use the Railway Public API, create new API tokens.
• Builds are back on all plans. As of Oct 23, 5:34 AM ET (the 09:34 UTC update), builds and deployments for Enterprise, Pro, Hobby, Trial and Free workspaces "continue to run normally." Hobby builds returned on Oct 22 at 5:59 PM ET (21:59 UTC), and Free and Trial at 7:22 PM ET (23:22 UTC). New signups "remain temporarily paused." Check the status page for the latest.
• Railway asks users not to "trigger the same deployment more than once" while the queue clears.

Railway also published step-by-step recovery guides. They are linked in the steps below.

1. Inventory your env vars (3 minutes)

Open each Railway service's Variables tab, in every environment you use, and list every secret: API keys, database URLs and passwords, webhook signing secrets, auth secrets and registry tokens. Mark each one by risk:

• Highest: payment keys (Stripe secret and restricted keys), database credentials (DATABASE_URL, passwords), admin or service-role keys (Supabase secret / service_role), cloud credentials (AWS, GCP).
• High: auth provider secrets (Clerk), AI provider keys (OpenAI, Anthropic and others billed per use), GitHub tokens.
• Medium: email (Resend) and other third-party API keys, webhook signing secrets.
• Skip: values that are public by design, such as Stripe pk_ keys, Clerk publishable keys and Supabase publishable / anon keys.

Also note anything outside Railway that holds the same secret: local .env files, CI, other hosts. They need the new value too.

2. Rotate the highest-risk keys first (10 minutes)

For each key, create the replacement, paste it into the Railway variable, then retire the old one (step 3). Official steps per provider:

• Stripe: on the API keys page, use Rotate key on the key's ⋯ menu. Rotating lets you pick when the old key expires; choosing Now deletes it immediately. Webhook signing secrets are separate and live under each endpoint in the Webhooks section. Stripe docs: API keys (Rotate an API key)
• Railway databases (Postgres, MySQL, MongoDB, Redis): Railway recommends Regenerate in the database's Database tab (Config) for template databases, which updates the password and the service variables together, then redeploying every service that uses it. For a suspected leak, Railway says "cutting off the old credential matters more than the short outage while your services redeploy." PostgreSQL · MySQL · MongoDB · Redis
• Supabase secret / service_role key: create a new secret key in Settings → API Keys, replace the old key everywhere, confirm every component uses the new one, then delete the old secret key or deactivate the legacy keys. Supabase docs: API keys (Rotate a leaked or compromised key)
• Supabase database password (if your DATABASE_URL points at Supabase): reset it under Database → Settings. Supabase docs: reset your database password. For databases on other hosts, follow that host's own password-reset docs.
• Clerk: add a new Secret Key on the API keys page, update CLERK_SECRET_KEY, redeploy, verify, then delete the old key. Webhook signing secrets (whsec_) rotate by creating a new endpoint. Clerk docs: Rotate your Clerk API keys
• OpenAI: OpenAI says that if you believe a key has leaked, "rotate your key immediately from the API Keys page." OpenAI Help: Best practices for API key safety
• Anthropic (Claude API): in the Claude Console API keys page, open the ⋯ menu next to the key, select Delete API key, then Create key. Claude Help Center: suspected compromised API key
• GitHub tokens: delete the token under Settings → Developer settings → Personal access tokens and create a new one. GitHub docs: Managing your personal access tokens. Railway says it removed GitHub registry tokens stored on services, but "those registry tokens still work on GitHub until you revoke them," and you need to reconnect your GitHub account yourself. Railway: Redeploy Buckets and Reconnect GitHub
• Resend: create a new API key, then remove the old one from the API keys dashboard (More options → Remove API key). Resend docs: Manage API keys

3. Revoke the old keys

A new key does nothing if the old one still works. Delete, expire or deactivate every old value once its replacement is in place. Clerk and Supabase both advise confirming the new key works before deleting the old one, because a deleted key breaks anything still using it. Where a provider shows "last used" or request logs per key (Clerk, Stripe, Resend), use that to confirm the old key has gone quiet.

If builds aren't back for your plan yet, your running services still use the old values until they redeploy, so revoking right away may cause an outage. Weigh that per key; for databases, Railway's own guidance is to cut off the old credential first.

4. Redeploy once Railway allows it

• Railway notes that containers read variables only at startup, so every service that uses a rotated secret must be redeployed to pick it up.
• Services that use reference variables (such as ${{ Postgres.DATABASE_URL }}) get the new value on their next deploy; pasted values must be updated by hand.
• Bucket credentials were already regenerated by Railway; redeploy services that use buckets.
• Deploy once and wait. Railway asks users not to trigger the same deployment more than once.

5. Check provider logs for misuse

• Stripe: each key's ⋯ menu has View request logs (opens Workbench).
• OpenAI: review the Usage page and consider monthly spend limits with hard enforcement.
• Resend: view request logs per API key.
• Railway: workspace admins can review Audit Logs for variable reads, registry credential changes and deployments your team didn't make. The Postgres guide also shows how to list current sessions with pg_stat_activity.
• Railway's provider-specific checks: OpenAI · Anthropic · Stripe · GitHub · AWS · GCP · OpenRouter · Grok

6. While you're in there: make sure no secret ships to the browser

Rotation fixes the server side. It's also a good moment to confirm none of the new keys ends up in a browser-exposed variable (NEXT_PUBLIC_…, VITE_…, REACT_APP_…), where every visitor can read it from your JavaScript. ShipCheck scans your live HTML and shipped JavaScript for OpenAI, Anthropic, Stripe live secret and restricted, AWS, GitHub and Google keys, private keys and Supabase service_role JWTs, and checks for a publicly served .env file. It doesn't detect every key format (for example Supabase sb_secret_, Resend keys or database URLs), so search for those by hand.

Quick checklist

• Every secret in every Railway service and environment listed
• Stripe, database and admin / service-role keys rotated first
• Auth, AI, GitHub and email keys rotated next
• Copies outside Railway (local .env, CI, other hosts) updated
• Old keys deleted, expired or deactivated
• New Railway API tokens created if you use the Public API; GitHub reconnected
• Services redeployed once builds are available for your plan (once, no repeat triggers)
• Provider usage and request logs reviewed; Railway audit log checked
• No secret in your client-side bundle

Sources: Railway security disclosure (Oct 21, 2026) and status.railway.com. For a general walkthrough of leaked keys, see Exposed .env file or API key? How to check and rotate.