The self-hosted PaaS timeline, and where the idea actually came from

Every “Heroku alternative” sounds like a new idea until you look at the actual timeline — the category has been rebuilt by a new team roughly every few years since Heroku itself, and the thing that keeps changing isn’t the core promise (git push, get a running app), it’s who owns the infrastructure underneath it.

The managed-everything era

Heroku (2007) defined the shape everyone still copies: buildpacks, dynos, add-ons, a git push that becomes a deploy. Acquired by Salesforce in 2010, and for close to a decade “PaaS” basically meant “Heroku, or something trying to be Heroku.” The tradeoff was always the same: extraordinary ease, on infrastructure you never touch and never own.

Fly.io (2017) and Render (2018) both kept that managed-everything model but attacked different parts of it — Fly built around running VMs close to users globally rather than one region; Render went after the specific pain of teams losing real engineering time to infrastructure plumbing instead of product work. Neither changed who owns the server. Railway (founded June 9, 2020, by Jake Cooper) pushed the same model toward near-zero activation energy — the smallest possible gap between “I have code” and “it’s running.”

The other branch: never host the customer’s app

Cloud 66, founded in 2012, made a different bet entirely, years before it was a trend: a control plane over servers the customer already owns, rather than a platform that owns the servers itself. That’s the actual origin point for the model Railyard follows — not a recent idea, a 2012 one that took a long time to become obviously correct as cloud bills grew and vendor lock-in got more expensive to ignore.

Coolify picked up that same BYO-server thread from the open-source side — first released March 24, 2021, and by spring 2026 past 50,000 GitHub stars, reportedly the most widely recognized self-hosted PaaS to date. Free, self-hosted, run entirely by you, including the control plane itself.

Where that leaves the actual choice

The real axis isn’t “which platform has more features” — every platform in this list converges on buildpacks, managed databases and zero-downtime deploys eventually. The axis that’s stayed stable for over a decade is who owns the machine: Heroku-through-Railway rent you the whole stack; Cloud 66-through-Railyard and Coolify give you a workflow on top of infrastructure that’s yours. Inside that second group, the next question is just as old — hosted control plane you don’t operate (Cloud 66, Railyard) versus self-hosted control plane you run yourself too (Coolify). Neither is strictly better; they’re different answers to how much infrastructure you personally want to operate, and that’s been the actual decision since 2012, not a new one.

Why the category keeps getting rebuilt instead of consolidating

Nobody’s won this outright because the tradeoff never resolves in one direction — every few years, a new team decides the current leader has drifted too far toward complexity, or price, or lock-in, and builds a simpler version of the same core idea. That’s not a sign the problem is unsolved; it’s a sign the actual answer is “it depends on how much infrastructure you want to own,” which doesn’t have a single correct answer that makes the rest of the category obsolete.

See how Railyard specifically compares: Heroku, Railway, Render, Fly, Cloud 66.