Dev.to Security 🔐 Cybersecurity Sun, 25 Oct 2026 06:16:21 +0000 👁 0 📖 17 min read

Is Railway Down? What the 21–22 October 2026 Railway Outage Means for Developers

Disclosure: this article was drafted with the help of an AI writing assistant. Every fact, time and link was checked against Railway's official status page, blog and docs. Originally published on Medium. Last updated: 1

Last updated: 1:30 PM IST, 24 Oct 2026. Status: builds and deployments are back for every plan. Railway published its Preliminary Incident Report at 10:08 PM IST on 23 Oct and marked the incident resolved at 3:36 AM IST on 24 Oct. The investigation is ongoing, and new signups are still paused.

Quick answer: Mostly no. Railway says builds and deployments are working normally for all plans (Enterprise, Pro, Hobby, Trial and Free), and its API was fully restored at 10:30 PM IST on 22 Oct. At 10:08 PM IST on 23 Oct, Railway published its Preliminary Incident Report and then marked the incident resolved at 3:36 AM IST on 24 Oct. The report says an attacker decrypted environment variables for at most 1.85% of workspaces (about 100,000), that user accounts weren’t accessed, and that running apps stayed online. New signups are still paused. Every Railway API token and Project Token created before the incident is still invalid, and Railway recommends that everyone who signed up before 21 Oct rotate the keys they stored on Railway.

What happened?

Railway (railway.com) is a cloud platform-as-a-service that builds, deploys and hosts developers' apps and databases. What happened: on 21–22 October 2026, Railway paused builds platform-wide, took its dashboard, API and support site partly offline, and disclosed that an unauthorised party may have accessed customer environment variables.

The Railway outage began around midday IST on 21 October 2026. For thousands of developers, the most noticeable symptom was simple: you couldn't ship. The Railway status page first logged the incident at 07:24 UTC (12:54 PM IST). Two hours later, Railway said its dashboard, API and CLI were unavailable and that new builds were paused in every region.

The story changed overnight. Railway published a security disclosure, and its official account posted an urgent notice at 3:21 AM IST on 22 October. Railway said it had detected "anomalous activity involving systems that store customer environment variables". It added that an unauthorised party may have obtained decrypted contents for some of them.

Railway is not connected to Indian Railways or IRCTC.

Is Railway down right now?

As of 24 October, the platform is working for all plans, and Railway has published its preliminary report and marked the incident resolved at 3:36 AM IST on 24 Oct. Here is the timeline from the official status page and blog, with times in IST:

21 Oct, 12:54 PM IST (07:24 UTC): Incident opened.
21 Oct, 2:58 PM IST (09:28 UTC): Issue identified. The dashboard, API and CLI are unavailable, and builds are paused in all regions.
21 Oct, 5:03 PM IST (11:33 UTC): The API is back, with some features missing. Builds are still paused.
22 Oct, 1:49 AM IST (20:19 UTC, 21 Oct): Railway invalidates OAuth sessions, so some users are signed out.
22 Oct, 3:21–3:40 AM IST (21:51–22:10 UTC, 21 Oct): @Railway posts its urgent notice, the security disclosure is linked on the status page, and Railway starts rotating bucket credentials.
22 Oct, 9:02 AM IST (03:32 UTC): Builds are restored for Enterprise workspaces.
22 Oct, 9:47 AM IST (04:17 UTC): All Railway API tokens are invalidated.
22 Oct, 10:22 AM IST (04:52 UTC): Redeploy is fixed for Enterprise.
22 Oct, 10:50 AM IST (05:20 UTC): Deployments are progressing slowly. Pro, Hobby, Free and Trial tiers are still waiting.
22 Oct, 11:59 AM IST (06:29 UTC): Builds are available for Pro and Enterprise workspaces. Pro users can now finish the steps in Railway’s guides that need a redeploy.
22 Oct, 12:41 PM to 8:20 PM IST (07:11 to 14:50 UTC): Deployments queue up and start slowly. Railway asks users not to trigger the same deployment more than once. By 8:20 PM IST the queue is cleared, and Pro and Enterprise deployments start at normal speed.
22 Oct, 10:30 PM IST (17:00 UTC): The API is fully restored, including features that had been unavailable. Railway says API tokens and Project Tokens created before the security incident stay invalidated, so anyone using the Public API or the CLI with a token must create a new one. Railway also says it will publish a full incident report on its blog once the incident is resolved.
23 Oct, 12:12 to 12:19 AM IST (18:42 to 18:49 UTC): Some deployments in US West fail after a successful build. Railway fixes this within minutes and asks affected users to redeploy.
23 Oct, 12:36 AM IST (19:06 UTC): Railway temporarily pauses new signups to focus on existing customers.
23 Oct, 2:38 AM IST (21:08 UTC): Builds are available for Hobby workspaces. Railway publishes its Security Guides on its engineering blog.
23 Oct, 4:19 AM IST (22:49 UTC): Builds are available for Free and Trial workspaces. Railway says builds and deployments on all five plans are running at about normal speed.
23 Oct, 7:30 AM IST (02:00 UTC): Railway says its Preliminary Incident Report needs more time and won’t be published that night as planned. It starts emailing impacted customers. Builds and deployments on all plans are still normal, and signups are still paused.
23 Oct, 7:49 AM IST (02:19 UTC): Railway is still sending notification emails to impacted customers. Its next update is due by 8:30 AM IST.
23 Oct, 9:45 PM IST (16:15 UTC): Railway says it has emailed the workspaces at highest risk and is now emailing the remaining at-risk groups.
23 Oct, 10:08 PM IST (16:38 UTC): Railway links its Preliminary Incident Report from the status page. It says the investigation is still ongoing.
24 Oct, 3:36 AM IST (22:06 UTC, 23 Oct): Railway marks the incident resolved. New signups remain paused.

What is known, and what isn't?

Known: Builds are back for all plans. Railway restored them in stages: Enterprise at 9:02 AM IST on 22 Oct, Pro at 11:59 AM IST, Hobby at 2:38 AM IST on 23 Oct, and Free and Trial at 4:19 AM IST (status page). Railway believes the security incident is part of a series of attacks on platform companies aimed at compromising AI inference providers, and it says it notified those providers to revoke keys (disclosure). Railway reset storage-bucket credentials and the GitHub tokens it held. It invalidated all API tokens and Project Tokens created before the incident, and it has emailed customers in its risk groups. Its preliminary report puts the exposure at no more than 1.85% of workspaces (see the next section). New signups are still paused. Independent coverage is available from BleepingComputer.

Unknown: Railway’s preliminary report doesn’t give the specific exploit details. Railway says it will “disclose this responsibly” when the investigation ends. It can’t yet say exactly which variables were decrypted, and it hasn’t ruled out access to source code. It also hasn’t said when signups will return.

Not receiving an email from Railway does not prove you were unaffected. Railway says it can’t tell exactly which keys were decrypted, and it still advises everyone who signed up before 21 Oct to rotate the secrets they stored on Railway.

This distinction matters. If you rotate keys because of a rumour, you lose an afternoon. If you skip rotation because "my app is still up", you could leave a leaked credential live.

What the preliminary report says

Railway published its Preliminary Report: Oct 21st Security Incident and linked it from the status page at 10:08 PM IST on 23 Oct (16:38 UTC). The key points, in Railway’s words where quoted:

Why: a “sustained and targeted campaign” that “was attempting to obtain AI provider API keys to perform distillation attacks”.
When: the attack ran from 7:28 PM IST on 20 Oct (13:58 UTC) to 9:02 AM IST on 22 Oct (03:32 UTC), when Railway confirmed the attacker no longer had access. That’s earlier than the outage most people noticed: Railway first paused builds at 10:33 PM IST on 20 Oct (17:03 UTC) under a separate status incident.
How: the attacker found a privilege escalation in Railway’s build infrastructure, got credentials for its CI environment, and ran an unauthorized query of encrypted environment variables, “of which a subset were decrypted”. Railway isn’t sharing exploit details yet.
Scope: “at most 1.85% of all workspaces”, about 100,000, had some environment variables potentially compromised. User accounts weren’t accessed, running services stayed online, and Railway isn’t ruling out access to source code until its final report.
Fixes: Railway rolled all keys twice, rolled every storage-bucket credential, moved its build system to single-tenant environments, rebuilt its internal tooling from validated source and hired an outside forensics firm.
What to do: rotate the keys you stored on Railway if you signed up before 21 Oct. Remove public network access to databases, check your GitHub audit logs and app access, and check registry audit logs such as Docker Hub.

