Railway security incident, October 2026: what to do now

As of October 24, 2026, 06:20 JST (October 23, 21:20 UTC). Every fact that can change carries the time it was checked, in JST (UTC+9), with Railway's own UTC time beside it. This page covers Railway's security incident of October 20 to 22, 2026, and what Railway has said about it since.

On October 21, 2026, Railway told every user to "immediately roll all environment variables, including any API keys, stored in Railway, as well as any private registry credentials". It also revoked its API tokens, CLI sessions, and GitHub connections, so a failing deploy needs GitHub reconnected or a new token.

Redeploying code from before the incident fails as well, so deploy your latest commit. Builds have run on every plan since October 22, 22:49 UTC (October 23, 07:49 JST), though Railway says they may be slow to start or finish, and new sign-ups are still paused (status page, October 23, 20:43 UTC).

Railway's preliminary report, linked from its status page on October 23 at 16:38 UTC, says the attacker was "attempting to obtain AI provider API keys to perform distillation attacks", and that "at most 1.85% of all workspaces had some environment variables potentially compromised", about 100,000 workspaces. It dates the attack from October 20, 13:58 UTC, to October 22, 03:32 UTC, when Railway confirmed the attacker no longer had access. Railway has emailed the workspaces it rates higher risk, and its status page says that workspaces outside those groups "are not confirmed safe from compromise." Services that were already running stayed online throughout.

Below: the steps in order, which keys to rotate first, why a deploy fails after the incident and the fix for each error, when each Railway plan got builds back, the sign-up pause, and the timeline from Railway's report and status page.

What to do, in order

Railway spreads these steps over its disclosure, 14 guides, its status page, and the report. This order gets one deploy through first, because Railway revoked every user's GitHub connection and every later step ends in a deploy, and reconnecting exposes no key. Then it takes each stolen key out of use, and checks for misuse last.

1. Reconnect GitHub

In Railway's Account Settings, connect your GitHub account again, and confirm the Railway GitHub App can reach the repositories you deploy. In each service's Settings, under Source, click Disconnect and then Connect Repo if the repository shows as disconnected, and check that autodeploy is still enabled. In a team project, the member who first connected the repository is the one who reconnects, so ask them before you rotate anything. For private images on ghcr.io, delete the old personal access token on GitHub, create one with the read:packages scope, and enter it under the service's Registry Credentials. Railway removed those tokens from your services, but in its words they "still work on GitHub until you revoke them".

2. Create new Railway tokens for the CLI and CI

On your machine, run railway logout, then railway login, railway link, and railway up. For CI, create a new token with the same scope as the old one: a project token for RAILWAY_TOKEN (project Settings, then Tokens) or an account or workspace token for RAILWAY_API_TOKEN (the tokens page in your account settings). Replace the value in your CI provider's secrets.

3. Get one deploy through with Deploy Latest Commit

Commits pushed while Railway paused deployments "were not queued", and Railway's status page says "Redeploying code from before the incident would not work and result in an error." In each service of the project, open the Command Palette (CMD/CTRL + K) and select Deploy Latest Commit, or push a new commit, and wait until its deployment is active. A service you skip still runs a deployment from before the incident, so step 4's deploy of its new keys would start from that deployment and fail. Until a deploy succeeds, your running service keeps calling providers with its old keys and its old database password, so a key you revoke before then takes your app down with it.

4. Rotate each key at its provider, then deploy

For each key in your variables, create a new key at the provider and put it in the service's Variables, then delete or disable the old key at the provider and deploy the staged change. Changing a variable in Railway alone doesn't stop a key someone already copied, and Railway's OpenRouter guide says your services "can't reach OpenRouter until you deploy the replacement key", so keep the time between revoking and deploying short. For a precautionary rotation, deploying the new key first and revoking the old one after is fine; for a key you know leaked, revoke it first. Start with AI provider keys, because Railway's report says that is what the attacker was after. The table below goes through each kind of key.

5. Regenerate database passwords with Railway's Regenerate button

For a PostgreSQL database from Railway's template, open the database service, then Database, then Config, and click Regenerate next to the password. Railway changes the password inside PostgreSQL and updates POSTGRES_PASSWORD, and DATABASE_URL and DATABASE_PUBLIC_URL follow it. Railway's guide warns that it then "restarts the database to apply the new password, so every open session drops" and "Your services can't reconnect until you redeploy them", so do step 6 right after. For a credential you don't suspect, the same guide points to a no-downtime flow, "Rotate credentials without downtime"; if you suspect a leak, it says to "Regenerate first". Don't edit POSTGRES_PASSWORD or PGPASSWORD by hand or run ALTER USER yourself: the guide says each changes only one side. Railway has the same kind of guide for MySQL, MongoDB, and Redis. The report also advises all users to "Remove public network access to databases": in the database's Settings, under Networking, turn off Public Access if nothing outside the project needs it.

