Coolify v4.0.0 ist da: Souveräne Deployment-Plattform statt Heroku und Vercel

Managed Coolify auf eigener Infrastruktur — WZ-IT betreibt Coolify auf Hetzner-Servern in deutschen Rechenzentren: mit Patch-Management, Backups, Monitoring und CVE-Tracking. Sie deployen, wir halten die Plattform sicher und aktuell. Jetzt kostenlosen Termin vereinbaren

Coolify hat Ende April 2026 nach knapp zwei Jahren Beta-Status offiziell die Version 4.0.0 veröffentlicht (Release-Notes auf GitHub). Das Timing ist alles andere als zufällig: Heroku ist im Februar 2026 in den "Sustaining Engineering Mode" gewechselt, Vercel-Rechnungen sprengen in Wachstumsphasen routinemäßig Mittelstands-Budgets, und der Druck Richtung souveräner Infrastruktur wächst — getrieben von NIS2, DSGVO und einer wachsenden Skepsis gegenüber US-Cloud-Plattformen.

Coolify ist nicht das einzige Projekt, das diese Lücke füllen will — aber mit über 52.000 GitHub-Stars, mehr als 280 One-Click-Services und einer Produktiv-Historie bei tausenden Unternehmen ist es der klare Marktführer im Open-Source-Self-Hosted-PaaS-Segment. Was die neue Version technisch und strategisch bedeutet, wann sich der Umstieg lohnt und wo die ehrlichen Grenzen liegen — darum geht es in diesem Beitrag.

Inhaltsverzeichnis

• Coolify v4: das Ende der Beta-Phase
• Was die neue Version konkret bringt
• Der eigentliche Anlass: Heroku im Sustaining-Mode
• Kostenvergleich: Vercel und Heroku gegen Coolify auf Hetzner
• Souveraenitaet und Compliance: DSGVO und NIS2
• Wann Coolify die richtige Wahl ist und wann nicht
• Von Vercel zu Coolify: die Migration in 10 Schritten
• Unser Vorgehen bei WZ-IT
• Weiterfuehrende Guides

Coolify v4: das Ende der Beta-Phase

Coolify ist eine Open-Source-Plattform, die einen Linux-Server in eine Heroku-, Netlify- oder Vercel-ähnliche Deployment-Umgebung verwandelt. Sie übernimmt die Aufgaben, die Entwickler bisher manuell mit Docker, Traefik, Let's Encrypt und Cron-Jobs gelöst haben — und stellt sie hinter eine grafische Oberfläche.

Konkret heißt das: Ein Entwickler verbindet ein Git-Repository, drückt "Deploy", und Coolify übernimmt den Rest. Build via Nixpacks oder eigenem Dockerfile, Reverse Proxy via Traefik, automatische SSL-Zertifikate via Let's Encrypt, Datenbank-Provisioning für PostgreSQL, MySQL, Redis oder MongoDB, Preview-Deployments pro Branch und Backups auf S3-kompatiblen Storage. All das auf Servern, die der Kunde besitzt — nicht in einer Cloud, deren Rechnung jeden Monat überrascht.

Das Projekt wurde von Andras Bacsai gestartet und ist über die letzten zwei Jahre zur am weitesten verbreiteten Self-Hosted-PaaS-Lösung im Open-Source-Bereich gewachsen. Tausende Unternehmen betreiben Coolify bereits seit ein bis zwei Jahren produktiv — formell allerdings die ganze Zeit im Beta-Status. Mit v4.0.0 ändert sich das. Das Release-Note des Maintainers liest sich entsprechend nüchtern: "This does not mean it has no bugs, it has many, but we fix them every day." Das ist keine Bescheidenheit, sondern die ehrlichste Beschreibung eines Reife-Statements, die man sich vorstellen kann.

Genau das ist der Kern der Story: v4.0.0 ist kein technischer Major-Sprung, sondern ein Reife-Signal. Für Entwickler, die Coolify schon nutzen, ändert sich am ersten Tag wenig. Für Enterprise-Kunden dagegen, die das "Beta"-Label bisher als Compliance-Showstopper hatten, fällt eine formale Hürde weg — und das zum strategisch denkbar günstigsten Zeitpunkt.

Was die neue Version konkret bringt

