The Reverse Migration: Why Teams Quit Self-Hosting and Go Back to Managed PaaS

Every month, another team publishes a Heroku-to-Hetzner victory lap: the bill dropped 80 percent, latency improved, the migration took a weekend. Those posts are real, and the math in them usually checks out. But there is a second migration running in the opposite direction that almost nobody blogs about — teams that tried a self-hosted PaaS, burned out on operating it, and quietly moved back to Render or Railway at three to five times the infrastructure cost.

You can see its traces in Hacker News threads and r/selfhosted retrospectives. In "Self hosting in 2023," one operator admits moving services back to third-party hosting over persistent anxiety about unexpected downtime or data breaches. In "Self-Host All the Things?", another describes shutting down everything public-facing and moving it all to the cloud. The Barclays CIO Survey found the share of respondents planning cloud repatriation rose from 49 percent to 69 percent — the toward-ownership flow is loud and measured. The reverse flow is quiet because nobody writes a triumphant post about paying more to stop getting paged.

This post is the honest catalog of that reverse migration: the failure modes that push teams back, which ones are inherent to owning machines versus artifacts of hand-assembling a platform from a dozen parts, and the specific checklist that separates the teams who stay self-hosted from the teams who bounce back within a year.

The math that pulls teams back​

Start with the numbers, because the reverse migration is first and foremost a pricing story told backwards. Take a typical small-production stack — one web service, one background worker, Postgres, and Redis — and price it three ways.

The infrastructure delta is real: roughly 4x. A Hetzner CX23 starts at €5.49 a month plus €0.50 for IPv4, and one step up fits this entire stack. (Render list prices: Starter web service $7, Standard $25 with 100 GB egress included; managed Postgres from $7 to $20.) That is the number that launches a thousand migrations off managed platforms.

Now price the other side of the ledger. The owned column's "you handle all of it" is doing enormous work in that table. Backups are not included — Hetzner's own backup service costs an extra 20 percent of the server price, and that covers the box, not tested point-in-time recovery of your database. There is no managed Postgres failover, no support engineer, no formal uptime SLA. Routine care — OS patching, platform upgrades, certificate monitoring, log rotation, capacity watching — runs two to four hours a month when nothing is wrong. And something is eventually wrong: a full disk at 2 a.m., a TLS renewal that silently failed, an OOM-killed database.

For a solo founder whose alternative is an evening of unpaid toil, that trade still wins. For a team of three engineers whose time is billed against a roadmap, one bad night a quarter erases the entire year's infrastructure savings. The teams that reverse-migrate almost never dispute the 4x infra math. They learned that infrastructure was never the whole bill.

The failure-mode catalog​

Across the 2026 retrospectives, the same five failure modes recur. Each is concrete, each has a recent example, and together they explain nearly every bounce-back.

1. The unpatched platform CVE. A self-hosted PaaS is itself internet-facing software with a steady stream of security releases — and unlike a managed platform, nobody applies them but you. In January 2026, Coolify disclosed eleven critical flaws enabling authentication bypass and remote code execution, amounting to full server compromise on affected self-hosted instances. Patches shipped promptly, with version 4.0.0-beta.445 addressing the headline CVE. But every team running Coolify had to notice the disclosure, schedule the upgrade, and survive it themselves. For teams that treat the PaaS layer as install-and-forget, a disclosure like that is the moment the bill comes due all at once — or worse, never, leaving a known-RCE box facing the internet.

2. Backups that existed but were never restore-tested. Almost every bounce story involves backups that were theoretically fine. Coolify ships database backups, but community tooling built around its v4 gaps exists precisely because the defaults are thin: database backups stored as plaintext on S3, no volume or config backups, no guarded major-version upgrades. The pattern repeats everywhere: the backup job ran, the restore was never rehearsed, and the first real restore attempt happens during the incident it was supposed to save. A backup you have never restored is a rumor, and teams discover this at the worst possible hour.

3. The 2 a.m. pages nobody signed up for. Full disks from unrotated Docker layers and logs. A Let's Encrypt renewal that failed silently sixty days ago and expired overnight. A memory leak that finally OOM-killed Postgres on a box with no swap and no alerting. None of these is exotic; all of them are handled invisibly by a managed platform's on-call rotation. On a self-hosted box, the on-call rotation is whoever set it up, forever. The September 2026 Ownkube comparison of self-hosted PaaS options puts it bluntly: Coolify, Dokku, and CapRover each carry a "High" ops burden, and "for the wrong team they quietly become a second job."

4. The single-node ceiling. Single-box tools are superb until the second machine. Coolify is at its best on one server or a small handful, with multi-node orchestration that the same comparison calls rough; Dokku is single-node by design; CapRover's Swarm-based scaling turns fragile beyond a few nodes. The team that adopted a single-box tool for its first app discovers the seam exactly when growth demands a second server: no fleet-wide provisioning, no declarative machine lifecycle, no story for spreading load. Replatforming under growth pressure is how teams end up back on a managed platform — not because self-hosting failed, but because their particular self-hosting tool had a ceiling they hit at the worst time.

