Every Hopped from Railway to Render. What the Hop Fixed — and the Ceiling It Didn't Touch.

Every moved its entire production fleet from Railway to Render in March 2026 — and moved one product, the AI dictation app Monologue, in about an hour, through the Render CLI driven by Codex. That sentence contains the whole story of hosted-PaaS churn in 2026: the hop was fast, the day-to-day got better, and the ceiling didn't move an inch. Here's the verdict up front, with the receipts below.

If you're comparison-shopping Railway vs Render, this post is the case study that settles which pains a second hosted PaaS actually fixes. If you're already paying the switching-cost tax of a real migration, it's the argument for pricing the own-the-fleet row before you re-sign with a meter.

What Every actually hit on Railway​

Every is the company to watch here because it's the exact profile the post-Heroku PaaS market was built for: a roughly 30-person AI product studio and publication whose subscription bundles journalism with four AI apps — Cora, Sparkle, Spiral, and the dictation app Monologue — serving tens of thousands of paying users. It grew up the way thousands of teams did: prototype on Railway, find traction, wake up one day running production on it.

Production is where the relationship broke. As reported, Every's COO described downtime on Railway occurring every few days, and the company moved everything to Render in March 2026. Note the shape of that failure: not one spectacular outage but a drumbeat of small ones — the failure mode that never makes a status-page hall of fame but slowly converts a platform team into full-time incident babysitters. Railway's developer experience is genuinely best-in-class for going from zero to deployed; Every's story is what happens when "deployed" has to become "operated" at real traffic, with paying users filing the tickets.

The migration itself is the other half of the story. Monologue moved through the Render CLI with Codex driving in about an hour. That number matters less as a benchmark — your topology is not Monologue's — than as a signal about what migrations cost in 2026: the mechanical part (provision services, move env vars, cut over DNS) compresses dramatically when an agent drives a typed CLI, which leaves the judgment part (data migration, rollback plan, verification) as the actual bill. Every paid that bill once. The question the rest of this post answers is what it bought.

Exhibit A: the May 19–20 outage Every never suffered (and why it still matters)​

Timeline guardrail first: Every left Railway in March. The outage below happened May 19–20, two months later. Every didn't suffer it. It matters anyway, because it's the cleanest public demonstration of the exact ceiling class Every's hop didn't exit — the failure mode that lives one layer above any single vendor's engineering.

On May 19, 2026 at 22:20 UTC, Google Cloud suspended Railway's production account over flagged activity, with no prior notice of the suspension. What followed was an ~8-hour platform-wide outage, ending around 06:14 UTC on May 20. The API, dashboard, control plane, and databases went offline. Users saw 503s and couldn't log in. Roughly 10 million services were affected.

The detail that elevates this from "cloud outage" to "architecture lesson" is the cascade. Workloads on Railway Metal (its own hardware) and AWS burst capacity kept running — but Railway's edge proxies populate their routing tables from a control-plane API hosted on GCP. As cached routes expired, those healthy workloads became unreachable anyway, returning 404s because the network control plane could no longer resolve routes to live instances. At peak impact, every Railway workload in every region was unreachable, including ones whose servers never went down.

Recovery then tripped secondary failures: a backlog of blocked deploys, GitHub rate-limiting Railway's OAuth and webhooks after its caches were wiped, even reset terms-of-service records.

Railway deserves credit for the incident report's honesty — "we take full responsibility for the architectural decisions that allowed a single upstream provider action to cascade into a platform-wide outage" is the sentence every vendor should write and few do. As one redundancy retrospective put it, this was not really a cloud outage at all — and a multi-cloud failure analysis showed the cached routes expiring roughly 35 minutes in, which is exactly how "redundant" workloads died on schedule.

But read Railway's sentence as a customer doing vendor diligence, because it names the ceiling precisely: the account, not the infrastructure, was the single point of failure. No container died. A billing-and-policy relationship between two companies flipped a switch, and ten million services followed. That failure class doesn't care which hosted PaaS you picked. It cares whether anyone above you can suspend your world by email.

Fixed vs moved: the audit​

With Every's reasons and the outage's lesson on the table, here's the row-by-row audit the title promised — what a Railway-to-Render hop actually fixes, and what just changes vendors.

Fixed: day-to-day deploy reliability. Every's stated pain was frequency, not singularity — downtime every few days. Render's production operating model (older, more conservative deploy pipeline; managed Postgres with point-in-time recovery; a longer history of operating paying production topologies) directly addresses that class of pain. And the post-hop receipt, while circumstantial, points one way: Every didn't hop again. Six months after the move, it launched Monologue publicly on September 16 — its fourth product, shipped on Render, with the company publicly investing in the platform it moved to. Revealed preference isn't an incident-free certificate, but teams don't launch flagships on platforms that burn them weekly.