v4.0.0 bündelt die Features, die in der langen Beta-Phase entstanden sind, und erklärt sie offiziell für stabil. Vier Bereiche sind für Unternehmen relevant.

Docker Compose als Single Source of Truth

Das Docker-Compose-Build-Pack unterstützt jetzt vollständig docker-compose.yml als zentrale Definitionsdatei für ein Deployment. Wer seine Applikation ohnehin als Compose-Stack beschreibt, kann diese Datei direkt aus dem Git-Repository ziehen lassen — Coolify baut und betreibt den kompletten Stack daraus. Die offizielle Coolify-Dokumentation zu Docker Compose beschreibt die unterstützten Annotationen im Detail.

Zwei davon lösen klassische Docker-Schmerzpunkte: Mit is_directory: true legt Coolify bei Bind Mounts ein Verzeichnis statt einer Datei an — ein häufiger Stolperstein bei manuellen Setups. Und über die Content-Annotation lassen sich Dateiinhalte mit dynamischen Umgebungsvariablen direkt im Compose-File definieren.

Magic Environment Variables

Seit v4.0.0-beta.411 verfügbar und mit dem stabilen Release offiziell gereift: die "Magic Environment Variables" für Compose-from-Git-Quellen. Coolify generiert automatisch konsistente URLs, FQDNs, Passwörter und Zufalls-Strings — und zwar über Service-Grenzen hinweg. Ein Datenbank-Passwort, das im einen Container erzeugt wird, steht im abhängigen Container unter demselben Namen zur Verfügung, ohne dass es manuell durchgereicht werden muss. Für Multi-Service-Stacks ist das der Unterschied zwischen "funktioniert auf Anhieb" und "drei Stunden Env-Variablen-Debugging".

Multi-Server, Docker Swarm und der v5-Ausblick

Coolify unterstützt seit Längerem Multi-Server-Setups: Ein Coolify-Master verwaltet N Worker-Server über SSH. Für Clustering steht Docker Swarm zur Verfügung — bewusst eingeschränkt, einen nativen Kubernetes-Pfad gibt es nicht.

Spannend ist der Ausblick, den Bacsai direkt im v4.0.0-Release-Note gibt: Das größte Feature von v5 werde "full scalability in the core" — also Cloud-Infrastruktur-Verhalten auf den eigenen Servern. Wichtig für die Investitionssicherheit: v4 wird parallel weiter gepflegt ("doing v5 does not mean we won't continue to support v4"). Wer heute auf v4 setzt, landet nicht in einer Sackgasse.

Postgres 18 und Security-Haertung

Seit v4.0.0-beta.463 bringt Coolify nativen Support für PostgreSQL 18 inklusive pgvector 18 mit — relevant für alle, die Vektor-Suche oder KI-naheliegende Workloads selbst hosten wollen. Dazu kommt eine Reihe von Security-Verbesserungen, die mit v4.0.0 stabil sind: ein Upgrade des Hash-Verfahrens für die E-Mail-Verifizierung, HMAC-Signatur-Prüfung für Webhooks, ein Schutz gegen Datenverlust beim Löschen von Services und Fixes an den S3-Backup-Endpunkten. Ergänzt wird das durch eine API-First-Architektur mit verbessertem REST-API und eine Coolify-CLI, die eine KI-Assistenz für Debugging per natürlicher Sprache integriert.

Wer Coolify produktiv betreibt, sollte den Security-Aspekt ernst nehmen: Die Plattform hatte 2025/2026 mehrere kritische CVEs. Die Details und warum konsequentes Patch-Management Pflicht ist, haben wir in unserer Coolify-CVE-Übersicht 2025/2026 zusammengefasst.

Der eigentliche Anlass: Heroku im Sustaining-Mode

Der technische Inhalt von v4.0.0 erklärt nur die halbe Aufmerksamkeit. Die andere Hälfte kommt aus dem Markt.

Heroku, das den PaaS-Markt vor über einem Jahrzehnt definiert hat, ist im Februar 2026 in den "Sustaining Engineering Mode" gewechselt — ein euphemistischer Begriff für: keine neuen Features mehr, nur noch Bug- und Security-Fixes. Für tausende Unternehmen, die seit Jahren auf Heroku setzen, ist das ein klares strategisches Signal. Die Plattform stirbt nicht über Nacht, aber sie entwickelt sich nicht mehr weiter. Das löst eine Migrationswelle aus.

