Yes. Railway disclosed on 21 October 2026 that an unauthorized party had accessed its internal systems, including build infrastructure and CI credentials, from 20 October. The attacker queried encrypted customer environment variables and decrypted a subset. Railway says the attacker's access was removed on 22 October and that individual user accounts were not logged into.

What was exposed in the Railway breach?

Customer environment variables: the database URLs, API keys and passwords apps read at runtime. Railway's preliminary report says at most 1.85% of workspaces, about 100,000, had some variables potentially compromised. Because the keys were envelope-encrypted, Railway could not tell exactly which variables were read, so it treats the broader set as exposed. Whether source code was accessed is left to its final report.

Do I need to rotate my Railway environment variables?

Yes. Railway recommends that every customer revoke and reapply sensitive environment variables stored on Railway before 21 October 2026, even if they were not contacted. Rotate at the issuing service first (create a new key, deploy it, then revoke the old one), starting with AI API keys, payment keys and database credentials.

Are my Railway API tokens still valid after the breach?

No. Railway revoked all Railway access tokens and invalidated user sessions, so any token created before the incident has to be recreated, and any CI pipeline or script that deploys to Railway needs the new one. Railway also rolled its GitHub App installations and the credentials of every storage bucket on the platform.

Should I move off Railway after the breach?

Not as a reflex. Rotating your secrets is what protects you now, and moving does not replace it. Move if the breach exposed a requirement Railway does not meet for you, such as holding your own encryption keys, a security questionnaire you cannot answer, or a client contract about where data and secrets live. Plan the move after the rotation, not instead of it.

Railway Breach, October 2026: What to Rotate Now

A server block on rail tracks with its vault door open and keys drifting out, next to a solid safe receiving a row of new keys under a rotation arrow

Railway, the app-hosting platform, disclosed a breach on 21 October 2026: an intruder reached its internal systems and decrypted part of its customers' environment variables, the database URLs, API keys and passwords that apps read at runtime. Railway says at most 1.85% of workspaces, about 100,000, had some variables potentially compromised, but it could not tell exactly which, so it asks every customer to revoke and reapply sensitive variables stored before 21 October. It has already revoked all Railway access tokens. If your app, or one a freelancer or agency built for you, runs on Railway, rotate now: AI keys and payment keys first, then the database, then everything else. Below: what happened, the rotation order, and how to decide whether to stay.

What happened

Everything here comes from Railway's preliminary report, dated 22 October 2026, unless said otherwise. A final forensic report is still to come.

20 October: the attack starts. Railway describes "a sustained and targeted campaign" against its internal infrastructure, including a privilege escalation attempt in its build systems. It has not published the root cause.
21 October: the attacker obtains credentials from Railway's CI environment, then queries encrypted environment variables and decrypts a subset. Railway notifies vendors, invalidates sessions and publishes its disclosure that evening.
22 October: Railway confirms the attacker's access is removed and restores deployments.
26 October: Railway calls the incident resolved for existing users; new signups were still paused.

What Railway says was not affected: individual user accounts were not logged into. What it has not ruled out: access to source code, which the final report is meant to settle.

On the numbers, read carefully. 1.85% of workspaces is Railway's ceiling for variables "potentially compromised". Because the variables were envelope-encrypted, Railway could not determine which specific ones were read, so it treated a broader set as exposed. It contacted customers it considers high risk, a larger group than the 1.85%, and sent upstream providers lists covering more than 100,000 users as a precaution. A revocation notice from a provider therefore does not mean your key was read. It does mean you should act as if it was.

What Railway already did, and what breaks because of it

Railway's response changed things in your setup whether you act or not:

All Railway access tokens were revoked and sessions invalidated. CI pipelines, scripts and tools that deploy to Railway with an old token now fail until you create a new one.
GitHub App installations were rolled. Check that auto-deploys from GitHub still trigger.
Credentials for every storage bucket on Railway were rolled. An app that reads a bucket with a copied credential needs the new one.
Vendors were asked to revoke keys, including GitHub, GitLab, Anthropic, OpenAI, OpenRouter and Stripe according to the report. Some of your keys may already have stopped working at the provider's end. That is the provider protecting you; replace them rather than restoring the old values.

