In this article
  1. Railway status page: what it says now
  2. What happened
  3. Why it matters
  4. What to do now
  5. What’s still unknown

TL;DR: In its preliminary report, Railway says an attacker reached internal Railway systems and decrypted stored environment variables for a subset of workspaces: “at most 1.85% of all workspaces had some environment variables potentially compromised,” about 100,000 workspaces. It recommends that “all customers who signed up prior to October 21 rotate their keys stored on Railway.” Railway marked the incident resolved at 22:06 UTC on October 23 (6:06 a.m. Manila on October 24), and on October 26 it added that the incident “is resolved for existing users.” New signups are still paused: Railway’s report says it “will reopen signups this week,” while its status page said at 15:19 UTC on October 27 (11:19 p.m. Manila) that it does “not yet have a date to share for reopening signups.” Railway also says it “is unable to refund customers for spend performed with compromised API keys.” Railway, the app hosting platform, first said on October 21, 2026 that “an unauthorized third party may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents.” Railway says those variables can hold API keys and database and registry credentials. It says the impact may be limited to a subset of users, but it recommends that every user roll all environment variables stored in Railway, including API keys and private registry credentials, and review logs for unusual activity. Railway paused all deployments while it investigated. As of 6:49 a.m. Manila on October 23, builds are back on every plan, so you can deploy again after rotating your variables (as of 4:09 p.m. Manila, Railway says builds and deployments on every plan “are proceeding normally,” after warning at 3:37 p.m. that builds “may stay in a queued state” during a build-system upgrade; at 5:34 p.m. it warned that “[r]edeploying code from before the incident would not work and result in an error,” so our advice is to deploy a new commit), and Railway has invalidated every API and Project Token created before the incident, so you need to create new ones.

Railway status page: what it says now

Status as of Oct 28, 2026, 10:08 a.m. Manila: The Railway Platform Outage incident for October 21 is still marked “Resolved,” with no update since 22:06 UTC on October 23 (6:06 a.m. Manila on October 24). Railway now posts recovery news in a separate status incident, “Railway Recovery after October 21 Incident,” which it says “is not an announcement of an additional incident.” Its updates (UTC, with Manila time in brackets):

  • October 26, 19:12 (October 27, 3:12 a.m. Manila): Railway says it will use this incident “to provide updated information” while it works “to recover all of our systems after the October 21 Security Incident,” and that it expects “to post at least twice a day during the week.”
  • October 27, 03:22 (11:22 a.m. Manila): “There is no change since our last update. New signups remain paused while we prioritize reliability for existing customers during recovery. We do not have a date to share yet for re-enabling signups.” Railway says its next update will come “around 15:00 UTC on October 27” (11:00 p.m. Manila).
  • October 27, 15:19 (11:19 p.m. Manila): Railway says new signups “remain paused” and it does “not yet have a date to share for reopening signups.” It “will now post updates here once a day,” with the next “around 16:00 UTC on Wednesday October 28” (12 a.m. Manila on October 29).

Other Railway status notices we hadn’t reported before:

  • October 23, 22:03 (October 24, 6:03 a.m. Manila): Railway’s support site notice says “station.railway.com, is now restored, you can raise support threads on that property,” and that “[n]ew account signups remain paused and some non-essential product features remain disabled.”
  • October 24, 13:57 (9:57 p.m. Manila): In a notice titled “Clarification: Recent Oct 24 API key revocations are precautionary,” Railway says it “is not currently under attack.” On October 23, AI providers asked for “another batch of potentially affected keys”; Railway gave that batch to OpenAI and Anthropic, but “because we could not filter keys by when they were added, it inadvertently included newer keys. As a result, providers may have revoked replacement keys you created after the incident.” Railway says those revocations “do not indicate that your replacement keys were compromised.”
  • October 26, 11:05 to 23:43 (October 26, 7:05 p.m. to October 27, 7:43 a.m. Manila): A separate notice reported slow build snapshot uploads in EU West, US West and Southeast Asia, “caused by the same issue with our upstream storage provider.” Railway said this was “unrelated to the security incident from October 21st” and that “[r]unning deployments are not affected.” It was resolved at 23:43 UTC.