6. Deploy every service that reads a new value

Railway's guides say containers read variables only at startup, so a running service keeps the old value until its next deploy. Use Deploy Latest Commit for each one: a Redeploy of a deployment from before the incident fails. Your storage bucket credentials are already new: Railway regenerated ACCESS_KEY_ID and SECRET_ACCESS_KEY for every bucket in every environment, and the services that use them pick the new values up on their next deploy. Update every copy outside Railway as well, such as local .env files, CI secrets, and other hosts.

7. Check each provider for use you didn't make

Look at usage grouped by key at each AI provider, Stripe's request logs, AWS CloudTrail, your GitHub security log, the OAuth apps and GitHub Apps you have authorized, and your registry's activity logs. Check from October 20, 13:58 UTC, when Railway's report says the attack began, to the moment you revoked each key: a copied key works until then. Export what you find before you delete a key, because OpenRouter, for one, drops a key's usage figures when the key is deleted.

Which keys to rotate

Railway's instruction covers every variable. The order below is this page's: the keys the attacker was looking for, then the keys that move money or reach other systems, then the rest. Each "why" is from Railway's own posts (read October 24, 05:36–05:38 JST).

Who needs to do this. The report recommends rotation for "all customers who signed up prior to October 21", and its remediation section says to "revoke and reapply sensitive environment variables stored on Railway prior to this date". Not getting an email from Railway doesn't mean you're clear: the status page says workspaces outside the higher-risk groups it emailed "are not confirmed safe from compromise." An email from a provider about a revoked key doesn't mean yours was stolen either. In the report's words, "Users being notified by vendors about revocation does not imply that their credentials were impacted by the incident", because Railway gave some vendors every key it held.

Why deploys fail after the incident

Each cause below is in Railway's words, from its October 23 guide "Recover Failing Deploys" unless the row says otherwise (read October 24, 05:36 JST).

If a deploy still fails after you reconnect GitHub and create new tokens, Railway's guide asks you to email support@railway.com with the project, service, and environment, the deployment ID, the error from the build logs, and whether the service deploys from GitHub, the CLI, or CI.

Is Railway back?

Builds and deployments are back on every plan, according to Railway's status page (checked October 24, 06:16 JST). Its latest update, of October 23 at 20:43 UTC, says builds "may take longer than usual to start or finish while we work through redeploys across the platform", that "The Railway API and dashboard are fully functional", and that the support site, station.railway.com, "remains unavailable". The incident is still open, in Monitoring, and its page still carries the label "Major Outage", with builds in four regions and the support site listed as affected.

Builds had also stopped once before: on October 20, from 17:03 to 20:56 UTC (October 21, 02:03 to 05:56 JST), under a separate status entry titled "New builds are temporarily paused". The report puts that pause inside the attack.

Sign-ups

Railway paused new sign-ups on October 22 at 19:06 UTC (October 23, 04:06 JST) "so we can focus on making sure everything is working well for existing customers", and said it "will post here when they are available again." Its latest update, of October 23 at 20:43 UTC (October 24, 05:43 JST), still says "New signups remain temporarily paused while we focus on existing customers" (checked October 24, 06:16 JST). Railway has given no date. If you planned to open a new Railway account, that post on status.railway.com is the one to wait for.

What happened: the timeline

The report is dated October 22 on Railway's blog, and Railway's status page linked it on October 23 at 16:38 UTC. It calls itself preliminary: "Our forensic investigation is still ongoing." Rows marked "report" are from its timeline; the others are from the status page (both read October 24, 05:36–06:16 JST).

What Railway hasn't said yet (as of October 24, 06:16 JST): how the attacker got in ("we are not yet able to share the specific details and scale of the exploits"), whether source code was accessed, when the final report comes out, and when sign-ups and the support site return.

Tell your users while you fix it

If your users saw failed deploys, sign-outs, or new keys, they may ask what happened and whether they need to do anything. A Convika page can answer them from outside Railway: ask Claude Code or another AI client connected to Convika to write it, add a reply form, and publish it, or make it with Convika's AI on the dashboard and add the form with Add a form to my page before you publish (Free shows 50 entries a month). The page is static HTML that Convika serves at a convika.page address, not a host for your app, and it holds none of your environment variables. On Free the page is public, and search engines and Convika's gallery may list it, so leave out hostnames, key names, and anything internal.

Make my notice page

Updates to this page

• October 24, 2026, 06:20 JST: first version, with Railway's status update of October 23, 20:43 UTC, the latest at 06:16 JST.

