Der große PaaS-Umzug: Was Alternativen zu Heroku für dein Startup bedeuten

Mal ganz ehrlich: Die Heroku-Nachricht hat die Entwickler-Community wie ein unerwarteter Plot-Twist getroffen. Als Salesforce das Ende der kostenlosen Dynos und Änderungen bei der Preisstruktur ankündigte, war das kollektive Stöhnen in jedem Dev-Discord und auf jedem Twitter-Thread zu hören. Plötzlich fühlte sich diese Plattform, auf die sich viele von uns für alles verlassen hatten – vom Hobbyprojekt bis zur Produktionsumgebung – nicht mehr wie ein sicherer Hafen an, sondern wie eine teure Beziehung, aus der man möglichst elegant aussteigen wollte.

Also begann natürlich das große Hin und Her der Migrationen. Plattformen wie Render, Railway, Fly.io und andere standen plötzlich im Rampenlicht und beantworteten Fragen von Entwicklern, die wissen wollten: „Bist du die Richtige?"

Da ich diese Migrationswelle aus der Nähe beobachtet habe – und meine eigenen Gedanken dazu entwickelt habe, was eine gute Hosting-Plattform wirklich ausmacht – möchte ich dir meine Perspektive geben. Hier erfährst du, was dich wirklich erwartet, wenn du Herokus komfortable Umgebung verlässt.

Die Verlockung des Preisetiketts

Hier ist das Versprechen, das immer wieder gemacht wird: „Wechsle zu unserer Plattform und spare 30 bis 40 Prozent bei deiner Hosting-Rechnung."

Und ja, die Rechnung geht auf. Je nach deiner aktuellen Heroku-Konfiguration können die Ersparnisse erheblich sein. Für ein Startup, das Geld für mehrere Dynos, Worker-Prozesse und Datenbank-Instanzen verbrennt, ist es durchaus befriedigend zu sehen, wie diese Posten schrumpfen.

Aber hier ist, was einem das Marketing verschweigt: Du migrst nicht nur das Hosting. Du migrst Denkmodelle, Arbeitsabläufe und eine gewisse operative Verantwortung, die Heroku stillschweigend für dich übernommen hatte.

Den Mentalitätswandel verstehen

Hier wird es spannend – und manchmal frustrierend.

Heroku funktioniert nach dem, was ich ein „anwendungszentriertes" Modell nennen würde. Du deployst eine App, und diese App enthält verschiedene Prozesstypen (Web, Worker, Clock usw.), die als zusammenhängende Einheit zusammenarbeiten. Die Plattform versteht, dass diese Prozesse zusammengehören. Lifecycle-Events, Umgebungskonfiguration und Deployment-Pipelines berücksichtigen diese Beziehung.

Viele moderne PaaS-Plattformen gehen anders vor. Nicht Apps sind die Grundeinheit, sondern einzelne Services oder Prozesse werden zu erstklassigen Bürgern. Das bietet mehr Flexibilität – du kannst Komponenten unabhängig skalieren, konfigurieren und deployen. Aber es bedeutet auch, dass du zum Koordinator wirst.

Stell es dir vor wie den Unterschied zwischen einer möblierten Wohnung und dem Bau deines eigenen Tiny Houses. Die Wohnung (Heroku) kommt mit Möbeln, eingerichteten Versorgungsleitungen und einem Hausmeister, der sich um die Wartung kümmert. Das Tiny House (moderner PaaS) gibt dir vollständige Kontrolle – aber plötzlich denkst du über Sanitär, Elektrik und wo das Sofa stehen soll nach.

Die Migrationsrealität

Reden wir darüber, was passiert, wenn du umziehst.

Die meisten Plattformen haben großartige Arbeit beim „ersten Deployment" geleistet. Verbinde dein GitHub-Repository, konfiguriere ein paar Umgebungsvariablen, klicke auf Deploy, und zack – du bist in der Produktion. Dieser Teil ist wirklich beeindruckend, und die Konkurrenten haben hier von Herokus frühem Erfolg gelernt.

Aber deine Anwendung ist kein einzelner Service. Es sind fünf. Oder zehn. Oder mehr. Und jeder dieser Services muss konfiguriert, deployed und gewartet werden. Jeder hat seinen eigenen Build-Prozess, seine eigenen Skalierungsregeln, seine eigenen Health-Checks.

