Where Post-Railway Workloads Land: Six Destinations and the Hetzner Math

On the night of May 19, 2026, thousands of containers kept running while the platform around them disappeared. Google Cloud incorrectly suspended Railway's production account at 22:20 UTC — a customer reportedly spending about $2 million a month on GCP — taking the API, dashboard, control plane, builds, deploys, and databases offline for roughly eight hours. Railway's edge proxies held for about an hour on cached routes, then the caches expired.

Workloads on Railway Metal and AWS, machines Google never touched, started returning 404s. The containers never stopped; customers simply could not reach them. Railway's own incident report, published the next morning, confirms every word of that sequence.

That outage is the centerpiece of a detailed 2026 exit roundup collecting completed migrations off Railway, and this post is a destination-by-destination read of where those workloads actually landed. Here is the verdict first: the six exits scatter across six different destinations because the teams are solving different problems — but every exit is priced the same way, as a one-time migration against a meter that never stops. Once the exit is paid for, the same small-production workload that costs about $128 a month on Railway's meter fits many times over on a flat-rate dedicated box at roughly €44 a month, and the marginal cost of one more app on hardware you already own drops to near zero.

Six exits, six destinations: what each one buys, and what it re-buys​

No single replacement is winning because no single complaint is driving the exits. Some teams want managed hosting without the incident history. Some want a conventional cloud chosen deliberately.

Some are moving down a layer and taking the machine back. Read each destination as a trade, not a verdict:

Two of these rows deserve a closer look because their evidence is unusually sharp. SoundBoost.ai, an AI audio-mastering SaaS, moved from Railway to a Hetzner dedicated server in Germany by early June under CEO Berkan Cesur — and reports lower latency to its mostly-US customer base than Railway's US East region delivered, alongside the elimination of recurring five-minute-scale lag spikes. Geography is only one input to latency; a closer region that behaves inconsistently can lose to a farther server with a cleaner, steadier path. Jitter and routing quality are what users feel, not kilometers.

Every, the media and AI company, provides an accidental controlled comparison: its Cora product ran on Render for years with one incident total, later traced to Cloudflare rather than Render, while its Railway-hosted products suffered downtime every few days, in COO Brandon Gell's words — same company, same period, two platforms, materially different outcomes. One caution the roundup itself flags: this is a customer story published by the destination vendor, not an independent benchmark. Treat the migration-hour claim as marketing-adjacent and the internal comparison as the substantive part.

The Azure row carries the most actionable lesson in the whole roundup. A team running a B2B enterprise app migrated mid-outage, posted live to Hacker News, and was back up in a couple of hours — possible only because their database had never lived on Railway. A team whose data was Railway-native had no such option regardless of urgency. Database portability is the difference between an exit and a hostage situation.

The costing question the roundup never asked​

The roundup prices nothing except the two first-person data points it was handed: SoundBoost at roughly half the cost on Hetzner, SmartFolio from about $20 to about $8 a month on Coolify. But Railway's meter is public — $20 per vCPU per month, $10 per GB of RAM per month, $0.05 per GB of egress, $0.15 per GB of volume storage — so the missing comparison can be computed directly. Take two representative workloads, not one convenient point.

A side-project footprint — one small service with about 1 vCPU and 2 GB of RAM, a 10 GB volume, 50 GB of egress — meters to roughly $20 to $45 a month on Railway depending on exact sizing, consistent with the $20 SmartFolio was paying. The same footprint on a small VPS running Coolify costs roughly $8 all-in, SmartFolio's reported number. At this size the meter is a convenience fee of 3 to 5x over the VPS, and for a hobby that fee is perfectly rational.

A small-production footprint — a web service plus a worker plus Postgres, 3 vCPUs and 6 GB of RAM total, a 20 GB volume, 100 GB of egress — meters to about $128 a month on Railway: $60 of CPU, $60 of RAM, $3 of volume, $5 of egress, with the $20 Pro base absorbed into usage. That entire footprint fits many times over on a single flat-rate dedicated box in the AX41 class — 12 threads, 64 GB of RAM, NVMe storage — at roughly €44 a month after Hetzner's mid-2026 repricing. The meter costs nearly 3x the box while delivering a fraction of its headroom.