This page changes when Railway re-enables sign-ups, brings back its support site, resolves the incident, publishes its final report, or changes its advice. The same week: Node.js October 2026 security release: what to update and PHP October 2026 security release: what to update.

Frequently asked questions

Is Railway down right now?

Not for running apps and deploys. Builds and deployments run on every plan, and Railway's update of October 23, 20:43 UTC, says "The Railway API and dashboard are fully functional" (checked October 24, 06:16 JST). The incident is still open, in the Monitoring state, and its page still carries the label "Major Outage" for builds in four regions and the support site: builds may take longer than usual to start or finish, station.railway.com is still down, and new sign-ups are still paused.

Do I need to rotate my OpenAI or Anthropic key if I use Railway?

Yes, if the key was stored in a Railway variable. Railway's report says the attacker was "attempting to obtain AI provider API keys", and Railway asked AI providers to revoke the keys it found. Create a new key, put it in the variable, delete the old one at the provider, and deploy your latest commit.

Was my Railway account hacked?

Railway says no: "individual accounts were not logged into." The attacker reached Railway's internal systems and decrypted stored environment variables for some workspaces. Railway revoked all Railway access tokens anyway.

Why did I get an email saying my API key was revoked?

Railway sent providers a list of potentially decrypted keys on October 21 and asked them to revoke the keys, and "Some vendors requested all keys to be revoked." Its FAQ names "GitHub, GitLab, Anthropic, OpenAI, OpenRouter, SpaceXSI, Google, or Stripe" as the senders of such emails. The report says such an email "does not imply that their credentials were impacted by the incident." Either way, the old key no longer works, so deploy a new one.

I didn't get an email from Railway. Am I safe?

Not necessarily. Railway finished emailing the workspaces it rates higher risk on October 23 at 18:57 UTC, and its status page says workspaces outside those groups "are not confirmed safe from compromise." Rotate anyway.

Why do my Railway deploys fail after the incident?

Usually because Railway revoked your GitHub connection or your token. Reconnect GitHub, create new CLI and CI tokens, and use Deploy Latest Commit: redeploying code from before the incident fails, and commits pushed during the pause were never queued. The table above matches each error to its fix.

Did my app go down?

Railway says running services "stayed online throughout the incident." What stopped was new builds and deployments, and for a time the dashboard, API, CLI, and support site.

How many Railway users were affected?

Railway says "at most 1.85% of all workspaces had some environment variables potentially compromised", which it puts at "about 100,000 workspaces". More people got key revocations than that: because Railway gave some providers every key it held, "the amount of users who were affected by upstream provider reset requests was larger than 100k."

Why can't I sign up for Railway?

Railway paused new sign-ups on October 22 at 19:06 UTC and said it will post on its status page when they return. Its update of October 23, 20:43 UTC, still says they "remain temporarily paused" (checked October 24, 06:16 JST).

Do I need to rotate keys I added after the incident?

Railway's advice covers variables stored before October 21. Its report dates the attack to October 22, 03:32 UTC, when Railway confirmed the attacker no longer had access, so this page's reading is that a key added before that time should be rotated too. Railway's status page adds: "If you have already completed these rotations since the incident was contained, this update alone does not require you to repeat them."

Is Railway safe to use now?

Railway's answer in its report is "Yes", saying it has "redeployed and revalidated all impacted systems" and moved its builders to single-tenant environments. Its forensic investigation is still running, and Railway says a final report will follow.

Sources

Times are when this page read each source, in JST on October 24, 2026. Each source's own date is in its entry.

• Railway: Security Disclosure: Wednesday October 21st, dated October 21, 2026, last modified October 23, 17:02 UTC (05:36)
• Railway: Preliminary Report: Oct 21st Security Incident, dated October 22, 2026, last modified October 23, 17:01 UTC (05:36)
• Railway: Security Disclosure Recommendation: Recover Failing Deploys, dated October 23, 2026 (05:36)
• Railway status: Railway Platform Outage, opened October 21, 07:24 UTC, latest update October 23, 20:43 UTC (05:37; 06:16)
• Railway status: New builds are temporarily paused, October 20, 17:03 to 20:56 UTC (05:40)
• Railway: Redeploy Buckets and Reconnect GitHub After the Credential Reset, dated October 22, 2026 (05:38)
• Railway: Rotate PostgreSQL Database Credentials, dated October 22, 2026, last modified October 23, 01:16 UTC (05:38)
• Railway: Check for Unexpected OpenAI Usage, Anthropic Usage, OpenRouter Usage, and Grok Usage, each dated October 22, 2026 (05:38)
• Railway: Check for Unexpected Usage in Stripe, Check for Anomalous GitHub Access, and Check for Anomalous AWS Access, each dated October 22, 2026 (05:38)
• Railway engineering blog, the list of the incident's posts (05:37; 06:16)