When builds were first paused. Railway’s status page had a notice, “New builds are temporarily paused,” at 17:03 UTC on October 20 (1:03 a.m. Manila on October 21): “We are aware of an issue affecting builds and have temporarily paused new builds for most workspaces while we investigate. Deploys triggered during this period will need to be triggered again once we resume builds.” Railway’s preliminary report lists 17:03 UTC on October 20 as the time it “declared an incident on status.railway.com.” Builds resumed at 20:56 UTC on October 20 (4:56 a.m. Manila on October 21), when Railway said deploys, GitHub pushes and restarts made during the pause “were not queued during the pause and will not start on their own.” At 02:49 UTC on October 21 (10:49 a.m. Manila), it paused builds for Free, Trial and Hobby workspaces again, and at 09:28 UTC (5:28 p.m. Manila) it said “new builds remain paused in all regions.” We didn’t find the wording “deploys have been paused due to an upstream issue” in any of Railway’s status notices for this incident.

Update, Oct 28, 2026, 10:45 a.m. Manila: Railway’s recovery status incident posted a new update at 15:19 UTC on October 27 (11:19 p.m. Manila): signups are still paused with no reopening date, and Railway will now post once a day, next around 16:00 UTC on October 28 (12 a.m. Manila on October 29). We’ve updated the status section and the TL;DR.

Update, Oct 27, 2026, 4:32 p.m. Manila: Railway’s October 26 report update. Railway added a “Continuous Updates” section dated Monday, October 26 to its preliminary report (page metadata: 20:41 UTC on October 26, 4:41 a.m. Manila on October 27). It says:

  • “The security incident is resolved for existing users.” Railway says it “will continue to provide updates until all surface areas of Railway are fully operational.”
  • Signups: “We will reopen signups this week.” Railway’s later status page update, at 03:22 UTC on October 27 (11:22 a.m. Manila), says it does “not have a date to share yet for re-enabling signups.”
  • Refunds: “Railway is unable to refund customers for spend performed with compromised API keys.” It encourages users “to reach out to AI token providers directly,” then to “submit a support request at station.railway.com with timestamps, prompts, and addition [sic] proof of fraudulent spend so we can escalate the request on your behalf.”
  • Railway says it is implementing “a new generation of builder, encryption, and logging systems.”

The report’s FAQ, which already did so before the October 26 update, lists Google among the providers whose key-revocation emails users may have received: “GitHub, GitLab, Anthropic, OpenAI, OpenRouter, SpaceXSI, Google, or Stripe.” The report’s main list of vendors it worked with doesn’t name Google.

When Railway told vendors: 09:25 or 09:35 UTC? Railway’s report gives two times. Its timeline table and its “Scale of impact” section both say 09:25 UTC on October 21 (5:25 p.m. Manila), when it “notified vendors proactively” and when “we knew they were accessed.” Its FAQ says Railway sent the list of potentially decrypted keys to providers “on October 21st 09:35 UTC” (5:35 p.m. Manila), “prior to our public disclosure.” Railway doesn’t explain the 10-minute difference. We use 09:25 UTC, the time in its timeline and its “Scale of impact” section. That is three minutes before Railway’s 09:28 UTC status update; either time is before its public disclosure at 20:44 UTC.

We’ve updated the TL;DR, the steps under “What to do now” and the still-unknown section.

What happened

Earlier status, as of Oct 24, 2026, 6:20 a.m. Manila: Railway’s status page now lists the incident as “Resolved.” Its 22:06 UTC update on October 23 (6:06 a.m. Manila on October 24) says: “Builds, deployments, the Railway API, and the dashboard are operating normally. New signups remain temporarily paused while we focus on existing customers.” Its support and community site, station.railway.com, was then still unavailable and tracked in a separate notice; Railway says it was restored at 22:03 UTC on October 23. The same update links the preliminary report and says: “If you have not already done so, please rotate sensitive credentials stored in Railway environment variables, revoke the old credentials, and redeploy dependent services.” Railway says its forensic investigation is still ongoing and that it will follow up as it concludes.