Plötzlich deployst du nicht nur Code – du verwaltest ein Sternbild von Services, die zusammenarbeiten müssen, aber nichts voneinander wissen.

Wo es kompliziert wird

Hier ist ein Szenario, das ich immer wieder erlebt habe: Du erstellst eine blueprint.yaml oder ähnliche Konfigurationsdatei, um deine Infrastructure-as-Code zu definieren. Das ist großartig! Alles ist dokumentiert, versioniert und reproduzierbar.

Dann schaust du im Web-Dashboard nach etwas und bemerkst eine Einstellung, die nicht ganz zu deiner YAML-Datei passt. Also aktualisierst du sie über die UI. Welche ist jetzt maßgebend? Die Datei, die du in Git committet hast, oder die Dashboard-Einstellung, die gerade gespeichert wurde?

Das ist keine theoretische Überlegung. Diese Mehrdeutigkeiten schaffen Verwirrung, und Verwirrung bei der Infrastruktur ist gefährlich. Wenn um 2 Uhr nachts etwas kaputtgeht, musst du genau wissen, wo du nachschauen musst.

Die versteckten Kosten von „Mehr Besitz"

Moderne PaaS-Plattformen werben oft damit, dass du „mehr" von deiner Infrastruktur besitzen wirst. Das wird als Ermächtigung präsentiert, und in vielerlei Hinsicht ist es das. Mehr Kontrolle, mehr Übersicht, mehr Möglichkeiten zur Anpassung.

Aber Besitz hat seinen Preis. Wenn Herokus Routing-Schicht ein Problem hat, eröffnest du ein Support-Ticket. Wenn dein Render-Deployment ein Netzwerkproblem hat, debuggst du Load-Balancer-Konfigurationen. Wenn deine Fly.io-App spezifische Kernel-Parameter braucht, liest du Dokumentation, die tiefes Infrastruktur-Wissen voraussetzt.

Die Frage ist nicht, ob diese Plattformen schlecht sind. Sind sie nicht. Die Frage ist, ob dein Team die Kapazitäten, das Know-how und die Lust hat, diese operative Komplexität einzugehen – im Austausch für die Kostenersparnis.

Die richtige Wahl für deine Situation treffen

Also, solltest du migrieren? Die Antwort ist – wie so oft –: Es kommt darauf an.

Bleib näher an Herokus Einfachheit, wenn:

• Du noch in der Anfangsphase bist und schnell vorankommen musst
• Dein Team klein ist oder du viele Hüte auf einmal trägst
• Deine Infrastrukturanforderungen relativ Standard sind
• Developer Experience und Geschwindigkeit wichtiger sind als das letzte Quäntchen Sparpotenzial

Umarm die moderne PaaS-Komplexität, wenn:

• Du dedizierte DevOps-Ressourcen hast
• Deine Infrastruktur einzigartige Anforderungen hat
• Kostenoptimierung eine kritische Metrik für dein Business ist
• Dein Team sich mit Infrastructure-as-Code und Debugging verteilter Systeme wohlfühlt

Das Fazit

Eine Plattform-Migration ist selten so einfach, wie der „Quick Start"-Guide suggeriert. Die wahren Kosten, Heroku zu verlassen, liegen nicht nur im Migrationsaufwand – sie liegen im fortlaufenden Abwägen zwischen Einfachheit und Kontrolle, zwischen managed Services und eigener Infrastruktur.

Bevor du den Sprung wagst, sei ehrlich mit dir selbst, was du aufgibst. Günstigeres Hosting ist toll, aber nicht, wenn es dein Team ausbremst oder operative Komplexität einführt, die mehr kostet als das, was du sparst.

Am Ende des Tages ist die beste Hosting-Plattform diejenige, die es dir erlaubt, dich auf dein Produkt zu konzentrieren, statt deine Infrastruktur zu verwalten. Manchmal ist das eine vollständig verwaltete Plattform mit einem Premium-Preisschild. Manchmal ist es eine flexible, kosteneffektive Alternative, die mehr Eigeninitiative erfordert.

Kenne dich selbst. Kenne dein Team. Wähle entsprechend.

Was ist deine Migrationsgeschichte? Schreib deine Gedanken in die Kommentare – wir würden gerne hören, wie der große PaaS-Umzug für die Community läuft.