I cover what this means for you, with a 12-step checklist, in Is Railway safe now?.

What should you do right now?

Update, 23 Oct: what to do now that builds are back

Builds work again on every plan, so the “can’t deploy the new key” problem is over. Finish the job:

Create new Railway tokens. Every API token and Project Token created before the incident is still invalid. Make new ones, then update your CI, GitHub Actions secrets and any scripts or CLI setups that use them (status page).
Redeploy every service where you changed a variable. Containers read variables only at startup, so a rotated key goes live only after a redeploy (Railway guide).
Redeploy services that use storage buckets, and reconnect GitHub. Railway regenerated bucket keys and removed the GitHub tokens it held (same guide).
Revoke the old keys at each provider once the new ones work. Changing the value in Railway alone doesn’t stop a leaked key from working.
Check your inbox, including spam, for an email from Railway. Railway says it is emailing impacted customers.
Retry failed deployments once. If a deployment in US West failed after its build finished, redeploy it. Don’t trigger the same deployment again and again.
Read the preliminary report on Railway’s blog, and watch the status page for the final report and for signups returning.

Railway's official disclosure tells all users to rotate every environment variable, API key and private registry credential stored in Railway, and to review their logs. Steps marked (best practice) are general security practice drawn from the providers' own documentation. They are not Railway instructions.

Quick checklist

List every variable in every Railway project and environment.
Rotate the most dangerous keys first: cloud, then database, then payments, then auth, then other API keys.
For each key: create the new one, update it in Railway, check that it works, then revoke the old one.
Check each provider's logs for activity since 21 Oct 2026.
Reconnect GitHub to Railway, then create new Railway API tokens.
Add spend alerts and keep each key's permissions to the minimum.
Don't spam redeploys. Watch the status page.

Step 1: List every secret

Open each project and each environment (production, staging, PR environments). Write down the service variables, the shared variables in Project Settings, and any reference variables (for example ${{ Postgres.DATABASE_URL }}). Also check places outside Railway that hold copies of the same values, such as GitHub Actions secrets, local .env files and CI tools.

Step 2: Rotate in order of blast radius (best practice)

Cloud provider keys. For AWS IAM, create a second access key, deploy it, deactivate the old key, then delete it (AWS guide). For GCP, create a new service-account key and delete the old one (GCP guide). Railway also has guides for checking AWS and GCP access. For Azure, regenerate the client secret or access key in the portal.
Databases. Change the password, or create a new user, then update the connection string, restart, and remove the old user. Railway has guides for PostgreSQL, MySQL, MongoDB and Redis.
Payments. In Stripe, roll your secret and restricted keys (Stripe docs). Also roll your webhook signing secrets, and follow Railway's Stripe guide. For Razorpay, regenerate the key secret and the webhook secret in the dashboard (Razorpay docs).
App auth secrets. These include JWT signing keys, session secrets, NEXTAUTH_SECRET / AUTH_SECRET and Laravel's APP_KEY. Be aware that changing them logs every user out. A new Laravel APP_KEY (from php artisan key:generate) also makes previously encrypted data unreadable unless you keep the old key. On Laravel 11+, put the old key in APP_PREVIOUS_KEYS (Laravel docs).
OAuth client secrets. Generate a new client secret in GitHub or Google Cloud console, deploy it, then delete the old one.
Other API keys. This covers OpenAI, Anthropic, xAI, SendGrid, Resend, Twilio and similar services. Revoke each key at the provider and create a new one. Railway has guides for OpenAI, Anthropic, Grok and OpenRouter.
Railway API tokens and Project Tokens. Railway has invalidated every token created before the incident. Create new ones, scoped to a single project where you can, then update CI and GitHub Actions secrets.