Update, Oct 24, 2026, 6:20 a.m. Manila: Railway’s preliminary report. Railway linked its preliminary report on its status page at 16:38 UTC on October 23 (12:38 a.m. Manila on October 24); the report itself is dated October 22. It says:

  • The attack ran from 13:58 UTC on October 20 to 03:32 UTC on October 22, when Railway “confirmed that the attacker no longer had access to any internal systems.” Railway says the attacker was likely after AI provider and platform API keys “to perform distillation attacks,” and that it isn’t “yet able to share the specific details and scale of the exploits.”
  • The attacker pulled encrypted secrets, then reached Railway’s CI environment, where it “was able to decrypt artifacts that held additional API access.” Railway found “an unauthorized query of encrypted environment variables, of which a subset were decrypted.” Because the keys were envelope encrypted, Railway says that query alone can’t show which keys in a workspace were affected.
  • Scale: “at most 1.85% of all workspaces had some environment variables potentially compromised. This represents, numerically, about 100,000 workspaces.” Railway says it is also contacting customers it considers high risk, a group “greater than the 1.85% of workspaces”: workspaces with a very large number of environment variables, and environments with many AI vendor keys. As of 18:57:54 UTC on October 23 (2:57 a.m. Manila on October 24), its status page says it had finished notifying the higher-risk workspaces, adding that “[w]orkspaces outside those higher-risk groups are not confirmed safe from compromise.”
  • Railway says the attacker “did not access Railway user accounts,” but it isn’t ruling out access to user source code until its final report. It revoked all Railway access tokens as a precaution.
  • Railway says it worked with GitHub, GitLab, Anthropic, OpenAI, OpenRouter, SpaceXSI, Stripe and others to revoke potentially compromised keys, and gave some vendors every key on the platform, so an email from a vendor about a revoked key “does not imply that their credentials were impacted.”
  • Railway recommends “that all customers who signed up prior to October 21 rotate their keys stored on Railway.” Elsewhere in the report it recommends all users “revoke and reapply sensitive environment variables stored on Railway prior to this date,” remove public network access to databases, check GitHub audit logs and app access, and check registry audit logs, such as Docker Hub’s.

We’ve updated the status, what-to-do and still-unknown sections.

Earlier status, as of Railway’s Oct 23, 2026, 5:34 p.m. Manila update: Railway’s status page still listed the incident as “Identified.” Its latest update then, at 09:34 UTC (5:34 p.m. Manila), is a reminder that “if you are facing issues with deployments, you may need to disconnect and reconnect your GitHub integration” and that “[r]edeploying code from before the incident would not work and result in an error”; Railway says builds and deployments “continue to run normally, and there is no other change since our last update.” That earlier update, at 08:09 UTC (4:09 p.m. Manila), says “Builds and deployments for Enterprise, Pro, Hobby, Trial and Free workspaces are proceeding normally,” that new signups “remain temporarily paused,” and that “[w]e have notified customers with a very high likelihood of impact by email.” It adds: “We are still conducting forensic analysis to find more cohorts of likelihood of impact. The team still expects the preliminary report by noon EST.” Railway’s update before that, at 07:37 UTC (3:37 p.m. Manila), said builds “may stay in a queued state” during a build-system upgrade and that “[t]his update is not related to the security disclosure.” This is a moving story; we’ll update it.

Update, Oct 23, 2026, 6:45 p.m. Manila: If your Railway deployments are failing, Railway says you may need to reconnect its GitHub integration, and that redeploying code from before the incident will error. In a 09:34 UTC (5:34 p.m. Manila) status update, Railway says: “Reminder: if you are facing issues with deployments, you may need to disconnect and reconnect your GitHub integration. Redeploying code from before the incident would not work and result in an error. Builds and deployments for workspaces continue to run normally, and there is no other change since our last update.” Our advice: to pick up rotated variables, don’t redeploy code from before the incident; deploy a new commit instead, for example by pushing one. If that deployment fails, disconnect and reconnect the GitHub integration as Railway suggests, then check that the new deployment goes live. Railway’s 08:09 UTC update said it “still expects the preliminary report by noon EST.” Railway wrote EST and didn’t give a date; its 03:00 UTC update said October 23. Noon EST on October 23 is 1 a.m. Manila on October 24, while noon US Eastern daylight time, which is in effect on October 23, is midnight Manila at the start of October 24. Our advice: if you haven’t had an email from Railway, don’t assume you’re in the clear, since Railway says it is still looking for more customers who may have been affected and recommends that every user rotate their variables.

