Railway Security Breach: Rotate Environment Variables Now

The Railway security breach is an incident Railway disclosed on 21 October 2026: an unauthorised third party may have accessed encrypted environment variables on the platform and, for some of them, obtained the decrypted contents. Environment variables often hold API keys and database and registry credentials. Railway recommends that every user immediately roll all environment variables stored in Railway, including API keys and private registry credentials, and review logs for unusual activity.

Railway security incident: what happened?

According to Railway's disclosure, it detected anomalous activity involving the systems that store customer environment variables. Railway believes it is part of a series of attacks recently targeting platform companies with the aim of compromising AI inference providers, and says it has notified those upstream providers to revoke keys proactively.

Railway's initial analysis suggests the impact may be limited to a subset of users, but it recommends the same precautions for everyone while it completes its review. It will email affected customers directly once it confirms which accounts were affected.

Railway status: are deployments paused?

Deployments were paused during the investigation. As of 11:47 UTC on 22 October 2026, the Railway status page reported that deployment wait times were coming down, though some deployments may still take longer than usual to start, and that builds remained available for Pro and Enterprise workspaces, with Hobby, then Free and Trial to follow. Railway asks users not to trigger the same deployment more than once. Railway's disclosure does not say whether already running services were affected; check the status page for the current state before you plan a rollout.

What should Railway users do now?

1. Rotate every secret stored in Railway. Treat all environment variables as exposed: payment keys, database passwords, registry tokens, AI provider keys, OAuth client secrets and webhook signing secrets. Create the new credential at the provider, update Railway, deploy, then revoke the old one. If your plan cannot deploy yet, keep the old credential alive only until the new one is deployed.
2. Update Railway and deploy the change. In Railway, variable edits are staged changes: nothing reaches running services until you click Deploy, which redeploys every affected service. From the CLI, railway variable set sets a value and triggers a redeploy; add --skip-deploys to stage several changes and deploy them once. Railway's credential rotation guide covers rotating without downtime.
3. Check for misuse. Review provider logs and dashboards for activity you do not recognise, starting with anything that moves money or customer data.
4. Expect revoked AI keys. Railway says it notified upstream AI inference providers to revoke keys proactively, so check whether any AI provider keys stored in Railway still work, and replace them if they do not.

Is Railway safe to use after the breach?

Railway's initial analysis suggests the impact may be limited to a subset of users, and it says it will email affected customers and post updates as it narrows the scope. Until it publishes its findings, nobody outside Railway can say more. What matters for you today is the same whether you stay or move: any secret that was stored in Railway should be treated as exposed. Moving to another host does not undo that, so rotate first and make any hosting decision afterwards.

Stripe keys: rotate first, investigate second

For stores and SaaS apps, we would rotate Stripe keys first. Railway's Stripe guidance quotes Stripe's rule that a key that reached a public repository or a log line is treated as compromised even without evidence of use, and applies it here: rotate first, investigate second.

• Rotate the secret or restricted key. In the Stripe Dashboard, rotate the key on the API keys page. Stripe lets you set a delayed expiration of up to 7 days on the old key. Use that only to bridge the gap until you can deploy the new key, keep it as short as possible, and expire the old key as soon as the new one is live.
• Roll webhook signing secrets. If a webhook signing secret was stored in Railway, roll it too. Stripe lets you delay the old secret's expiration for up to 24 hours while you update your server.
• Move to restricted keys. Stripe's API key documentation recommends restricted keys with only the permissions an integration needs, which limits the damage if a key leaks again.
• Review the account. Look for charges, refunds, payouts or connected accounts you do not recognise, and check the request logs for calls your app did not make.

Shopify apps and headless stores on Railway

If a Shopify app or headless storefront runs on Railway, its client secret and access tokens may have been in its environment. Shopify's credential management guide explains how to rotate a client secret in the Dev Dashboard. For routine rotation it replaces stored access tokens before revoking the old secret, to avoid downtime. If a secret is actively being misused, Shopify says to revoke the exposed secret immediately, accepting that merchants lose access until the new one is in place. Our Shopify app development team can help rotate app credentials safely.

What to do next

Make a list of every secret your Railway services use and rotate them today, Stripe and database credentials first. Deploy the changes once builds are available for your plan, then watch provider logs for a few days. If you also run PHP or Node.js, patch those runtimes too: the PHP2Shell and Node.js security release fixes came out the same day.