5. Bus factor of one. The person who built the box understands the box: the undocumented firewall rule, the cron job that restarts the queue worker, the reason TLS renewals need a manual DNS prod. Then they go on vacation, get sick, or leave. The remaining team inherits a machine they can neither confidently change nor confidently leave alone. Managed platforms are, among other things, institutional memory sold as a service — and teams that bounce back are often buying back exactly that after their single operator becomes a single point of failure.

Inherent to ownership vs assembled by hand​

Here is the question that decides whether the reverse migration was inevitable or avoidable: which of these failures come from owning machines, and which come from bolting together a platform from a dozen parts by hand?

Modes 1 and 2 — unpatched CVEs and untested backups — are overwhelmingly assembly artifacts. A managed platform patches itself and proves its restores continuously; a self-hosted stack can do both too, but only if upgrade automation and restore drills were built in on day one rather than deferred to "later." Teams that bounce on these modes did not fail at ownership. They failed at building the boring automation that ownership requires, usually because no tutorial's "deploy in an afternoon" guide includes it.

Mode 4, the single-node ceiling, is a tooling choice, not a law of physics. It is inherent to single-box tools and absent from fleet-native ones. A team running declarative machine lifecycle over its servers — machines as reconciled API objects, not pets with SSH histories — adds a second server the way it added the first. The seam only exists where the platform stops at the box boundary.

Modes 3 and 5 — the pages and the bus factor — are the genuinely inherent ones, and they are really the same mode wearing two costumes: someone must be responsible for the machine, at every hour, with documented knowledge. Automation shrinks this surface enormously — alerting that fires before the disk is full, renewals that page on failure rather than expiring silently, runbooks that let the second person act. But the residual is irreducible: owned infrastructure has an owner, and that owner is on call. Teams that accept this explicitly, with rotations and runbooks, stay. Teams that discover it at 2 a.m. leave.

The honest summary: roughly two-thirds of the reverse migration is teams paying for automation they never built, on tooling with a ceiling they never checked. Only the last third is the true cost of ownership — and it is a real cost, not a failure to optimize.

The stay-self-hosted checklist​

The teams that stay self-hosted are not luckier and not necessarily more skilled. They did a short list of unglamorous things before they needed them. If you are self-hosting today or considering it, this is the checklist that separates stayers from bouncers:

• Automated, scheduled upgrades. OS patches and platform releases on a calendar with a staging pass — not "when someone remembers." The January Coolify disclosure is the test case: would your fleet have been patched within days without heroics?
• Off-box backups with rehearsed restores. Backups on separate infrastructure, encrypted, with a restore drill on a fresh machine at least quarterly. If you have never restored onto a blank box, you do not have backups.
• Health alerting that fires before the page would. Disk usage, memory pressure, certificate expiry, failed backup jobs, failed renewals — each with a threshold and a destination that is not "notice the site is down."
• A second person with root. Documented access, a written runbook for the five most likely incidents, and at least one drill where the primary operator is unavailable. Bus factor of one is a pre-incident, not a risk.
• Capacity headroom and a growth plan. Know which resource exhausts first and what the next step is — a bigger box, a second box — before growth forces the decision. Single-box teams should name their ceiling explicitly.
• A defined exit. Ironically, the teams most likely to stay are the ones that could leave: portable compose or manifest definitions, data export tested, DNS cutover rehearsed. Optionality removes the trapped feeling that turns one bad incident into a permanent retreat.

None of these items is expensive. Together they cost a focused week to establish and a few hours a month to maintain. Compare that against the managed premium — roughly $50 a month for the stack in our table — and the checklist pays for itself the first time any single item fires. The teams that bounce are overwhelmingly teams that skipped the checklist, not teams for whom it failed.

Who should go back anyway​

Honesty cuts both ways. The checklist has a price in sustained attention, and some teams should look at it and choose managed deliberately rather than fail at it accidentally.

If nobody on the team wants the pager — not as a theoretical rotation, but as a real 2 a.m. phone — go managed. If the product is pre-revenue and every engineering hour compounds into the only thing that matters, go managed; 37signals can save $10 million over five years on owned hardware because it staffs the ownership, and your two-person startup is not 37signals. If compliance needs (SOC 2 evidence, audited access logs, contractual SLAs) would cost more to build than the platform premium, go managed. These are not defeats. They are the same arithmetic, solved correctly for a different team.

But if you have the appetite — even one person who treats the checklist as craft rather than chore — the reverse migration is avoidable. The infrastructure math still favors ownership by 4x. The failures that reverse it are, in most cases, automation that was never built and ceilings that were never checked. Build the automation, check the ceiling, rehearse the restore, and write down the runbook. The box will hold.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with the declarative fleet lifecycle that single-box tools stop short of. Star the repo on GitHub or deploy your first app today.