Update, Oct 23, 2026, 4:30 p.m. Manila: Railway builds may stay queued during a build-system upgrade. In a 07:37 UTC (3:37 p.m. Manila) status update, Railway says “Builds may stay in a queued state while the Railway team deploys an upgrade to the build system” and that “[t]his update is not related to the security disclosure.” It doesn’t say how long the upgrade will take. If you’re redeploying to pick up rotated variables or new bucket credentials, a queued build means your service is still running with its old values until the new deployment goes live, so our advice is to check that each deployment finishes. Railway has also reworded its 03:00 UTC update: it now says it is emailing “customers with high likelihood of impact,” where it earlier said “impacted customers with high likelihood of impact.” We’ve updated our quote of that update above, and corrected our 10:40 a.m. note, which said Railway was emailing “impacted customers”; Railway’s 02:19 UTC update says customers with “a high likelihood of impact.” Its Preliminary Incident Report is still due around midday Eastern Time on October 23 (about midnight Manila).

Update, Oct 23, 2026, 1:50 p.m. Manila: Railway’s notification emails will take “at least several more hours,” and its status page now gives a time for the Preliminary Incident Report. In its 03:00 UTC (11:00 a.m. Manila) update, Railway says it “cannot give a reliable estimate for when all emails will be sent” and apologizes “that we cannot provide a more definite timeline.” It says it “still plan[s] to publish our Preliminary Incident Report around midday Eastern Time on October 23,” which is about midnight Manila. Railway hasn’t named a new time for its next status update; it says the next one comes when sending is complete or if anything material changes. If you haven’t had an email yet, that doesn’t mean you’re in the clear: Railway still recommends that every user rotate their variables.

Update, Oct 23, 2026, 10:40 a.m. Manila: Railway says it is now emailing customers with a “high likelihood of impact,” and its Preliminary Incident Report is delayed. If you use Railway, watch your inbox (including spam) for a message from Railway. Builds are back on every plan. Railway enabled builds for Hobby at 21:08 UTC (5:08 a.m. Manila) and for Free and Trial at 22:49 UTC (6:49 a.m.), so everyone can now complete the guides that need a redeploy. At 17:00 UTC (1:00 a.m.) it said the API was fully restored and that “API tokens and Project Tokens created before the security incident remain invalidated,” so create new ones if you use the Public API or the CLI. It paused new signups at 19:06 UTC (3:06 a.m.).

Update, Oct 22, 2026, 9:17 p.m. Manila: Railway says deployment wait times are close to normal again. At 11:01 UTC (7:01 p.m. Manila), it said queued deployments were starting again, though more slowly than usual, and that it was “continuing to work on build error rates.” Its updates at 11:47 UTC (7:47 p.m.) and 12:30 UTC (8:30 p.m.) said wait times were coming down, and at 13:16 UTC (9:16 p.m.) it said it had “almost worked through the queue.” Its updates since 11:01 UTC don’t mention build failures. Builds are still available only for Pro and Enterprise workspaces; Hobby, then Free and Trial, are still waiting.

Update, Oct 22, 2026, 6:15 p.m. Manila: Some Railway builds are failing more often than usual. In its 09:28 UTC (5:28 p.m. Manila) status update, Railway said “some builds are failing more often than usual” and that it is “working to bring error rates back down,” while many deployments were still queued. Its 10:15 UTC (6:15 p.m. Manila) update says both problems continue. Builds are still available only for Pro and Enterprise workspaces; Hobby, then Free and Trial, are still waiting.

Update, Oct 22, 2026, 4:25 p.m. Manila: Railway has invalidated all Railway API tokens and restored builds for Pro and Enterprise workspaces; Hobby, then Free and Trial, are still waiting. In its status updates (Manila times, October 22):

  • 11:32 a.m.: builds came back for Enterprise workspaces, so Enterprise customers could “complete the steps in our published guides that require a redeploy, including applying any new credentials you have added in Railway.” Pro, Hobby, then Free and Trial were to follow in stages.
  • 12:00 p.m.: the Redeploy feature was unavailable; Railway said to use “Deploy Latest Commit” from the service’s command menu (Ctrl/Cmd+K) instead. At 12:52 p.m. it said Redeploy was fixed for Enterprise customers.
  • 12:17 p.m.: “In accordance with our security disclosure, we have invalidated all Railway API tokens.” If you use an API token with Railway’s Public API, “it will no longer work,” and Railway says to create new tokens.
  • 12:39 p.m. to 2:12 p.m.: services with pre-deploy commands got stuck at “Running pre-deploy command.” At 2:12 p.m. Railway said Enterprise deployments were moving through each stage at normal speed and that stuck deployments would continue “on their own, and no action is needed.”
  • 2:29 p.m.: builds became available for Pro workspaces, and “Pro customers can now complete the steps in our published guides that require a redeploy.”
  • 3:11 p.m. and 4:01 p.m.: deployments were slow to start and some stayed queued; at 4:01 p.m. Railway asked users not to trigger the same deployment more than once.

