Google Cloud blocks Railway: your PaaS has a landlord problem

What happened

On May 19, 2026, Railway's status page recorded an incident with an unusual root cause: the platform itself was being blocked by Google Cloud, the hyperscaler underneath portions of its infrastructure. The Hacker News thread, currently at 518 points, captured what every senior infra engineer already suspects but rarely sees stated this plainly — when your PaaS rents from a public cloud, the public cloud can shut the door, and there is no appeals process that runs on your timeline.

Railway has spent the last several years building a developer-friendly Heroku successor: push to deploy, services as primitives, a clean control plane on top of someone else's iron. The 'someone else's iron' part is the load-bearing detail. When Google Cloud blocks Railway, every Railway customer downstream becomes collateral damage in a dispute they had no part in and cannot influence.

Details on the specific trigger remain thin as of this writing — Railway's status page is the primary public artifact, and Google has not posted a corresponding public note. The pattern, however, is familiar: abuse heuristics, billing flags, or compliance reviews at a hyperscaler can produce automated enforcement actions that take hours or days to unwind, regardless of how legitimate the downstream workload is.

Why it matters

The interesting thing about this outage is not that it happened. Infrastructure breaks. The interesting thing is the shape of the dependency it exposes. Railway customers chose Railway specifically to *not* think about Google Cloud. They wanted services, environments, and a deploy pipeline — not IAM, VPCs, and project quotas. The trade was: pay a premium, skip the YAML. The bill for that abstraction came due in the form of a failure mode customers cannot remediate, monitor, or even fully understand.

Compare this to the AWS-us-east-1 events of the past decade. Those outages were brutal, but they were *symmetric*: everyone on us-east-1 went down together, and Amazon owned both the cause and the fix. A PaaS-being-blocked-by-its-cloud outage is asymmetric. Railway's other tenants on Google Cloud are fine. Google's other PaaS customers are fine. Only the Railway-on-GCP intersection is broken, and the people inside that intersection have a vendor relationship with exactly one of the three parties needed to resolve it.

The community reaction on HN reflects the discomfort. Threads split between sympathy for Railway (who has built a genuinely good product), frustration at the opacity of hyperscaler enforcement, and a quieter strain of 'this is why we self-host.' The self-hosting camp is overstating its case — running your own Kubernetes is not a free lunch — but they're not wrong about the principal-agent problem. Your PaaS's incentives align with you right up until their cloud bill, their compliance posture, or their abuse signals say otherwise.

There's also a market-structure question here. Heroku's slow decline created an opening. Render, Railway, Fly.io, and a handful of others have filled it, each leaning on AWS, GCP, or their own bare-metal footprint. The ones renting from hyperscalers are building businesses whose continuity depends on a relationship they don't fully control. Fly.io's bet on owning its own hardware looks more defensible after a day like this, even if the operational cost is higher. The PaaS market may quietly bifurcate along this axis: 'we own the racks' versus 'we resell someone else's racks with a nicer UI.'

What this means for your stack

If you ship on a PaaS, today is a good day to write down three things. First: what is your actual blast radius? Not the marketing 'multi-region' answer — the real one. If your PaaS disappears for 24 hours, what breaks, what degrades, what survives? Most teams have never been forced to answer this because their PaaS has not, until recently, been the failure domain.

Second: what is your portability cost? Railway and competitors all support Docker, Postgres, and standard runtimes. The lock-in is rarely the runtime — it's the control plane: secrets, environment promotion, preview environments, the deploy graph. Estimate, in person-days, what it would take to redeploy your production stack on a different PaaS or directly on a cloud. If the number is 'we don't know,' that is itself the finding.

Third: what does your status communication look like when your provider's provider is the problem? Your users do not care that Google blocked Railway. They care that your app is down. The maturity of your incident comms is now partly a function of how clearly you can explain a four-party outage in two sentences.

For teams choosing a PaaS today, the question is not 'is Railway good' — by most accounts it is — but 'what is the substrate, and what is the substrate owner's track record of treating downstream tenants as customers vs. inventory?' That's a question worth asking on every sales call, and the honest answer should be in your runbook.

Looking ahead

Railway will recover from this specific incident. The harder question is whether the PaaS market, collectively, treats this as a wake-up call or a one-off. Expect contracts to start carrying language about substrate transparency, expect serious customers to ask for multi-substrate options, and expect at least one PaaS to make 'we own our hardware' the headline of its next funding round. The Heroku-era assumption that the abstraction below your abstraction is somebody else's problem is, at minimum, due for an audit.