One more line in the report matters for the bill: Railway will not refund fraudulent AI spend. If someone used a leaked OpenAI, Anthropic or OpenRouter key, the charges are between you and that provider. Railway points you to them.

What to rotate, in order

Railway's own list is: revoke and reapply sensitive variables stored before 21 October, remove public network access to databases, rotate sensitive keys, check GitHub audit logs and installed app access, and check registry audit logs such as Docker Hub. Here is the order we would follow, based on what costs you most if it is abused.

Order	Secret	Why first	How to rotate without an outage
1	AI API keys (OpenAI, Anthropic, OpenRouter, others)	A leaked key turns into a bill within hours, and Railway won't refund it	Create a new key, deploy it, revoke the old one. Then read the provider's usage page for spend you don't recognize, from 20 October
2	Payment keys (Stripe secret keys, webhook signing secrets)	Money and customer data	Stripe can roll a key with an expiry on the old one, so both work while you deploy
3	Database credentials (`DATABASE_URL`, passwords)	Full read and write on your data	Create a new database user or password, deploy, then drop the old one. Turn off public network access to the database while you are there
4	Cloud and code access (AWS or GCP keys, GitHub tokens, deploy keys, registry tokens)	Lets an attacker reach beyond the app	Rotate, then read the audit logs: GitHub's security log, your cloud's access logs, Docker Hub or other registry logs
5	Signing secrets (JWT, session, cookie secrets)	Lets someone forge a login	Rotating logs every user out. Plan it, or support two secrets during a short overlap
6	Everything else (email and SMS providers, OAuth client secrets, other SaaS tokens)	Spam, account takeover at third parties	Same pattern: new value, deploy, revoke the old

Three rules that keep this from causing its own incident:

Rotate at the source. Generate the new value at the issuing service, not by editing the variable in Railway alone. Changing only Railway's copy leaves the leaked value working.
New before old. Deploy the new value, check the app works, then revoke the old one. Revoking first is how a rotation becomes an outage.
Write down what exists. Most teams find secrets they forgot: a second Stripe key, a test OpenAI key with no spending limit, a token in a CI variable. Railway's dashboard lists every variable per service and environment; that list is your inventory.

If you are not sure what an old key could reach, treat it as able to reach everything. That is usually closer to the truth than the key's name suggests.

Should you leave Railway?

A breach at a hosting provider is a reason to ask questions, not automatically a reason to move. Every platform that holds your secrets can be breached, the big clouds included. What matters is how much one breach can reach and how fast you can recover.

Questions worth answering now, honestly:

Could you rotate everything in an afternoon? If the answer is no because nobody knows what the app uses, that is the real problem, and it moves with you to any host.
Do you need to hold your own keys? On Railway, Railway encrypts and decrypts your variables. On your own cloud account, secrets can sit in a store encrypted with keys you control, and services can authenticate without long-lived key files at all.
Does a client or a security questionnaire ask where secrets live? If you now have to explain this breach to a customer, write the answer down; it tells you whether the setup still fits.
Who runs the platform for you? A managed platform exists so you don't have to. Moving to raw cloud infrastructure trades this risk for operations work someone has to do every month.

If you do move, do it after the rotation, and use the move to fix the inventory problem rather than copying the same pile of variables to a new host. Our longer piece on whether your software agency should host your app covers the trade-off between running it yourself and having the builder run it.

What we do

We don't host anything on Railway; we checked our repositories before writing this. Our production services run on our own Google Cloud infrastructure. Credentials live in HashiCorp Vault inside the cluster, unsealed with Google Cloud KMS, and in Google Secret Manager, and are mounted into the application at runtime, never written into code or the repository. Services reach Google Cloud through Workload Identity, so there are no long-lived service-account key files to leak, and internal tokens are generated straight into Secret Manager without anyone seeing the value. Details on our security page.

What we do for you: take over an application someone else built, wherever it is hosted, list every secret it uses and what each one can reach, rotate them in an order that keeps the app up, and keep it maintained afterwards. If you decide to move, we plan the migration so you leave with fewer secrets, not the same ones on a new host.

What we don't do: incident forensics or breach investigation. If you suspect your data was actually accessed, you need a specialized incident-response firm, and possibly your lawyer, before you need us. We are not SOC 2 or ISO 27001 certified either; we answer security questionnaires point by point with evidence from the actual systems.