Step 3: Rotate without downtime, and the outage trade-off (best practice)

The usual pattern is to create the new key, update the Railway variable, deploy, check that it works, and only then revoke the old key. During the outage, changing a variable needed a deploy, and builds were paused for some plans until 4:19 AM IST on 23 Oct (status page). Builds now work for every plan, so you no longer have to choose between keeping your app up and revoking a leaked key. Deploy the new key and then revoke the old one. For the record, the trade-off people faced during the outage was:

If you revoke now, a leaked key stops working at once, but your app may break until you can deploy the new one.
If you wait to revoke, your app keeps running, but a possibly exposed key stays valid.

For high-risk keys (cloud, payments, database admin), revoking at once is usually the safer choice. Whichever you pick, set the new key in Railway now so it goes live with the next successful deploy.

Step 4: Check the logs for misuse

Look for activity since 21 Oct 2026 in:

AWS CloudTrail
Stripe's Developers → Logs and Events pages
the GitHub security log and organisation audit log
your database connection logs
usage pages for each AI provider

Flag unknown IPs, new users or keys, and usage spikes.

Step 5: Reconnect GitHub

Railway reset the GitHub tokens it held and removed GitHub registry tokens stored on your services. Reconnect GitHub yourself, and revoke any old personal access tokens on GitHub (Railway guide). Bucket credentials were regenerated too, so redeploy the services that use them. If you log in and see nothing, and your GitHub email differs from your Railway email, use “Log in using email” (Railway’s preliminary report). Commits pushed while deploys were paused weren’t queued, so use Deploy Latest Commit (Railway guide).

Step 6: Make the next leak smaller (best practice)

Give each key the fewest permissions it needs, for example Stripe restricted keys and scoped IAM roles.
Set spend limits and billing alerts.
Keep a written list of where every secret lives.
Consider a secrets manager, so the next rotation is one change instead of fifty.

Step 7: After the outage: clean up

If a deployment failed during the recovery, retry it once rather than queueing it repeatedly.
Export database backups (for example with pg_dump) and keep a tested fallback plan (best practice).
Write down what broke for you and how long it took to fix. You’ll need those notes when you read Railway’s incident report.

Railway’s official security guides

Railway has published step-by-step guides for the security disclosure, collected on its engineering blog:

Is Railway down again? Has this happened before?

Railway has had a platform-wide outage before. It was a different, earlier incident, and Railway has not linked it to the current one.

On 19 May 2026, Google Cloud suspended Railway's production project. Railway's own incident report says the suspension followed activity that Google flagged as a Terms of Service violation, and that Google gave no notice before suspending it. The dashboard, API, databases and GCP-hosted compute went offline. Railway's AWS and Railway Metal workloads kept running at first. However, the edge proxies got their routing tables from a control-plane API hosted on Google Cloud. Once the cached routes expired, those apps became unreachable too. Railway puts the impact at roughly eight hours, from 22:20 UTC on 19 May to about 06:14 UTC on 20 May (3:50 AM to about 11:44 AM IST on 20 May). Builds were then brought back gradually.

The incident-management company ilert has a readable breakdown. Its framing differs slightly from Railway's report, which says Google had sent earlier violation notices. Treat Railway's report as the primary source.

The current outage is not that incident. Railway ties October’s disruption to a security incident in which an attacker got into its build and CI systems (preliminary report). Some general lessons still carry over without assuming the same cause:

The control plane and the data plane can fail separately. In both incidents, dashboards, APIs and builds were hit hard. Whether already-running apps stay reachable depends on how much they depend on the control plane.
"Multi-cloud" isn't the same as resilient. One hidden single-provider dependency can take the whole platform down.
Recovery is staged. Railway restored things layer by layer and drained the queue of waiting deploys slowly. That's why "builds are back for Enterprise" doesn't mean "builds are back for you".

Reliability lessons for indie developers and startups