Two sensitivity notes keep this honest. First, utilization cuts both ways: a half-empty dedicated box still beats the meter here, but spiky or mostly-idle workloads that genuinely sleep can meter for less than any always-on server — that is the one shape where per-use pricing wins. Second, egress is the sleeper line: 100 GB costs $5 on Railway and effectively nothing against a dedicated box's included tens of terabytes, but at a terabyte a month the meter adds $50 while the flat box adds zero. Egress-heavy workloads widen every gap above.

And there is a second-order effect the roundup never mentions. On a metered PaaS, every preview environment, every staging copy, every load-test clone meters independently — environments multiply the bill. On hardware you already own, managed as a fleet, the marginal cost of one more app or one more ephemeral environment is near zero: the nodes are sunk, and bin-packing absorbs the rest. Teams price the exit as one migration project and forget to price the meter as a per-environment tax that compounds with every service they add.

What Railway did after May​

Fairness requires the other half of the story, because Railway responded substantively. Its May 28 summer update declares Q2 2026 a reliability-foundation quarter and reports the cutover to a fully distributed network router: if a single cloud goes down, traffic routes over backup links between Metal, AWS, and GCP instead of depending on one provider-hosted control plane. The incident report commits further — high-availability database shards extended across AWS and Metal so quorum survives a cloud disappearing, Google services demoted to secondary and failover roles only, and a control- and data-plane redesign aimed at vendor independence — alongside second-generation Metal hardware and four new datacenter sites.

So the honest stay conditions are narrower than "never use Railway" and wider than "nothing happened." Prototypes, internal tools, and anything where downtime is an inconvenience remain reasonable on the platform; deployment speed is still genuinely excellent. Staying for revenue-critical workloads is defensible only as an explicit decision: secrets exported to a store Railway does not control, no hardcoded internal hostnames, a rehearsed restore, and a tested recovery path — the roundup's own checklist, completed before the next incident rather than during it.

Note what even the fix list does not change: Pro support still targets 72 hours with no SLO, the hard spending cap still works by taking workloads offline, and Postgres on the default template is still explicitly unmanaged. Those are product choices, not incident aftermath.

What an exit actually involves​

Teams stay on infrastructure they no longer trust because migration feels unbounded. The roundup's scoping section is the best antidote to that: an exit is mostly inventory work, completable in days for a single service, not quarters. Work through what is actually coupled to Railway: environment variables that exist only in the dashboard, every internal hostname in application config and connection strings, cross-service reference syntax that does not travel, database connection paths and anything routed through the TCP proxy, volume data that must be dumped or streamed out, scheduled jobs defined in Railway rather than in the repository, build and healthcheck settings, and DNS plus edge TLS configuration.

Two of those items are worth doing this week whether or not you leave, because each is both a migration task and a live single point of failure: export every secret to a dedicated secret store, and convert every platform-internal hostname into a configuration value. Both are no-op changes while you remain. The Azure mid-outage story adds the third: know exactly how your database leaves the platform, and confirm the answer before a security review — or an outage — asks for you.

The meter is forever; the exit is once​

Four unrelated failure domains in five months — abuse automation in February, the CDN in March, the GCP suspension in May, carrier and storage in July — is what makes this a platform evaluation rather than an incident retrospective. Any one of them is a bad week; four in four different subsystems is a pattern that changes what you can plan for. The six destinations show there is no consensus replacement, only a consensus that deployment convenience no longer settles the argument by itself.

Price the decision the way the roundup does not: the exit is a bounded, one-time inventory project, while the meter reprices every workload, every environment, and every gigabyte forever — against flat hardware that still prices each unit of headroom at a fraction of the meter. That is the calculation that lands teams on Hetzner and Coolify rather than merely on a different meter.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.