Parallel sorgt Vercel für virale Kostendiskussionen. Das bekannteste Beispiel ist die Creator-Plattform Cara, die nach einem Wachstumsschub von 650.000 Nutzern über Nacht mit einer Vercel-Rechnung von rund 95.000 US-Dollar konfrontiert war. Das ist ein Extremfall — aber das zugrundeliegende Muster ist Alltag: Bandbreiten-Overages und Function-Invocation-Kosten sind die unsichtbaren Schmerzpunkte, die eine Vercel-Rechnung in Wachstumsphasen unkalkulierbar machen.

Der wirtschaftliche Wendepunkt lässt sich beziffern: Sobald die Vercel- oder Heroku-Rechnung regelmäßig über 50 bis 100 Euro pro Monat liegt, lohnt sich das Durchrechnen der Self-Hosted-Alternative. Bei Rechnungen über 300 Euro pro Monat ist die Antwort fast immer eindeutig — die Frage ist dann nur noch, ob man selbst betreibt oder betreiben lässt.

Kostenvergleich: Vercel und Heroku gegen Coolify auf Hetzner

Die folgende Tabelle legt einen typischen Mittelstands-Workload zugrunde: eine produktive Webapplikation mit etwa 500.000 Visits pro Monat, einer angeschlossenen PostgreSQL-Datenbank, einem Redis-Cache und drei Staging-Umgebungen für Preview-Deployments. Die Vercel- und Heroku-Werte stammen aus öffentlichen Preislisten und realen Erfahrungsberichten; die Coolify-Werte basieren auf Hetzner-Listenpreisen. Alle Angaben sind Größenordnungen, keine Angebote.

Eine herstellerunabhängige Vergleichsrechnung von MassiveGRID kommt für einen vergleichbaren Workload auf rund 601 US-Dollar pro Monat bei Vercel gegenüber etwa 90 US-Dollar für Coolify auf Hetzner — eine Ersparnis von rund 85 Prozent.

Die reine Zahl ist allerdings nur die halbe Wahrheit. Die wichtige Frage hinter den Kosten lautet: Was kostet der eigene Aufwand für Self-Hosting? Wer Coolify rein selbst betreibt, spart bei der Cloud-Rechnung, zahlt aber mit eigener Zeit — regelmäßige Updates, Reaktion auf Sicherheits-CVEs, Monitoring-Setup, Backup-Verifikation, Disaster-Recovery-Tests. Und der berüchtigte "2-Uhr-nachts-Incident", wenn der Server wegen vollgelaufenem Docker-Build-Cache abraucht.

Genau hier ergibt ein Managed Service Sinn: Die Ersparnis gegenüber Vercel bleibt deutlich — typisch 70 bis 80 Prozent statt 85 bis 90 —, aber der operative Aufwand wandert an den Service-Partner.

Souveraenitaet und Compliance: DSGVO und NIS2

Der Kostenvorteil ist das, was Entscheider zuerst überzeugt. Strategisch wichtiger ist oft das, was darunter liegt.

Datenstandort. Coolify auf Hetzner bedeutet Data Residency in Falkenstein, Nürnberg oder Helsinki — nicht in einer US-Cloud. Das ist DSGVO-konform ohne die übliche Konstruktion aus Standardvertragsklauseln und Transfer-Impact-Assessments. Und es entzieht die Daten dem Zugriffsbereich des US-CLOUD-Act. Coolify ist dabei nicht an Hetzner gebunden — die Plattform läuft auf jedem Linux-Server mit SSH-Zugang —, aber die Empfehlung für Hetzner kommt vom Coolify-Projekt selbst, und Coolify ist als vorinstallierte App in der Hetzner Cloud Console verfügbar.

NIS2. Eine self-hosted Plattform ist auditierbarer als eine Black-Box-PaaS. Wer Coolify auf eigener Infrastruktur betreibt, kann Patch-Stände, Zugriffswege und die Lieferkette dokumentieren — genau das, was die NIS2-Pflichten zum Risikomanagement (Art. 21) verlangen. Eine Managed-PaaS kann diese Nachweise oft nur eingeschränkt liefern.