Moved: the single-vendor control plane. Render's control plane is Render's, the same way Railway's was Railway's. Render doesn't need to be incident-free to have been the right move — no vendor in this market is — but its status page is a status page: September 2026 alone shows an Oregon API-latency event, degraded builds and deploys, and a 50-minute service instability in Singapore. Better cadence than "every few days" is genuinely worth migrating for. It is not the same as owning the control plane.

Moved: the rented-hyperscaler blast radius. This is the row that should end the "Render is structurally safer" argument. Render runs on AWS and Google Cloud — historically US regions on GCP and EU on AWS. Railway's May outage was literally its GCP account being suspended. Render is, among other things, another GCP tenant: the "account suspension cascades everywhere" failure class applies to it by construction, differing only in probability, mitigations, and luck. Every traded one company's upstream-account risk for another company's upstream-account risk. That's a reasonable trade! It is not an exit.

Moved and repriced: the meter. Hops reprice you; they don't flatten you. Render's April 2026 replan is the exhibit: a roughly $70 seat-fee cut funded by metered bandwidth exposure, where past ~0.5 TB of egress the bandwidth line starts dominating the invoice. Railway meters compute, memory, and egress; Render meters compute, seats (reduced), bandwidth, and managed data. Our September pricing audit priced the same topologies on both and found the managed rows reprice continuously across five dimensions while a flat box reprices once, as one number.

Every's bill changed shape. It didn't change species.

Untouched: owning the blast radius. No hosted-to-hosted migration can fix "we don't own the machines, the network, or the account relationship." That row only moves when the fleet does — onto hardware with your name on the invoice and a control plane you can reach during someone else's incident.

The switching-cost tax (and when to spend it differently)​

Here's the frame that makes hosted-to-hosted churn interesting instead of just sad: migration labor is the real cost of the hop, not compute. Render will currently pay up to $10,000 in migration credits to pull teams off Railway — and as our credits breakdown showed, that grant buys years of compute but zero hours of engineering. The expensive part of Every's move wasn't the Render bill; it was the audit, the data migration, the cutover plan, the verification, the week of held breath. Credits cover the meter. They never cover the migration.

Once you see the labor as the price, the strategic question sharpens: if you're paying the switching-cost tax anyway, why spend it on a lateral move? Both vendors now publish step-by-step guides for migrating off each other — Railway's docs walk you Render-to-Railway, Render's walk you back — which tells you exactly how the industry values your hop: as recurring revenue changing pockets, subsidized at the margin.

The labor you'd spend learning a second control plane, second pricing dimensions, and second status page could instead buy the only move that changes rows rather than vendors: declarative infrastructure on machines you own, where the May-19 failure class (someone else's account suspended) is structurally impossible because there's no someone else.

That's not an argument that Every chose wrong. It's an argument about when to stop hopping.

Hop vs skip: a decision guide​

Hop (Railway → Render, or the reverse) when:

• Your pain is vendor-specific and day-to-day: flaky deploys, missing managed Postgres features, support responsiveness. Every's "every few days" drumbeat is the textbook hop-shaped problem.
• Your team is small enough that ops time is your scarcest resource and the migration can be agent-driven in days, not quarters.
• Your compliance needs are satisfied by either vendor's certifications, and your blast-radius tolerance covers "one company's incident takes us down for hours, rarely."

Skip the hop and price the own-the-fleet row when:

• You've hopped before, or you're comparison-shopping your second vendor in two years. Two hops' worth of migration labor is most of a self-hosting project's budget, spent for zero structural gain.
• Your bill's growth term is egress or data, not compute — the dimensions where flat hardware wins by the widest margin. Past ~0.5 TB/mo egress, price the box; past a few TB, it's not close.
• Your failure tolerance has a compliance or revenue floor: regulated data, SLAs you signed, or a launch where "our vendor's upstream suspended their account" is not an acceptable postmortem sentence.
• You run AI-agent sandboxes or other untrusted-tenancy workloads, where noisy-neighbor contention and device scheduling need node-level control no hosted PaaS sells you.

The honest middle: hop now if you're bleeding, but treat the hop as the last one — migrate onto portable primitives (plain Postgres, standard containers, env-driven config) so the next move, to your own fleet, is cheaper than this one was.

The churn is the tell​

Step back and the market pattern is unmistakable: Heroku in sustaining mode, Railway throttling tiers and suffering an account-level outage, Render subsidizing exits with credits, both vendors maintaining defection guides for each other's customers. Hosted PaaS in 2026 is a genuinely contested buyer's market — and contested markets optimize for acquisition, not for your blast radius. Every's hop was rational, well-executed, and worth it on its own terms. It also left every structural risk exactly where it found it, under a different logo.

That's why hosted-to-hosted churn belongs in the self-hosting case next to the hosted-to-self-hosted migrations: each hop proves teams will pay real switching costs for reliability, while proving the ceiling is structural — no vendor selection fixes a rented account. The teams that stop hopping aren't the ones that found the perfect vendor. They're the ones that realized the vendor was never the variable.

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.