Heroku zu Coolify oder Self-Hosting migrieren
Timo Wevelsiep•Aktualisiert: 30.08.2026Hinweis zum Inhalt: Versionen, Befehle und Preise können sich ändern. Bitte prüfen Sie kritische Schritte vor dem produktiven Einsatz eigenständig. Dieser Leitfaden ersetzt keine individuelle Beratung.
Sie möchten Heroku ablösen und Deployment sowie Betrieb kontrollierbar weiterführen? WZ-IT übernimmt die Heroku-Migration ab 1.990 Euro netto bis zur getesteten Zielumgebung und auf Wunsch den anschließenden Betrieb.
Eine Migration von Heroku zu Coolify oder Self-Hosting übersetzt ein eingespieltes PaaS-Modell in explizite Komponenten. Dynos, Procfile, Buildpacks, Config Vars, Add-ons, Pipelines und Heroku Postgres müssen im Ziel weiter funktionieren oder bewusst ersetzt werden.
Heroku-Anwendung und Pipeline inventarisieren
Erfasst werden insbesondere:
- Apps und Zuordnung zu Heroku Pipelines
- Staging-, Review- und Production-Umgebungen
- Dyno-Typen, Anzahl und Ressourcen
- Prozessgruppen aus dem Procfile
- Buildpacks, Runtime-Versionen und Systemabhängigkeiten
- Config Vars und Secret-Verwendung
- Add-ons und deren tatsächliche Funktion
- Heroku Postgres, Redis, Storage und externe Datenwege
- Scheduler, Release Phase und One-off Dynos
- Domains, TLS, E-Mail, Webhooks und OAuth-Callbacks
- Logs, Metriken und Alarmierung
Die Add-on-Liste allein reicht nicht. Für jeden Dienst muss bekannt sein, welche Daten er hält, wie die Anwendung ihn anspricht und welches Export- oder Ersatzverfahren verfügbar ist.
Dynos und Procfile im Ziel abbilden
| Heroku-Ebene | Mögliche Zielabbildung |
|---|---|
| web Dyno | Anwendung hinter Reverse Proxy und TLS |
| worker Dyno | separater Worker-Service ohne öffentlichen Endpoint |
| clock/Scheduler | geplanter Plattformjob oder System-Timer |
| release Phase | kontrollierter Migrations- oder Deployment-Schritt |
| one-off Dyno | administrativer Job oder temporärer Task |
| Config Vars | geschützte Variablen und Secrets je Umgebung |
| Pipeline | getrennte Staging- und Produktionsprojekte |
Ein Procfile beschreibt Startkommandos, aber nicht das vollständige Betriebsmodell. Health Checks, Ressourcen, Restart, Parallelität, Logging und Skalierung werden im Ziel zusätzlich festgelegt.
Buildpacks durch reproduzierbare Builds ersetzen
Buildpacks erkennen Sprache und Abhängigkeiten teilweise automatisch. Beim Exit wird der Build explizit und reproduzierbar gemacht. Je nach Anwendung entsteht ein Dockerfile oder eine nachvollziehbare Build-Konfiguration der Zielplattform.
Zu prüfen sind:
- Runtime- und Paketversionen
- Lockfiles und private Registries
- Betriebssystempakete und native Bibliotheken
- Build- und Release-Skripte
- statische Assets und Compile-Schritte
- Startkommando und erwartete Ports
- Verhalten bei mehreren Instanzen
Der Build wird zuerst unabhängig von Heroku erzeugt und in einer isolierten Zielumgebung gestartet.
Add-ons funktional ersetzen
Heroku Add-ons können Datenbanken, Cache, Queues, E-Mail, Monitoring, Logging, Search oder Object Storage bereitstellen. Ein Wechsel ersetzt nicht den Produktnamen, sondern die benötigte Funktion und den Datenweg.
Für jedes Add-on werden dokumentiert:
- Daten und Konfiguration
- Export- und Importweg
- Zielprodukt oder weiterhin externer Dienst
- neue Verbindungsdaten und Secret-Rotation
- Abnahme und Rückfall
- spätere Kündigung oder Aufbewahrung
Heroku Postgres migrieren
Heroku dokumentiert Export- und Importwege für Postgres. Für ein planbares Verfahren werden Datenbankversion, Größe, Extensions, Rollen, Verbindungen, Pooling, Schreiblast und zulässige Ausfallzeit aufgenommen.
Nach dem Restore werden nicht nur Tabellenzahlen geprüft. Sequenzen, Constraints, Funktionen, Trigger, Extensions, Zeitzonen und zentrale fachliche Abfragen gehören zur Abnahme. Die Anwendung wird zunächst unter Staging mit der neuen Datenbank getestet.
Staging, Review Apps und Git-Deployment
Git-basierte Deployments bleiben möglich. Heroku Pipelines und Review Apps werden jedoch nicht automatisch eins zu eins reproduziert. Die Zielstrecke kann feste Staging- und Produktionsumgebungen sowie optional kurzlebige Preview-Umgebungen umfassen.
Dabei werden Branches, Secrets, Datenzugriff, Domain, Freigabe, Health Check und Rollback getrennt festgelegt. Preview-Umgebungen dürfen nicht unbeabsichtigt produktive Daten verändern.
Cutover und anschließender Betrieb
Vor der Umschaltung werden Webprozesse, Worker, Scheduler, Daten, E-Mail, Webhooks, Neustart, Logs, Monitoring, Backup und Restore getestet. Der Cutover koordiniert laufende Jobs, Schreibgrenze, finalen Datenabgleich, Domainwechsel und Smoke Tests. Die Quelle bleibt bis zum Ende des vereinbarten Rückfallfensters verfügbar, sofern Datenmodell und Vertrag das zulassen.
Bei mehreren Anwendungen oder unbekannten Add-ons kann der PaaS Exit Review den sinnvolleren ersten Schritt bilden.
Quellen
Lieber betreiben lassen?
Sie möchten PaaS & Cloud Exit nicht selbst betreiben? WZ-IT übernimmt Einrichtung, Betrieb und Wartung - datenschutzorientiert aus Deutschland.
Anfrage
PaaS-Migration einordnen
Beschreiben Sie Quelle, Anwendung und gewünschtes Ziel. Wir prüfen den Migrationsweg für Runtime, Daten, Delivery und anschließenden Betrieb.
Häufig gestellte Fragen
Antworten auf die wichtigsten Fragen
Coolify kann Git- oder Container-Deployments, Domains, Variablen und mehrere Prozesse abbilden. Heroku Add-ons und verwaltete Plattformfunktionen müssen jedoch einzeln durch passende Daten-, Messaging-, E-Mail-, Storage- oder Beobachtungsdienste ersetzt werden.
Das Procfile zeigt Prozessgruppen wie web und worker und ist ein wichtiger Inventarbaustein. Die Prozesse werden im Ziel als getrennte Services oder Startkommandos mit eigenem Health-, Skalierungs- und Restart-Verhalten bereitgestellt.
Ja. Abhängig von Größe, Schreibaktivität und Ausfallfenster kommen Heroku-Export, PostgreSQL Dump und Restore oder ein Replikationsverfahren infrage. Rollen, Extensions, Sequenzen, Verbindungen und Anwendungsfunktionen werden anschließend geprüft.
Die Heroku-Migration beginnt bei 1.990 Euro netto. Anwendungen, Dynos, Buildpacks, Add-ons, Daten, notwendige Codeänderungen, Zielarchitektur und Cutover bestimmen das konkrete Angebot.