Anti-Lock-in. Coolify speichert alle Konfigurationen direkt auf dem Server des Kunden. Bacsai formuliert es so: "All configurations for your applications/databases/etc are saved to your server. So, if you decide to stop using Coolify, you could still manage your running resources." Es gibt keine Migrationshölle wie beim Verlassen von Heroku oder Vercel — verloren gehen die Automatisierung und der Komfort, nicht die laufenden Workloads.

Wann Coolify die richtige Wahl ist und wann nicht

Coolify ist nicht das einzige Self-Hosted-PaaS, aber das mit Abstand größte. Die folgende Übersicht ordnet die ernstzunehmenden Open-Source-Alternativen ein.

Drei Gründe machen Coolify zum pragmatischen Default, wenn nicht eine sehr spezifische Anforderung dagegenspricht: die Größe der Community (drei- bis vierfach so viele Stars wie die nächsten Self-Hosted-Konkurrenten), das Service-Template-Angebot (über 280 One-Click-Services, mehr als bei jeder anderen Open-Source-Alternative) und die offizielle Hetzner-Integration.

Genauso wichtig für eine ehrliche Einordnung ist, wann Coolify nicht die richtige Wahl ist:

• Multi-Region-Failover: Echtes Failover über mehrere Regionen braucht externe Load Balancer und ist nicht Coolifys Stärke. Wer das zwingend braucht, sollte Managed Kubernetes prüfen.
• Eingebaute Observability fehlt: Web-Analytics, Error-Tracking und Session-Replay bringt Coolify nicht mit. Diese Tools müssen ergänzt werden — als self-hosted Services (Uptime Kuma, Plausible, Sentry) oder als zusätzliche SaaS-Abos.
• Self-Hosting heißt Verantwortung: Updates, Backups, CVE-Monitoring und Disaster-Recovery-Tests gehören ehrlich kommuniziert. Wer das nicht selbst leisten will, braucht einen Managed-Service-Partner.
• Kubernetes-native Patterns: Wer Service Mesh, echtes Auto-Scaling über Dutzende Knoten oder spezifische K8s-Operatoren braucht, ist mit einer Kubernetes-Plattform besser bedient.

Von Vercel zu Coolify: die Migration in 10 Schritten

Diese Checkliste begleitet die Migration einer typischen Next.js- oder Node.js-Webanwendung von Vercel zu Coolify auf Hetzner. Sie ist bewusst pragmatisch gehalten und deckt die Punkte ab, die in der Praxis Zeit kosten.

1. Bestandsaufnahme. Die komplette Vercel-Konfiguration dokumentieren: alle Environment Variables (auch in Preview- und Development-Umgebungen), Custom Domains samt DNS-Settings, aktive Integrationen, Edge Functions, Middleware-Pattern, Cron Jobs und Build-Settings.
2. Vercel-Spezifika identifizieren. Edge Functions, Incremental Static Regeneration und Vercel-spezifische Middleware laufen nicht eins zu eins auf Docker. Diese Punkte vor der Migration bewerten und gegebenenfalls replatformen.
3. Server-Sizing. Für die meisten Mittelstands-Workloads reicht eine Hetzner-CCX-Instanz als Coolify-Worker plus eine kleine separate Instanz für Coolify selbst. Höhere Lasten skalieren vertikal oder über zusätzliche Worker-Server.
4. Coolify-Installation. Bei Hetzner reicht die Auswahl des vorinstallierten Coolify-Images bei der Server-Erstellung. Danach Admin-Account anlegen, MFA aktivieren, erste Server-Verbindung verifizieren.
5. Git-Anbindung einrichten. In Coolify eine dedizierte GitHub-App erstellen und mit dem Ziel-Repository verknüpfen — nicht den persönlichen Token verwenden, das vermeidet Berechtigungskonflikte.
6. Test-Deployment. Vor dem echten Cut ein Staging-Setup aufsetzen: Projekt anlegen, Repository auswählen, Build-Pack wählen (Nixpacks für Standard-Frameworks, Dockerfile für Custom-Setups), Environment Variables übertragen, auf einer Subdomain deployen.
7. Datenbank-Migration planen. Externe Datenbank beibehalten und Coolify nur für die App nutzen — oder die Datenbank ebenfalls als One-Click-Service auf Coolify migrieren. Bei Variante zwei den Transfer per pg_dump/pg_restore zuerst auf Staging testen.
8. DNS vorbereiten. 24 bis 48 Stunden vor dem Cut die DNS-TTL der produktiven Domains auf 300 Sekunden senken. Das verkürzt das spätere Umstellungsfenster erheblich.
9. Production-Cut. Außerhalb der Hauptverkehrszeit den DNS-A-Record umstellen. Coolify erstellt das SSL-Zertifikat automatisch. Alle kritischen User-Flows testen, Logs 30 Minuten beobachten — und das Vercel-Deployment mindestens 48 Stunden parallel laufen lassen, falls ein Rollback nötig wird.
10. Cleanup und Observability. Nach 48 bis 72 Stunden stabilem Betrieb das Vercel-Projekt archivieren. Auf Coolify-Seite die Observability ergänzen, die Vercel mitbrachte (Monitoring, Analytics, Error-Tracking), Backups konfigurieren und eine Patch-Strategie festlegen.

