Railway breach: roll your environment variables, what is known

If you deploy on Railway, roll every secret stored there, starting with API keys and database credentials. Railway told customers on October 21 that an unauthorized party may have read their encrypted environment variables and, for some, obtained the decrypted values. We read Railway’s disclosure, its status page timeline and two of its follow-up guides. This article covers what Railway says happened, what it has done, what it recommends and what is not known. The incident was still developing when we wrote it.

What happened at Railway?

Railway says it detected anomalous activity “earlier this morning” on October 21 involving systems that store customer environment variables. Its investigation “to date” indicates an unauthorized third party may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents. Environment variables can hold secrets such as API keys and database or registry credentials. Railway says its initial analysis suggests the impact may be limited to a subset of users, and that it will email customers directly as it confirms which accounts were affected. It gives no time for the detection and no count of affected users.

Does Railway link it to AI providers?

It does, and the claim is Railway’s own. Its disclosure says it believes this is part of a series of attacks recently targeting platform companies “with the aim of compromising AI inference providers”, and that it notified those upstream providers to revoke all keys proactively. Railway does not name the providers, the attackers or the other companies. Its follow-up guides include checks for unexpected usage of Anthropic, OpenAI, OpenRouter and Grok keys. Those are precautionary guides for customers who stored such keys, not statements that those providers’ keys were misused.

What did Railway do?

Railway tracks all of this in one status incident called “Railway Platform Outage”. As we read it, the sequence is (times in UTC):

• October 21, 07:24-09:28: the incident opens as “investigating” at 07:24 and by 09:28 the dashboard, API and CLI are unavailable and new builds are paused in all regions. The support site is also affected.
• October 21, 11:33-19:15: the API comes back with some features missing, and builds and deployments stay paused through the day. At 19:30 Railway says “an issue affecting multiple systems” led it to pause builds across the platform.
• October 21, 20:19: OAuth sessions are invalidated “due to impact from adjacent cache systems”, signing some users out. Railway does not say how this relates to the security incident.
• October 21, 21:59: the security notice is published, advising users to revoke all environment variables stored in Railway. Deployments stay paused for everyone, including Enterprise.
• October 21, 22:10: Railway rotates all storage bucket credentials. New ones appear in the dashboard, but services need a redeploy to pick them up.
• October 22, 01:22: Railway publishes 13 guides, covering provider keys (Anthropic, OpenAI, OpenRouter, Grok), databases (PostgreSQL, MySQL, MongoDB, Redis), AWS, GCP, Stripe, GitHub and bucket credentials.
• October 22, 03:32: builds return for Enterprise workspaces, with Pro, Hobby, Free and Trial to follow in stages.
• October 22, 04:17: Railway invalidates all of its API tokens. Integrations using the public API need new tokens.
• October 22, 04:52-05:20: Redeploy is fixed for Enterprise at 04:52, and the latest update we read, at 05:20, says deployments are slower than usual and some stay at the pre-deploy stage.

What should you do?

Follow Railway’s advice and do it in an order that works while builds are limited. Railway recommends rolling all environment variables stored in Railway, including API keys, and private registry credentials, and reviewing logs for unusual activity.

The two guides we read follow the same shape. The Anthropic guide says to revoke the key in the provider console, create a replacement, update it on Railway and review usage and logs for requests you did not make. The AWS guide says to deactivate the exposed access key, create a replacement, update both variables on Railway and review CloudTrail and billing for activity you did not generate. Because deployments were paused, some of these steps could not be finished until builds returned, and Railway says the guides apply to every plan regardless of the staged rollout. Check Railway’s status page for where your plan stands.

What is still unknown?

• How the attacker got in, and when. Railway gives no root cause or time of access.
• How many customers are affected. “A subset” is all Railway says so far.
• Whether any exposed keys were used. Railway’s disclosure does not say. Reports on social media that keys were used are unverified, and we did not use them.
• Who is behind it, and which other companies were targeted. Railway refers to a series of attacks without naming them.
• Whether the outage and the intrusion are the same event. The security updates sit in the same status incident as the outage that began at 07:24 UTC, but Railway has not said whether the intrusion caused it.

What to keep in mind

These are our observations:

• The security notice came about 14.5 hours after the status incident opened. That is our arithmetic from the status page times (07:24 to 21:59 UTC). Railway has not said when it detected the anomalous activity, so we cannot say how much of that gap is the investigation.
• Rotate even if you are not told you were affected. Railway has asked everyone to roll their secrets, and it has not yet confirmed which accounts are involved.
• A paused deployment pipeline slows rotation. Several of Railway’s own steps wait on builds, so revoke at the provider first where the guide says to and expect a gap until you can redeploy.
• Set spending limits and alerts at your AI providers. Provider-side usage caps and alerts limit the damage from a stolen key whatever the cause.
• Railway’s “AI inference providers” explanation is its own account. It may be right, but we have not seen evidence for it beyond Railway’s statement.
• It sits alongside other key-theft cases. See our report on the OpenCode Console breach, where provider API keys were also at issue. Nothing we read connects the two incidents.

Editorial review: October 22, 2026 (AI). Prepared from Railway’s blog disclosure, its status page for incident QH8L8B3E (read through October 22, 05:20 UTC) and two of Railway’s 13 follow-up guides (Anthropic usage and AWS access), all read as page text through a command-line fetch. We did not read the other 11 guides, contact Railway, test any step, or verify any report by users. Details may have changed after our reading, so check Railway’s status page. This is not security advice for your environment; follow Railway’s and your providers’ guidance.