Die Timeline der selbst gehosteten PaaS, und wo die Idee eigentlich herkommt

Jede „Heroku-Alternative“ klingt nach einer neuen Idee, bis man sich die tatsächliche Timeline ansieht – die Kategorie wird seit Heroku selbst etwa alle paar Jahre von einem neuen Team neu aufgebaut, und das, was sich ständig ändert, ist nicht das Kernversprechen (git push, App läuft), sondern wem die Infrastruktur darunter gehört.

Die Ära des „managed everything“

Heroku (2007) definierte die Form, die bis heute alle kopieren: Buildpacks, Dynos, Add-ons, ein git push, der zum Deploy wird. 2010 von Salesforce übernommen, und für fast ein Jahrzehnt bedeutete „PaaS“ im Grunde „Heroku, oder etwas, das versucht, Heroku zu sein“. Der Trade-off war immer derselbe: außergewöhnliche Einfachheit, auf Infrastruktur, die du nie berührst und nie besitzt.

Fly.io (2017) und Render (2018) behielten beide dieses Managed-everything-Modell, griffen aber unterschiedliche Teile davon an – Fly baute darauf, VMs weltweit nah an den Nutzern laufen zu lassen statt in einer Region; Render ging gegen das spezifische Problem vor, dass Teams echte Engineering-Zeit an Infrastruktur-Klempnerarbeit verlieren statt an Produktarbeit. Keiner der beiden änderte, wem der Server gehört. Railway (gegründet am 9. Juni 2020 von Jake Cooper) trieb dasselbe Modell auf eine nahezu null Aktivierungsenergie – den kleinstmöglichen Abstand zwischen „ich habe Code“ und „er läuft“.

Der andere Zweig: die App des Kunden nie selbst hosten

Cloud 66, gegründet 2012, machte eine völlig andere Wette, Jahre bevor es ein Trend war: eine Control Plane über Servern, die der Kunde schon besitzt, statt eine Plattform, die die Server selbst besitzt. Das ist der eigentliche Ursprungspunkt für das Modell, dem Railyard folgt – keine neue Idee, sondern eine aus dem Jahr 2012, die lange brauchte, um offensichtlich richtig zu werden, während Cloud-Rechnungen wuchsen und Vendor-Lock-in teurer wurde, um ihn zu ignorieren.

Coolify griff genau diesen BYO-Server-Faden von der Open-Source-Seite auf – erstmals veröffentlicht am 24. März 2021, und bis Frühjahr 2026 über 50.000 GitHub-Stars, berichtet als die bisher am weitesten erkannte selbst gehostete PaaS. Kostenlos, selbst gehostet, komplett von dir selbst betrieben, einschließlich der Control Plane selbst.

Wo das die eigentliche Wahl hinführt

Die eigentliche Achse ist nicht „welche Plattform hat mehr Features“ – jede Plattform in dieser Liste konvergiert irgendwann auf Buildpacks, verwaltete Datenbanken und Zero-Downtime-Deploys. Die Achse, die seit über einem Jahrzehnt stabil geblieben ist, ist wem die Maschine gehört: Heroku bis Railway vermieten dir den ganzen Stack; Cloud 66 bis Railyard und Coolify geben dir einen Workflow auf Infrastruktur, die dir gehört. Innerhalb dieser zweiten Gruppe ist die nächste Frage genauso alt – gehostete Control Plane, die du nicht selbst betreibst (Cloud 66, Railyard), gegenüber einer selbst gehosteten Control Plane, die du auch selbst betreibst (Coolify). Keine ist strikt besser; es sind unterschiedliche Antworten darauf, wie viel Infrastruktur du persönlich betreiben willst, und das ist die eigentliche Entscheidung seit 2012, keine neue.

Warum die Kategorie sich immer wieder neu erfindet, statt sich zu konsolidieren

Niemand hat das eindeutig gewonnen, weil sich der Trade-off nie in eine Richtung auflöst – alle paar Jahre entscheidet ein neues Team, dass der aktuelle Platzhirsch zu weit in Richtung Komplexität, Preis oder Lock-in abgedriftet ist, und baut eine einfachere Version derselben Kernidee. Das ist kein Zeichen dafür, dass das Problem ungelöst ist; es ist ein Zeichen dafür, dass die eigentliche Antwort „es kommt darauf an, wie viel Infrastruktur du besitzen willst“ ist – und das hat keine einzige richtige Antwort, die den Rest der Kategorie obsolet macht.

Sieh dir an, wie Railyard konkret abschneidet: Heroku, Railway, Render, Fly, Cloud 66.