Heroku-Alternative in Europa: von der PaaS zur eigenen Cloud ohne Platform-Team

Ein B2B-Produkt läuft seit Jahren auf Heroku: drei Standard-2X-Dynos (zweimal Web, ein Worker) mit je 1 GB RAM für je 50 $ im Monat, dazu Heroku Postgres in der Standard-Stufe ab 50 $ – zusammen 200 $ im Monat, Stand Oktober 2026. Es funktioniert. Dann liest die Geschäftsführung, dass Heroku keine neuen Funktionen mehr entwickelt, und fragt nach Plan B. Eine Heroku-Alternative ist eine Plattform, die den bequemen Ablauf – Code pushen, App läuft – erhält und dabei Kosten, Standort und Zukunft der Infrastruktur in Ihre Hand legt.

Warum suchen Teams eine Heroku-Alternative?

• Das Ende der kostenlosen Pläne. Seit dem 28. November 2022 gibt es keine kostenlosen Dynos und keine kostenlosen Pläne für Heroku Postgres und Redis mehr.
• Der Preis pro Dyno. Ein Standard-1X mit 0,5 GB RAM kostet 25 $ im Monat, ein Performance-M mit 2,5 GB 250 $ (Stand Oktober 2026). Add-ons wie die Datenbank kommen einzeln dazu; die Rechnung wächst mit jedem Dyno.
• Die Regionen. Die Common Runtime kennt zwei Regionen, „eu“ und „us“. Konkrete Standorte wie Dublin, Frankfurt oder London gibt es nur in Private Spaces, einer eigenen, abgeschotteten Laufzeitumgebung.
• Die Zukunft. Am 6. Februar 2026 hat Heroku den Übergang zu einem „Sustaining Engineering“-Modell angekündigt: Stabilität, Sicherheit, Zuverlässigkeit und Support, aber keine neuen Funktionen; Enterprise-Verträge gibt es für Neukunden nicht mehr. Für bestehende Kunden ändern sich laut Heroku weder Preise noch Betrieb.

Was Heroku gut macht – und was Sie ersetzen müssen

Heroku hat den Maßstab gesetzt: Code pushen, App läuft; die Datenbank kommt als Add-on, die Konfiguration als Config Vars. Für jeden dieser Bausteine braucht der Umzug einen Ersatz:

• Build aus Git: statt Buildpacks meist ein Dockerfile, gebaut im Cluster oder in GitHub Actions.
• Config Vars: werden zu Umgebungsvariablen; Passwörter und Schlüssel gehören in Secrets, die niemand mehr auslesen kann.
• Postgres-Add-on: wird zu einer Managed Database mit privatem Endpunkt, erreichbar nur aus dem Cluster.
• Logs: heroku logs --tail wird zum Log-Viewer über die Pods; wer Logs monatelang aufbewahren muss, braucht einen Log-Dienst.
• Scaling: eine feste Zahl an Replikas oder ein Autoscaler statt der Dyno-Formation.
• Domains und TLS: ein Ingress-Controller mit cert-manager für Let’s-Encrypt-Zertifikate, dazu die DNS-Einträge.

Welche Optionen gibt es?

1. Eine andere PaaS. Der kürzeste Weg: Der Ablauf bleibt fast gleich, und mehrere europäische Anbieter betreiben Rechenzentren in der EU. Sie tauschen damit aber eine PaaS gegen die nächste: Rechenleistung zum Paketpreis, Daten beim Anbieter, Ausstieg wieder per Migration.
2. Managed Kubernetes in Eigenregie. Etwa Scaleway Kapsule im eigenen Konto, Nodes zu Scaleway-Listenpreisen, volle Kontrolle. Dafür bauen und pflegen Sie Build, Ingress, Zertifikate, Datenbankanbindung, Backups und Upgrades selbst – die Arbeit eines Platform-Teams.
3. Managed Kubernetes plus Control Plane. Die Infrastruktur liegt wie bei Option 2 in Ihrem Konto, eine Plattform übernimmt den Heroku-Teil: Build, Deploy, Datenbanken, Domains, Zertifikate und den Betrieb des Clusters. Das ist der Ansatz von Clusterward – Bring Your Own Cloud auf Scaleway in Paris, Amsterdam oder Warschau.

Welche Option passt, entscheiden zwei Fragen: Wem soll die Infrastruktur gehören, und wer hat Zeit, sie zu betreiben? Zwei solche Control Planes vergleicht die Seite Clusterward vs. Qovery.

Wie läuft die Migration von Heroku ab?