Your deploy pipeline is a dependency too. Many teams plan for their app going down, but not for losing the ability to change it. When builds pause, you can't ship a hotfix, rotate a credential or roll back. This incident showed both problems at once.

Single-provider risk is real, but it's a trade-off. Some developers on X said that moving away from Railway would cost them several times more. That's the honest tension. A sensible middle ground is to keep a documented, tested path to redeploy elsewhere, such as a Dockerfile and an infrastructure-as-code template you have actually run once, without paying for two clouds.

Treat secrets as revocable by design. Use scoped keys with spending limits. Keep an inventory of where each key lives. Write a runbook so you can rotate everything in under an hour. One developer summed it up: any key you can't lose without graceful degradation "is an outage waiting to happen".

Have your own status signals. An external uptime check and alerts on your provider's status page tell you about a problem before your users do.

Communication is part of the system. Railway posted frequent, timestamped updates with promised next-update times, and it published per-provider remediation guides. That's a pattern worth copying for your own incident page, even if all you have is a pinned post.

Frequently asked questions

What is Railway? Railway (railway.com) is a cloud hosting platform (PaaS) for deploying apps and databases. It has no connection to Indian Railways or IRCTC.
Is Railway down today? Is Railway still down? Not for builds. Railway says builds and deployments are normal on every plan and its API is fully restored. It published its preliminary report on 23 Oct and marked the incident resolved at 3:36 AM IST on 24 Oct, though its investigation continues.
When did the Railway outage start? The first status entry is at 07:24 UTC (12:54 PM IST) on 21 Oct 2026.
Was there a Railway security breach (was Railway hacked)? Yes. Railway’s preliminary report says an attacker got into internal systems through its build infrastructure and decrypted environment variables for at most 1.85% of workspaces. Railway says user accounts weren’t accessed.
Do I need to rotate my keys? Yes. Railway recommends that all users rotate every secret stored in Railway and check their logs.
Are my running apps down? Railway’s updates were about builds, deployments, the API, the dashboard and the support site. If your app failed because a provider revoked a key, such as an AI or payments key, deploy the new key now that builds are back. Check your own monitoring and status.railway.com.
Is the Railway outage related to the PHP vulnerability? No public evidence says so. Railway’s disclosure and preliminary report don’t mention PHP. The report describes a privilege escalation in Railway’s build infrastructure. Some posts on X linked the two because the PHP flaws were disclosed the same week, but that’s speculation.
Is there a Railway status page? Yes, status.railway.com. Railway calls it the fastest place for updates.
Why is my Railway API token not working? Railway invalidated all API tokens and Project Tokens created before the security incident. Create a new token in Railway, then update your CI, scripts and CLI.
Are Railway signups paused? Yes. Railway paused new signups at 12:36 AM IST on 23 Oct 2026 to focus on existing customers, and they are still paused. Railway says it will post on the status page when they return.**
Has Railway published an incident report or postmortem? Yes, a preliminary one. Railway published its Preliminary Report: Oct 21st Security Incident at 10:08 PM IST on 23 Oct and says a follow-up will come when its investigation ends.
Will Railway tell me if my account was affected? Railway says it has emailed customers in its risk groups. It can’t tell exactly which keys were decrypted, so it still advises everyone who signed up before 21 Oct to rotate their secrets.
Where are Railway’s security guides? On Railway’s engineering blog at blog.railway.com/engineering. They are also listed in the section above.
Is this related to Indian Railways or IRCTC? No. Railway is a cloud hosting company.

Related guides

Conclusion

As of 24 Oct, Railway’s builds are back on every plan, its preliminary report is out, and it marked the incident resolved at 3:36 AM IST on 24 Oct. Old API tokens no longer work and signups are still paused. The most important action doesn’t depend on Railway at all: revoke and rotate your secrets at their source. The longer lesson is to design for the day your platform stops letting you deploy.

This article will be updated as Railway publishes new information. It is not affiliated with Railway.

Over to you: after this week, would you pay more for a second deployment target, or do you accept the single-provider risk in exchange for Railway's developer experience?

📰 Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.

← News 🔐 Cybersecurity 🏠 Home