Die meisten Migrationen scheitern nicht an der Technik, sondern an unvollständiger Dokumentation der bestehenden Konfiguration und an Vercel-spezifischem Code, der erst im Migrationsprozess auffällt. Ein realistisches Zeitfenster für eine Standard-Migration ist ein bis drei Arbeitstage plus eine Woche Beobachtungszeit.

Unser Vorgehen bei WZ-IT

Coolify v4.0.0 ist eine ausgezeichnete Plattform — aber Self-Hosting heißt Verantwortung. Wir nehmen Unternehmen genau diesen operativen Teil ab, ohne den Souveränitäts- und Kostenvorteil zu opfern.

1. Bewertung statt Bauchgefühl. Wir rechnen den konkreten Workload durch: Wie hoch ist die aktuelle Vercel- oder Heroku-Rechnung, welche Plattform-Features sind wirklich im Einsatz, und ab welchem Punkt rechnet sich der Umstieg? Liegt die Rechnung unter der Schwelle, sagen wir das auch.

2. Infrastruktur auf Hetzner. Wir richten Coolify auf dedizierten Hetzner-Servern in deutschen Rechenzentren ein — in der vom Projekt empfohlenen Zwei-Server-Struktur: ein Server für das Coolify-Management, einer (oder mehrere) für die Applikationen.

3. Migration als Service. Den Umzug von Vercel oder Heroku machen wir einmal sauber — von der Bestandsaufnahme über das Test-Deployment bis zum Production-Cut mit Rollback-Sicherheit.

4. Managed Operations. Patch-Management, CVE-Tracking, automatische Backups, Monitoring und 24/7-Bereitschaft gehören zum Betrieb. Die Coolify-CVE-Historie zeigt, warum das kein optionales Extra ist.

5. Keine Lock-in-Falle. Weil Coolify alle Konfigurationen auf dem Server des Kunden ablegt, bleibt die Infrastruktur jederzeit übernehmbar. Managed Service heißt bei uns Entlastung, nicht Abhängigkeit.

Ob als Managed Open Source im Komplettpaket oder als gezielte Unterstützung rund um die Coolify-Expertise — die Plattform steht auf europäischer Infrastruktur, der Betrieb liegt in europäischen Händen.

Weiterfuehrende Guides

• Coolify: Next.js-App in 4 Schritten deployen — der praktische Einstieg in die Plattform
• Coolify CVE-Übersicht 2025/2026: Sicherheitsluecken und Update-Pflicht — warum Patch-Management Pflicht ist
• GitHub Actions Preisaenderung 2026: Open-Source-Alternativen — dasselbe Muster bei CI/CD
• Managed Open Source bei WZ-IT — Self-Hosted-Software im Komplettbetrieb
• Coolify-Expertise bei WZ-IT — Beratung, Setup und Betrieb

Vercel-Rechnung im Blick, aber kein Team für Self-Hosting? Wir rechnen Ihren Workload ehrlich durch und übernehmen Migration und Betrieb von Coolify auf souveräner Infrastruktur. Sprechen Sie mit uns über Managed Coolify

Stand: Mai 2026. Versionsangaben und Feature-Stände beziehen sich auf das Coolify-Release v4.0.0 von Ende April 2026. Open-Source-Projekte entwickeln sich schnell — für die jeweils aktuellen Details lohnt der Blick in die offiziellen Release-Notes.