1. Bestandsaufnahme. Prozesstypen aus dem Procfile, Dynos, Add-ons, Config Vars, Domains – jede Zeile bekommt ihren Ersatz aus der Liste oben.
2. Container bauen. Dockerfile schreiben und lokal starten. Die App lauscht auf einem festen Port; liest sie ihn aus PORT, setzen Sie die Variable selbst.
3. Zielumgebung anlegen. Cluster, Managed Database mit privatem Endpunkt, Service mit Port, Ressourcen und Replikas.
4. Konfiguration übernehmen. heroku config listet die Config Vars. Passwörter und Schlüssel als Secrets anlegen, den Rest als Variablen; die neue DATABASE_URL zeigt auf die neue Datenbank.
5. Probelauf. Deployen, die Daten einmal kopieren, alles unter einer Test-Domain prüfen – Login, Hintergrundjobs, Uploads, E-Mails.
6. Umzug. Die TTL der DNS-Einträge am Vortag auf wenige Minuten senken, Schreibzugriffe auf Heroku stoppen, Daten final kopieren, DNS umstellen. Die Heroku-App erst löschen, wenn dort tagelang nichts mehr ankommt.

Typische Stolperfallen beim Umzug

• Die Datenbank-URL. Auf Heroku steht DATABASE_URL automatisch in den Config Vars, und Heroku kann sie bei einem Failover oder einer Rotation der Zugangsdaten ändern. Nach dem Umzug tragen Sie die Verbindungsdaten einmal selbst ein.
• TLS zur Quelle. Heroku Postgres verlangt sslmode=require; Datenbanken auf Private- und Shield-Plänen sind von außen gar nicht erreichbar, dort exportieren Sie aus dem Space heraus.
• Was das Buildpack still erledigt hat. Systempakete, Asset-Build, die passende Sprachversion – all das muss jetzt im Dockerfile stehen.

Was Clusterward ersetzt – und was nicht

Clusterward übernimmt den Heroku-Teil auf Scaleway Kapsule, in Ihrem eigenen Scaleway-Projekt:

• Build aus Git, im Cluster ohne Docker-Daemon oder über GitHub Actions; ein kurzer Workflow mit API-Token deployt bei jedem Push auf main (Deployments).
• Umgebungsvariablen und Secrets, auf Wunsch im Scaleway Secret Manager. Nach einer Änderung zeigt die Service-Seite „restart pending“, bis Sie neu starten.
• Managed PostgreSQL oder MySQL nur mit privatem Endpunkt (Managed Datenbanken). Die Datenbank für einen Service entsteht in einem Schritt; die DATABASE_URL kopieren Sie selbst in die Variablen. Der Import holt die Daten direkt über eine Postgres-URL, auch die von Heroku, und stoppt die App, solange er läuft.
• Logs aller Pods zusammengeführt, bis zu 10.000 Zeilen, auch vom abgestürzten Lauf; Uptime-Checks, Benachrichtigungen und Rollback auf eine frühere Version.
• Domains mit Let’s-Encrypt- oder Wildcard-Zertifikaten, DNS-Einträge automatisch in registrierten Cloudflare- oder Scaleway-Zonen, zeitgesteuerte Jobs als CronJob.

Was fehlt: Vorschau-Umgebungen pro Pull Request – wer heute mit Review Apps arbeitet, verliert sie beim Wechsel. Einen Add-on-Marktplatz gibt es nicht; Redis, Suche oder E-Mail-Versand buchen Sie selbst dazu. Logs werden nicht über die Lebensdauer eines Pods hinaus aufbewahrt, und der Autoscaler skaliert nur nach CPU.

Fazit

Eine Heroku-Alternative zu finden ist leicht; die richtige hängt daran, wem die Infrastruktur danach gehören soll. Eine andere PaaS ist der kürzeste Weg, Managed Kubernetes der unabhängigste – und mit einer Control Plane darüber wird daraus kein Projekt für ein Platform-Team. Wer die Bausteine vorher auflistet, zieht in Etappen um statt an einem Wochenende.

Sie planen den Umzug von Heroku? Schicken Sie uns Ihre Liste aus Dynos und Add-ons. Wir sagen Ihnen, was davon in Clusterward eins zu eins geht und was nicht. Frage stellen →

Quellen und weiterführende Links

• Heroku-Blog: An Update on Heroku (englisch)
• Heroku Dev Center: Ende der kostenlosen Pläne (englisch)
• Heroku: Preise (englisch)
• Heroku Dev Center: Regionen (englisch)
• Heroku Dev Center: Verbindung zu Heroku Postgres (englisch)