EssayBy Taiki Noda / 野田大貴05 / 224 min read日本語版 →

When Railway Lost Its Cloud Account for 8 Hours: Single-Cloud Dependency as a Solo Dev

Railway's cloud account was wrongly suspended and its infra went dark for ~8 hours. Here's the realistic hedge a solo dev can take against single-cloud dependency.

This morning's research log surfaced Railway's "Incident Report: May 19, 2026 – GCP Account Suspension." Google Cloud wrongly suspended Railway's account, and for roughly eight hours all of Railway's infrastructure went dark. What went down wasn't only the parts running on GCP — the parts hosted on AWS were dragged along too, because the control plane was entrusted to a single cloud account. Reading it, I felt that at a completely different scale I'm making structurally the same bet.

A wrongful suspension is the kind of outage you can't wait out

A normal outage recovers if you wait. A regional failure, a network partition — once the cause is fixed, your service comes back. A wrongful account suspension is a different species. The infrastructure itself is running; what gets revoked is your right to touch it.

What's frightening about the Railway case is that the suspension wasn't a technical failure — it came from a single decision on the provider's side. The number "8 hours" isn't how long the servers were down; it's how long it took for a human decision to be reversed. SLAs barely cover this class of event. There's no restart, no failover — there is nothing you can do on your end until you reach the other party and they acknowledge the mistake. That, more than anything, is what separates it from an ordinary outage.

A solo dev hangs everything from an even thinner thread

Railway is a company, and it still went dark for eight hours on a single control-plane dependency. A solo dev's structure is thinner. The hosted pieces I run ultimately sit on a small handful of cloud accounts. And those accounts are contiguous with the Google account I use for everyday work and with a single billing card.

So if a payment bounces once, or some automated detection flags the account and locks it, the design is one in which several products vanish at the same time. This is the flip side of running multiple micro SaaS products solo. Just as operations are concentrated in one person, the dependency is concentrated in one person's account too. Railway's eight hours showed me what happens when that point of concentration gets pushed from the outside.

A single binary is a hedge at the distribution layer — but not at the operations layer

This is where the Pure Go single-binary distribution choice pays off, but only halfway. gpdf itself is one binary with no CGO and no external dependencies; users drop it into their own environment and run it. At the distribution layer, gpdf doesn't die even if my cloud account disappears. The binary already in someone's hands keeps running. That's reassuring.

To be honest, though, the hosted API on top of it is a different story. Single binary or not, the thing that actually runs 24/7 and exposes an endpoint lives on someone's cloud. Even after achieving cloud-independence at the distribution layer, at the operations layer you're still hanging from one account. Railway's incident is a case that coldly drives home that asymmetry. The portability of the OSS itself, and the dependency that appears the moment you turn it into a SaaS, have to be reasoned about separately — that's how it feels to me now.

So what does a solo dev realistically do?

I won't land on "just go multi-cloud." Building genuine multi-cloud redundancy as a solo dev doesn't pay back its operational cost, in my view. The realistic answer sits somewhere far more boring.

First, separate the operations account from the everyday account. If the Google account that runs your services is cut off from your daily mail and logins, the odds of a collateral lockout drop. Second, keep your data portable at all times. Even if a whole account disappears, regularly exported data plus a single binary lets you stand the thing back up on another provider. Recovery speed, I think, is decided by export discipline, not by a redundant topology. Third, don't concentrate payment on a single instrument. Railway's case was triggered by a human decision, but the most common trigger for a solo dev is an expired or maxed-out card.

None of this is flashy. But being able to say, after eight hours of downtime, "the data exists, so I can rebuild somewhere else" — that's the realistic insurance for a solo dev, I think.

Common questions

Shouldn't you just go multi-cloud after all?

It depends on scale, is my answer. For a business that hosts other companies' infrastructure the way Railway does, control-plane redundancy is table stakes. For a solo dev's micro SaaS like mine, the cost of building and maintaining multi-cloud redundancy usually exceeds outage-probability × loss. The realistic answer for a solo dev isn't "redundancy" but "portability" — being able to walk to another place carrying your data and your distributables even if one account disappears. As insurance per hour invested, putting the effort there feels more effective.