Update, Oct 22, 2026, 10:11 a.m. Manila: Railway has published guides for checking AWS and Google Cloud keys stored in Railway: deactivate or disable the exposed key, put a new one in your Railway variables and redeploy, then review CloudTrail or Cloud Audit Logs for activity you didn’t generate. Its status page now lists 13 guides in all, including ones for OpenAI, Anthropic, Grok, OpenRouter, Stripe and GitHub access and for PostgreSQL, MySQL, MongoDB and Redis credentials. Its 01:22 UTC status update says the guides “may require redeployment of services which you will not be able to complete until Builds are available again.”

Railway’s security disclosure, by Jacob Cooper, was published at 20:44 UTC on October 21 (4:44 a.m. Manila on October 22). Railway says:

  • “Earlier this morning,” it “detected anomalous activity involving systems that store customer environment variables.” The post doesn’t give a time or time zone for that.
  • Its investigation so far “indicates that an unauthorized third party may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents.”
  • “We believe this is part of a series of attacks recently targeting platform companies with the aim of compromising AI inference providers.” Railway says it has “notified these upstream providers to revoke all keys proactively.” It doesn’t name the providers.
  • Its “initial analysis suggests the impact may be limited to a subset of users,” but it recommends the steps below for all users “as a precaution.”
  • It will email affected customers directly as it confirms which accounts were affected.

The blog post links to Railway’s status incident, titled “Railway Platform Outage.” Its updates say (times UTC, October 21):

  • 07:24: Railway started investigating an issue. By 09:28 it said the dashboard, API and CLI were unavailable, new builds were paused in all regions and its support site was affected.
  • 19:15 to 20:35: Railway said it would re-enable builds in stages, Enterprise workspaces first, then Pro, Hobby, and Free and Trial. At 20:19 it said it was “invalidating OAuth sessions as part of our mitigation,” so some users will be signed out and need to log in again.
  • 21:59: Railway linked the security notice, recommended that users “revoke all environment variables stored in Railway, including API keys and private registry credentials, and review your service logs for unusual activity,” and said “Deployments remain paused while we investigate, including for Enterprise customers.”
  • 22:10: “We are rotating all Railway bucket credentials in response to the security incident. New credentials will appear in your dashboard automatically.” Railway added that because deployments are paused, you can’t redeploy to pick up the new credentials until builds are restored.
  • 22:37 and 22:45: builds remained paused. Railway said customers may see storage bucket credentials revoked by Railway employee “Faraz Patankar” in their audit logs or activity panel, and that this is expected.
  • October 22, 00:22 and 01:22: Railway said it was still working to make builds available again, then that it had published guides for the recommended next steps, adding: “there are steps you may begin to take.”
  • October 22, 02:19 to 08:01: builds remained paused until 03:32, when they returned for Enterprise, then for Pro at 06:29; Railway invalidated all Railway API tokens at 04:17. The Manila-time update above has the details.

Why it matters

Railway says environment variables can include “API keys or database and registry credentials,” and it believes the attackers were after AI inference providers. Railway also says some of its guides need a redeploy, so the window between rotating a key and running with the new one depends on when you redeploy: builds have been available on every plan since 22:49 UTC on October 22 (6:49 a.m. Manila on October 23), and at 08:09 UTC on October 23 (4:09 p.m. Manila) Railway said builds and deployments on every plan “are proceeding normally.”

