TL;DR
Railway published four incident reports in five months covering four unrelated failure domains: its own abuse automation, its CDN, a shared control-plane dependency, and its networking and storage layers.
In May, applications running on Railway Metal and AWS became unreachable for hours while the containers themselves stayed healthy. No action on the customer side would have restored service.
Below $5,000/month in spend, there is no contractual response time. Free and Hobby tiers receive a public forum with no guaranteed reply; Pro receives a private thread, typically within 72 hours, with Railway's own documentation explicitly disclaiming any SLO.
The only hard spending cap Railway offers works by taking your workloads offline.
If you run anything revenue-critical on Railway, this article scopes what leaving involves and what to do this week regardless of whether you leave. It is a smaller project than most teams assume.
Railway made cloud deployment feel straightforward. Point it at a repository, add environment variables, provision a database, and you have a live URL in minutes without touching a VPC or writing reverse proxy configuration. For prototypes and internal tools, that remains a highly efficient developer experience.
The calculation changes when the application becomes a business.
Once customers, transactions, production data, background jobs, and revenue run through the platform, deployment speed stops being the metric that matters. What matters is what happens on the worst day. Can you see the failure? Can you act on it? Will anyone at the vendor respond?
Railway does not publish churn data, and no one can credibly claim a customer exodus. But you do not need churn data to evaluate this. The primary evidence is Railway's own incident reports. They are detailed, candid, and public. Read end to end, they describe a platform whose failure modes most customers cannot see and cannot mitigate.
A contractual escalation path does exist, but it starts at $5,000 a month in spend, which makes it irrelevant to almost every team writing the migration stories below.
That is the case this article makes. The migration stories that follow are corroboration, not proof.
Four Unrelated Failures in Five Months
One outage is a bad week. Four failures in four unrelated parts of the stack is a pattern, and it changes what you can plan for. You are no longer hardening against a known weakness; you are waiting to discover which layer fails next.
| Date | What happened | Confirmed impact | What it tells you |
|---|---|---|---|
| Feb 11, 2026 | An automated abuse-enforcement rule misclassified legitimate services during a staged rollout | Under 3% of the fleet received SIGTERM signals, including Postgres and MySQL services; the dashboard kept showing terminated workloads as active | Railway's own automation took customers down, and the console displayed the wrong status while it happened, so your monitoring indicated everything was fine |
| Mar 30, 2026 | A CDN configuration change enabled caching on domains that had it explicitly disabled | ~0.05% of domains for 52 minutes; GET responses without an explicit Cache-Control header could be served to a different user than the one they were generated for |
A single config push at the edge can turn your application into a data-handling incident, and the only defense was something most teams do not implement by default: setting explicit cache headers on every authenticated route |
| May 19-20, 2026 | Google Cloud incorrectly suspended Railway's production account | Multiple hours. API, dashboard, control plane, builds, deploys, and databases down; once cached routes expired, workloads on Railway Metal and AWS returned 404s despite still running | Your compute being healthy is not the same as your compute being reachable, and reachability is not yours to control |
| July 2, 2026 | Upstream ISP degradation, then a carrier disconnection that removed the last default route at a US East availability zone | ~20 minutes with no stable route to the internet, then storage pinned at a third of capacity and roughly 20,000 private-network links blackholed | Restoring the network did not restore what depended on it; storage reported healthy while two-thirds of servers in the zone sat waiting on disk |
May Is the One That Should Change Your Risk Model
Railway runs workloads across Railway Metal, AWS, and GCP, connected by redundant interconnects. Its edge proxies populate their routing tables from a network control plane API hosted inside Google Cloud.
When GCP suspended the account, the mesh held for about an hour on cached routes. Then the caches expired, the edge could no longer resolve routes to running instances, and applications on Metal and AWS began returning 404s. The containers never stopped. Customers simply could not reach them.
Consider what that means operationally:
- There was no failover you could trigger
- No region you could shift to
- No configuration on your side that would have helped
- No dashboard to work from, because the dashboard was down too
Core services were not confirmed operational again until roughly 04:00 UTC, nearly six hours in. Railway did not move the incident to monitoring until 06:14. For most of that window, the correct action for every Railway customer was to wait.
Railway took responsibility for the architecture and is removing the dependency. It does not change the exposure you were carrying without knowing it.
July Shows the Same Shape at Smaller Scale
A carrier degradation is routine internet weather, and multi-carrier routing handled it correctly. The damage came afterward: a disconnection made without checking which carrier supplied the site's default route, followed by systems that grabbed a bad path during the instability and never re-asserted the correct state once routing recovered.
What makes this dangerous is that everything appeared fine. Routing tables were correct. The storage cluster reported a healthy state. Throughput sat at a third of capacity for nearly two hours until someone found stale connections pinned to a slow management network.
If your own monitoring showed elevated latency that morning, nothing available to you would have explained why.
Teams Leaving or Actively Evaluating an Exit
Railway users are not converging on one replacement because they are not solving the same problem. Some want managed hosting without the incident history. Some want a conventional cloud, chosen deliberately. Some are moving down a layer and taking direct ownership of the server and deployment stack. Some end up on another platform with no notice at all.
| Customer or workload | Destination | Trigger | Evidence type |
|---|---|---|---|
| FeedAI | DigitalOcean App Platform | Latency spikes, incomplete requests, unresponsive endpoints | First-person founder account |
| SoundBoost.ai | Hetzner dedicated server | May outage, unexplained lag spikes, latency, and cost | first-person account, X post |
| Every | Render | Random failures, downtime, unclear communication as AI prototypes became customer-facing products | customer interview published by the destination vendor |
| FastAPI expense-tracker app | AWS EC2 and RDS | Production control, networking visibility, direct database ownership | first-person LinkedIn account post |
| SmartFolio | Coolify on self-hosted VPS | Own the stack; platform limits throttling traffic spikes; lower cost | first-person account, LinkedIn post |
| B2B enterprise app | Microsoft Azure | Emergency migration during the May 19 outage itself, not a planned exit | first-person account, posted live (Hacker News) |
| Growing n8n implementation | Under evaluation | 40+ workflows, concurrency, chained webhooks, long-running executions | First-person account describing migration intent |
FeedAI → DigitalOcean
Incomplete requests and intermittently unresponsive endpoints. The team audited its own application first, concluded the hosting environment was contributing, and moved the API to DigitalOcean App Platform. They report more consistent latency and fewer dropped requests afterward.
The founder suspected hostile traffic but never confirmed it. A platform does not need a total outage to lose a production customer. Unreliable tail latency is sufficient, and it is far harder to get acknowledged.
SoundBoost.ai → Hetzner
SoundBoost.ai is an AI audio-mastering SaaS. Railway was its main server provider when the May 19 outage hit. CEO Berkan Cesur moved the service to a Hetzner dedicated server by early June.
He reports the new setup costs roughly half as much, eliminated unexplained five-minute-scale lag spikes, and, despite the server being in Germany, delivers lower latency to SoundBoost's mostly-US customer base than Railway's US East region did.
Germany beating US East on latency to US customers is the signal here: geography is only one input. A closer region that behaves inconsistently can lose to a farther server with a cleaner, steadier path.
Every → Render
Every is a media and AI company running products including Cora, Monologue, and Locunity. Every's experience provides an accidental controlled comparison.
Cora had been on Render for years with, per its GM, one incident total, later traced to Cloudflare rather than Render. Every's other products ran on Railway, where the company's COO reports downtime "every few days." Same company, same period, two platforms, materially different outcomes.
Consider Locunity's specific failure mode on its own: jobs silently running on stale code after a deploy. That is a correctness bug, distinct from downtime.
Once the gap was obvious internally, Every moved everything to Render; Monologue's migration specifically was completed through the Render CLI and Codex in about an hour.
Provenance matters here: this is a customer story published by the destination vendor, not an independent benchmark. But the internal comparison is difficult to explain away as platform bias. It was the same team choosing where to place trust with their own money.
FastAPI developer → AWS
A developer documented moving an expense-tracker to EC2 and RDS, configuring Gunicorn and Nginx explicitly rather than having them abstracted away. This is an individual project rather than an enterprise migration, but it is a real category of departure. These teams do not want a better PaaS. They want to see and own the decisions Railway was making for them.
SmartFolio → Coolify
Nabeel Ahmed Moolji moved SmartFolio from Railway to a self-hosted VPS running Coolify and completed the migration with zero downtime. Monthly infrastructure cost fell from about $20 to about $8, but he explicitly describes the savings as secondary.
The reason was control: owning Postgres, logs, and the infrastructure underneath the application, and no longer having platform usage limits throttle it during traffic spikes. That puts SmartFolio in the same broad category as the FastAPI migration, but one step further. It is a deliberate move to keep the deployment experience while taking the underlying machine back.
Emergency migration → Azure, mid-outage
The other stories are decisions made with at least some time to plan. This one is what it looks like when a team does not get that consideration.
Posted to Hacker News the night of the May 19 outage: a team running what they describe as a B2B enterprise app moved off Railway to Azure while the outage was still active. They were back up in a couple of hours, helped by the fact that their database had never been on Railway to begin with.
They said they had valued the simplicity, but that the accumulated "mishaps and shortcomings" had made the platform untenable for a B2B enterprise app.
The actionable detail is database portability. A team whose data already lived outside the platform had an emergency exit available in hours. A team whose data was Railway-native did not have that option, regardless of urgency.
Growing n8n deployments
One team chose Railway when a client had a handful of workflows, then grew to 40+ with real-time processing, chained webhooks, code nodes, external APIs, long-running executions, and concurrent jobs. At that point, Railway started to feel limiting.
A separate community report documented repeated Redis ECONNRESET errors, queue failures, worker crashes, and interrupted workflows on Railway. Neither proves Railway cannot run n8n; resource allocation, configuration, Redis behavior, and n8n itself can all contribute.
What they demonstrate is why workflow engines are unforgiving production workloads. An n8n deployment is not a web container. It is workers, queues, Postgres, Redis, private networking, retries, and recovery, all of which have to hold at once.
The Six Problems Underneath Every One of These Stories
1. You Cannot See the Failure
In February, the dashboard showed terminated workloads as active. In July, routing tables looked correct and the storage cluster reported healthy while throughput ran at a third of capacity. In May, the dashboard was gone entirely.
This is the failure mode that should concern an engineering leader most, because it defeats your runbook before you open it. If your monitoring says the platform is fine and your customers say it is not, you will spend the first hour of every incident debugging your own application.
Every team above lost that same hour first, before anyone suspected Railway.
2. Your Blast Radius Is the Whole Platform
Modern applications depend on databases, Redis, workers, cron, private networking, secrets, volumes, domains, and a deploy pipeline. On Railway these are not independent. They share a control plane, and in May that control plane sat on a single provider's account.
The reflex answer is that multi-cloud solves this. May proves it does not. Multi-cloud buys resilience only if no single hosted dependency sits on every path, and route discovery sat on every path.
3. Consistency, Not Averages, Is What Production Runs On
A good average response time is not the measurement. Tail latency, dropped requests, connection stability, retry behavior, and queue recovery are.
FeedAI's problem was request completion, not an outage. SoundBoost reports that moving from Railway US East to a dedicated server in Germany eliminated recurring lag spikes and reduced latency even for a mostly-US customer base. The n8n reports concern Redis disconnections and interrupted long-running executions. July produced two hours where storage looked healthy and ran at a third of speed.
None of this appears in a deployment demo. All of it appears in your support inbox.
The SoundBoost result is a useful reminder that choosing the geographically closest region does not rescue inconsistent infrastructure. Distance is measurable. Jitter, routing quality, and unexplained stalls are what users feel.
4. Your Escalation Path During an Outage Is Priced
Railway's support model is documented. Read it before an incident, not during one.
Trial, Free, and Hobby: community support, no guaranteed response. Pro: private threads, typically within 72 hours, explicitly with no SLO. Railway does not offer email support and does not offer application-level support at standard tiers.
Contractual response times exist. Business Class provides one-hour acknowledgement for P1 production outages, 24/7, starting at $5,000/month in spend, with Slack Connect at $2,000/month committed.
State that plainly: unless you are spending $60,000 a year, your escalation path during a revenue-affecting outage is a public forum post with no guaranteed reply. On Pro, it is a private thread "usually" answered within 72 hours, with Railway's documentation explicitly declining to promise even that. This is a typical case with no stated floor for the worst-case scenario.
That is a coherent commercial model. It is not one most teams have consciously agreed to.
5. Your Spending Cap Is an Off Switch
Railway does provide usage limits: a soft email alert and a hard limit per workspace, covering compute and agent usage separately, with warnings at 75% and 90%. Replica limits cap CPU and memory per replica, and serverless auto-sleep trims idle spend.
Read what the hard limit does. When usage crosses it, Railway takes all your workloads offline. Railway's own documentation calls setting one "a possibly destructive action." Replica limits have the same shape: they protect the invoice by letting the service crash.
The protection against a runaway bill is an outage. The protection against an outage is an unbounded bill. There is no third option.
For a side project, that is acceptable. For a company whose finance team needs a forecast and whose customers need uptime, those are two failure modes wearing one setting.
SmartFolio's experience is a different limit and should not be conflated with the hard spending cap: Moolji says platform usage limits were throttling the application during traffic spikes. The common operational point is narrower. Limits that look like account configuration become runtime behavior when real traffic arrives.
6. Shared Egress and No VPC Peering
Outbound traffic runs through shared IP pools by default. When another tenant on that pool trips a provider's abuse detection, the block can catch everyone sharing the range.
This is not hypothetical: a Railway customer posted to Central Station in June 2026 after every outbound call from two production environments to googleapis.com started failing mid-response. That is a known pattern of Google blocking shared Railway egress ranges, per Railway's own support response.
The prescribed fix, enabling Static Outbound IPs, did not fully resolve it in that case; the static pool got flagged too. Static IPs are still worth enabling, but plan for the possibility that they do not fully insulate you.
Separately, Railway's private networking is a Wireguard mesh scoped to your project and environment, not VPC peering. There is no way to privately bridge a Railway environment to a corporate network or a database in another cloud. That is a hard stop under some compliance regimes, and worth confirming before a security review finds it for you.
What Railway's Own Documentation Makes You Responsible For
Railway has shipped meaningful improvements. Every one of them is an answer to a 2026 failure, and each carries a caveat that only shows up on the day you need it.
| What teams assume | What the documentation says |
|---|---|
| The Postgres you clicked is managed | The Postgres template is explicitly unmanaged, so you own configuration, monitoring, and maintenance, and the docs point you to upstream Postgres HA, repmgr, and pgpool |
| High availability is on | HA is an opt-in conversion to a Patroni, etcd, and HAProxy cluster. It does fail over automatically, but converting drops active connections, changes your connection endpoints, and any hardcoded connection strings outside Railway must be updated by hand |
| PITR means we can restore | A restore provisions a new sibling service and never touches the source. Cutting over is manual. The window starts at the first post-enable backup, not retroactively |
| We have a spending cap | The cap works by taking your workloads offline |
| Someone will answer during an outage | Not below $5,000/month |
None of this is hidden. The problem is that a platform sold on removing infrastructure decisions has quietly left a significant number of them with you, and most teams discover which ones during the incident rather than before it.
Point-in-time recovery you have never rehearsed is not a recovery plan. It is a feature flag.
What Leaving Railway Actually Involves
Teams typically stay on untrusted infrastructure because migration feels unbounded and lives permanently on next quarter's list.
It is a smaller project than it feels, and it is mostly inventory work. Here is the scope.
What Is Actually Coupled to Railway
Work through this list against your project before estimating anything:
- Environment variables that exist only in Railway, including any set as literal values rather than references.
- Every *.railway.internal hostname referenced in application config, connection strings, or worker configuration.
- Railway's cross-service reference syntax does not travel. Each one becomes a real value or a config entry somewhere else.
- Database connection paths like DATABASE_URL versus DATABASE_PUBLIC_URL, plus anything routed through the TCP proxy.
- Volume data requires dumping or streaming out rather than copying, since you have no direct filesystem access.
- Scheduled jobs configured in Railway rather than in your repository.
- Railpack or Dockerfile settings, build commands, pre-deploy commands, and healthcheck paths.
- DNS records and any CDN, WAF, or SSL configuration held at Railway's edge.
Anything on that list that exists only in Railway is both a migration task and, today, a single point of failure. Exporting your secrets to a dedicated secret store and converting every hardcoded .railway.internal hostname into a configuration value are both no-op changes while you remain on Railway. Together, they account for most of the portability work.
The FastAPI and SmartFolio migrations also show why the destination does not have to be another full PaaS. For some teams, the migration is precisely the decision to own more: the database process, logs, reverse proxy, deployment layer, or machine itself. Coolify and similar tooling can preserve much of the push-to-deploy experience without putting the underlying server outside your control.
What You Could Actually Have Done During Each 2026 Incident
Run your own team through the four incidents. Focus on what you would have seen and what you would have reached for. Ask whether any of it would have changed the outcome.
| Incident | What you would have seen | What your team would have tried | Would it have worked |
|---|---|---|---|
| Feb 11 | Services unreachable, plus networking errors from services calling services that were already gone, while the dashboard showed the terminated workloads as active | Redeploy the affected services, because the console said they were fine and your app must therefore be at fault | Barely. Manually triggered redeploys were delayed by back pressure from everyone else redeploying at once. Recovery came from Railway reverting the rule and running automated recovery |
| Mar 30 | Nothing. Application healthy, latency normal, no errors in your logs | Nothing, because there was no signal to act on. You would have learned about it from a confused user or from Railway's email afterward | Not applicable, which is the point. Railway reverted and purged the cache globally; impacted customers were notified after the fact |
| May 19-20 | 503s and "no healthy upstream" on the dashboard and API, then, once route caches expired around 22:35, 404s from containers that were still running fine | Fail over to another region, redeploy, roll back, or open a ticket | No. The API, dashboard, control plane, and build system were all down, and deploys were blocked platform-wide. As recovery began, GitHub started rate-limiting Railway's OAuth and webhooks, so logins and builds failed again. Your terms-of-service acceptance was also reset |
| Jul 2 | Elevated latency and packet loss, then failed connections, disk-bound services, and private networking silently broken between services | Restart workers, scale up, and investigate your own database, since disk-bound symptoms look like a query problem | No. The storage cluster reported healthy while running at a third of capacity, and roughly 20,000 host-to-host private links were blackholed. The fix required Railway terminating stuck connections and restarting mesh networking agents across every host in the affected zone |
Four incidents, four different subsystems, and one consistent answer in the right-hand column.
This is what concentration risk looks like in practice. It is not that a platform had a bad year; every platform has one eventually. It is that in all four cases, the information needed to diagnose the problem and the controls needed to fix it sat on the other side of a boundary you cannot cross. Your incident response reduced to refreshing a status page.
If that is an acceptable position for the workload, Railway is a reasonable choice.
The Bottom Line
Railway solved a real problem and solved it well. Getting from a git repository to a public URL remains among the most efficient developer experiences in the industry. For prototypes, internal tools, and anything where downtime is an inconvenience rather than a cost, it remains a reasonable choice.
For revenue-critical workloads in 2026, the trade has shifted. You are accepting failure modes your monitoring cannot see, a blast radius that spans your entire stack, a spending cap that works by turning you off, and no contractual response time below $5,000 a month. This is in exchange for deployment convenience that several other platforms now offer as well, without the same four postmortems attached.
That trade-off is no longer a technicality worth shrugging off. Four unrelated failure domains in five months is not bad luck; it's a platform still proving it can hold production weight. If you're hosted on Railway today treat this as a platform to exit, not one to keep watching.
Frequently Asked Questions
Why are developers leaving Railway?
Because 2026 produced four unrelated platform failures, and because the pattern underneath them is exposure customers cannot see, mitigate, or escalate. Completed migrations in the stories above go to Render, DigitalOcean, AWS, Azure, Hetzner, and Coolify on a self-hosted VPS, depending on whether the team wants another managed platform or direct control over its infrastructure and recovery.
Did Railway have a major outage in 2026?
Yes. On May 19-20, Google Cloud incorrectly suspended Railway's production account, causing a platform-wide outage that ran for multiple hours. The API, dashboard, control plane, and databases went down. As cached routing information expired, workloads running on Railway Metal and AWS became unreachable despite the containers still running.
Is Railway reliable enough for production?
It can run production applications. Whether it should run yours depends on whether you can absorb a multi-hour outage with no action available to you, a 72-hour support target, and a database you are documented as operating yourself. For prototypes and internal tools, those terms are acceptable. For anything with revenue or compliance attached, they require an explicit decision rather than an assumption.
What are the limitations of Railway databases for production?
The default Postgres template is explicitly unmanaged, so configuration, monitoring, and maintenance are yours. High availability with automatic failover exists but requires an opt-in conversion that drops connections and changes your endpoints. Point-in-time recovery provides roughly a four-week window, but restores into a new sibling service. Cutover is manual and should be rehearsed before you need it.
How responsive is Railway support during production incidents?
Trial, Free, and Hobby receive community support with no guaranteed response. Pro receives private threads, typically within 72 hours, with no SLO. One-hour P1 acknowledgement, 24/7, requires Business Class support at $5,000/month in spend. Railway does not provide email support or application-level debugging at standard tiers.
Can I cap my spending on Railway?
Yes, with a caveat that matters. You can set a soft email alert and a hard limit per workspace, with warnings at 75% and 90%. Hitting the hard limit takes all your workloads offline. Railway's documentation describes setting one as a "possibly destructive action." Replica limits work the same way: they protect the bill by letting the service crash.
How long does it take to migrate off Railway?
For a single service, typically days rather than quarters. The work is dominated by inventory rather than rewriting: secrets, internal DNS hostnames, cross-service variable references, volume data, cron definitions, and domains. Exporting secrets and moving .railway.internal hostnames into configuration are worth doing immediately regardless of whether you migrate, since anything that exists only inside Railway is currently a single point of failure.
Should a startup leave Railway after an outage?
Not reflexively. Ask instead whether the same failure could recur with you equally unable to act. For the May and July incidents, the honest answer is yes. That does not automatically mean migrating tomorrow. It does mean having a tested recovery path and secrets stored somewhere Railway does not control, before the next one.
Top comments (0)