What to do now

  1. Rotate every secret you stored in Railway, and revoke the old ones. Railway’s preliminary report recommends that “all customers who signed up prior to October 21 rotate their keys stored on Railway,” and its October 23 status update says to “rotate sensitive credentials stored in Railway environment variables, revoke the old credentials, and redeploy dependent services.” Its original disclosure recommended that you “immediately roll all environment variables, including any API keys, stored in Railway, as well as any private registry credentials.” Railway says environment variables may contain API keys and database and registry credentials. Our advice: revoke each old value with whoever issued it, not just change it in Railway. Railway’s status page says that if you’ve already completed these rotations since the incident was contained, “this update alone does not require you to repeat them.” If OpenAI or Anthropic revoked a replacement key you made after the incident, Railway says to “create a replacement, update the corresponding Railway environment variable, and redeploy the services that use it.”
  2. Review your logs and access. Railway recommends you “review logs for those services for unusual activity,” meaning the services those keys and credentials unlock, such as your API providers, databases and registries. Its preliminary report adds: remove public network access to databases, check your GitHub account audit logs and review all app access, and check audit logs in registries such as Docker Hub.
  3. Create new Railway API tokens. Railway has invalidated all Railway API tokens, so anything you’ve connected to its Public API with a token, such as scripts or CI jobs (our examples), has stopped working. Create new tokens on Railway and store them only where they’re needed.
  4. Expect Railway’s own bucket credential changes. Railway says it is rotating all Railway storage bucket credentials and new ones will appear in your dashboard automatically. Revocations by Railway employee “Faraz Patankar” in your audit log or activity panel are expected, Railway says. To pick up the new bucket credentials, you need a redeploy, which works only once builds are back for your plan (see step 5).
  5. Redeploy to pick up your new values. As of 6:49 a.m. Manila on October 23, builds are available on every plan, and at 08:09 UTC (4:09 p.m. Manila) Railway said builds and deployments on every plan “are proceeding normally.” Our advice: check that each deployment finishes, succeeds and goes live. In its 09:34 UTC (5:34 p.m. Manila) update, Railway says that “[r]edeploying code from before the incident would not work and result in an error” and that “if you are facing issues with deployments, you may need to disconnect and reconnect your GitHub integration.” Our advice: deploy a new commit rather than redeploy code from before the incident. Earlier it asked users not to trigger the same deployment more than once. If Redeploy isn’t available, Railway says to use “Deploy Latest Commit” from the service’s command menu (Ctrl/Cmd+K). Railway says some users will be signed out and need to log in again.
  6. Watch for Railway’s email and status updates. Railway says it will contact affected customers directly by email and will post updates on its blog and on status.railway.com. Its status page and its new guides give a support email address, though Railway “may not be able to share more detail than is published here.” Its support site, station.railway.com, is back.
  7. Report fraudulent AI spend to the provider first. Railway says it “is unable to refund customers for spend performed with compromised API keys.” It asks you to contact the AI provider directly, then submit a support request at station.railway.com “with timestamps, prompts, and addition [sic] proof of fraudulent spend” so it can escalate the request.

What’s still unknown

Railway hasn’t shared the specific exploits the attacker used, and says its forensic investigation is still ongoing, with a follow-up report to come. Because of how the keys were encrypted, it says it can’t tell which specific variables in an affected workspace were decrypted. It isn’t ruling out that the attacker accessed user source code, and says it will confirm that in its final report. On new signups, Railway’s October 26 report update says it “will reopen signups this week,” but its October 27 status update says it has no date yet. Railway’s report gives different times for when it told vendors (09:25 and 09:35 UTC on October 21) and doesn’t explain the difference.

Sources & method

Sources

Method. Last checked October 28, 2026, at 10:08 a.m. Manila time (02:08 UTC). Every fact here comes from Railway’s blog posts and status page. The disclosure post’s page metadata now says it was last modified at 17:02 UTC on October 23 (1:02 a.m. Manila on October 24); Railway doesn’t say what changed. Our own inferences: revoking old values with the issuer; the examples of what the credentials unlock in step 2; the scripts and CI examples in step 3; the point that rotated values take effect only once a redeploy goes live, so a queued build leaves the old values running; and the point that not getting Railway’s email doesn’t mean you’re in the clear. The advice to deploy a new commit rather than redeploy code from before the incident is also ours, based on Railway’s 09:34 UTC update. Advice marked “Our advice” is ours, not Railway’s. No affiliate links on this page. How we work.

Spotted an error? See our corrections policy and tell us.