Wenn Sie die verwaltete PaaS bereits verlassen haben, ist Ihr VPS bereitgestellt, der SSH-Schlüssel hinzugefügt und Ihr Terminal-Cursor blinkt in der Installationszeile. Bleibt nur die Frage: Führen Sie curl ... | bash für Coolify oder für Dokploy aus?
Beide Tools installieren sich mit einem Befehl. Beide geben Ihnen Git-Push-Deployments, automatisches SSL, eine Web-UI und einen Reverse-Proxy auf Docker. Die interessanten Unterschiede sind diejenigen, die in der Produktion zutage treten: wie jedes ein Standard- docker-compose.ymlhandhabt, was während eines Deployments passiert und wie jedes Projekt auf die Nachrichten reagiert hat, die diesen Vergleich 2026 neu gestaltet haben. Zwei Nachrichten tragen hier den Großteil des Gewichts: die Coolify-CVE-Offenlegungen vom Januar 2026 und der Dokploy-Lizenzumstrukturierung desselben Monats.
Dieser Beitrag ordnet jedes Tool einem bestimmten Anwendungsfall zu, anstatt einen Sieger zu küren. Am Ende wissen Sie hoffentlich, welches zu Ihrem Workflow passt.
Kurzfassung
- Coolify ist älter mit dem größeren Ökosystem (~55k GitHub-Sterne, 300+ One-Click-Service-Vorlagen), schwerer im Leerlauf, durchgehend Apache 2.0, ohne kostenpflichtige Stufe auf der selbstgehosteten Seite.
- Dokploy ist jünger (~34k Sterne), leichter im Leerlauf, Apache-2.0-Kern plus eine separate Source Available License, die künftige kostenpflichtige Funktionen (SSO, RBAC, Audit-Logs, White-Labeling) absteckt.
- Coolify kann heute keine Zero-Downtime-Deployments über Docker Compose durchführen; nur über Dockerfile, Nixpacks oder Single-Image-Deployments. Dokploy liefert Docker Swarm als erstklassigen Modus; Coolifys Swarm ist als experimentell gekennzeichnet.
- Die Coolify-CVEs vom Januar 2026 sind in v4.0.0 (April 27, 2026) gepatcht. Aktualisieren Sie Coolify und stellen Sie das Dashboard nicht öffentlich zur Verfügung.
Wenn keines der beiden Tools die richtige Antwort ist
Sowohl Coolify als auch Dokploy haben für manche Setups die falsche Form. Drei Alternativen, die man kennen sollte, kurz:
- Kamal (von 37signals): für Teams mit einer oder zwei Apps, die keine UI wollen; einfach
kamal deployvon Ihrem Laptop. Deutlich einfacher als Coolify oder Dokploy und die richtige Wahl, wenn Sie kein Dashboard wollen. - Dokku: der Klassiker, Git-Push, Single-Server-Modell. Älter, kleinerer Umfang, sehr stabil. Das „Heroku auf einem VPS"-Original.
- GitHub Actions + Docker Compose auf einem nackten VPS: der kleinstmögliche Stack. Keine Orchestrierungs-UI, aber auch kein Orchestrierungs-Overhead. Gut für eine einzelne App, bei der der Deploy-Ablauf
docker compose pull && docker compose up -daus der CI ausgelöst wird.
Wenn Ihre Form eine App auf einem Server ist, sind sowohl Coolify als auch Dokploy wahrscheinlich überdimensioniert; probieren Sie zuerst eines der obigen. Wenn Sie mehrere Apps, mehrere Datenbanken oder ein Team mit nicht-technischen Mitgliedern haben, die eine UI zum Bedienen brauchen, ist die Coolify-vs.-Dokploy-Wahl die richtige. Für einen breiteren Überblick über die Optionen in dieser Kategorie siehe unsere Übersicht über self-hosted Cloud-Plattformen mit Web-UI.
Coolify und Dokploy auf einen Blick
Coolify v4.0.0 stable erschien am April 27, 2026, nach einem langen Beta-Zyklus. Dokploy ist auf v0.29.4 Stand May 11, 2026. Beide sind Open-Source-PaaS-Projekte zum Selbsthosten im Heroku/Render/Vercel-Alternativen-Bereich, beide umhüllen Docker mit einer UI, einem HTTPS-by-default Reverse-Proxy (Traefik) und Git-basierten Deployments.
| Funktion | Coolify | Dokploy |
|---|---|---|
| Neuestes stabiles Release | v4.0.0 (April 27, 2026) | v0.29.4 (May 11, 2026) |
| Lizenz | Apache 2.0 | Apache-2.0-Kern + Source Available für kostenpflichtige Funktionen |
| Tech-Stack | PHP / Laravel | TypeScript / Node.js |
| GitHub-Sterne | ~55.000 | ~34.000 |
| Mindest-RAM (offiziell) | 2 GB | 2 GB |
| Mindest-CPU (offiziell) | 2 Kerne | nicht angegeben |
| Leerlauf-RAM (von der Community gemeldet) | 500 MB – 1.2 GB | 300 – 400 MB |
| Docker Compose Zero-Downtime | Nicht unterstützt (nur Dockerfile/Nixpacks) | Standard-Compose-Handhabung |
| Multi-Server-Clustering | Docker Swarm (experimentell) | Docker Swarm (nativ) |
| ARM64-Unterstützung | Ja (inkl. Raspberry Pi OS) | In den Docs nicht beworben |
| Build-Systeme | Nixpacks, Dockerfile, Docker-Image | Nixpacks, Dockerfile, Docker-Image, Heroku Buildpacks, Paketo, Railpack |
| Reverse Proxy | Traefik | Traefik |
| Umfang des selbstgehosteten Monitorings | Eingebaute Metriken + Log-Viewer | Grundlegende Ressourcenmetriken + KI-gestützte Log-/Build-Fehleranalyse (v0.29.0+) |
Unsere Einschätzung: Wählen Sie Dokploy, wenn Sie niedrigeren Leerlauf-Overhead, native Multi-Server-Unterstützung und Standard-Docker-Compose-Handhabung ohne plattformspezifisches Zurechtbiegen wollen. Wählen Sie Coolify, wenn Sie die größere One-Click-App-Bibliothek, ARM64-/Raspberry-Pi-Unterstützung oder reines Apache 2.0 ohne künftige kostenpflichtige Stufe im Hintergrund wollen.
Ressourcenverbrauch und VPS-Dimensionierung
Eine selbstgehostete PaaS kann Ihnen die Kosten für Heroku sparen. Wenn die Orchestrierungsschicht im Leerlauf 1,5 GB Ihres 2-GB-VPS verschlingt, bleibt Ihnen nichts mehr, worauf Sie deployen können. Die erste praktische Frage auf einem kleinen Server lautet also: Wie viel kostet Sie jedes Tool, bevor Sie überhaupt eine einzige App deployt haben?
Coolifys Leerlauf-RAM-Verbrauch hängt davon ab, welches Monitoring aktiviert ist, mit einer Basis-CPU-Last von 5–7 %, die ansteigt, wenn der Metrik-Scrape läuft. Coolifys eigene Dokumentation verwendet einen repräsentativen Produktions-Workload von 8 GB RAM, 4 Kernen und 150 GB Speicher, auf dem 3 Node.js-Apps, 4 statische Sites und ein paar Datenbanken laufen. Das ist eine vernünftige Dimensionierungsreferenz, wenn Ihr Stack ähnlich aussieht.
Dokploy hingegen läuft viel leichter, deutlich unter 2 % CPU, wenn nichts deployt wird.
A LogRocket-Produktionsbericht der beide Tools nebeneinander betrieb, kam zur gleichen grundsätzlichen Schlussfolgerung: ein docker stop && docker start auf einer Dokploy-App löst keinen vollständigen Rebuild aus, während dieselbe Operation auf Coolify es tut. Allein das verschiebt die Dauerkosten zugunsten von Dokploy, besonders auf kleineren VPS-Plänen, wo Rebuild-Stürme Ihr CPU-Budget auffressen.
Für die Dimensionierung empfehle ich folgendes VPS-Setup:
- Coolify, leichter Workload: 2 vCPU / 4 GB RAM / 120 GB NVMe is the practical starting point for Coolify plus a couple of small apps.
- Coolify, Produktions-Referenz-Workload: 4 vCPU / 8 GB RAM / 160 GB NVMe to match Coolify's own documented 3 Node.js + 4 static sites + databases example.
- Dokploy, leichter Workload: 1 vCPU / 2 GB RAM / 60 GB NVMe is comfortable for a single small app.
- Dokploy, Produktions-Spielraum: 2 vCPU / 4 GB RAM / 120 GB NVMe gives you room for a small production stack.
Profi-Tipp: Coolifys Leerlauf-RAM skaliert mit der Monitoring-Konfiguration. Wenn der Speicher knapp ist, reduzieren Sie das Metrik-Scrape-Intervall (oder deaktivieren Sie das eingebaute Monitoring ganz, wenn Sie bereits Prometheus/Grafana woanders betreiben), bevor Sie einen größeren Server bereitstellen.
Deployment-Realität: Docker Compose, Dockerfile und Zero-Downtime
Die meisten Teams kommen mit einer bestehenden docker-compose.yml und einer Erwartung zu einem dieser Tools: Datei einfügen, auf Deploy klicken, App hochfahren sehen. Wie jede Plattform Standard-Compose handhabt und was während des nächsten Deployments mit laufenden Anfragen passiert, ist der Punkt, an dem der praktische Unterschied zutage tritt.
Coolify unterstützt Docker Compose, Dockerfile, Nixpacks (automatische Erkennung aus Projektdateien) und direkte Docker-Image-Deployments. Es gibt jedoch einen Haken, der ausdrücklich erwähnt werden sollte: Zero-Downtime-Deployments (Rolling Updates, Blue/Green) funktionieren in Coolify nur über Dockerfile, Nixpacks oder Single-Image-Deployments. Sie funktionieren nicht über Docker Compose. Ein Coolify-Maintainer bestätigte in einer GitHub-Diskussion dass „bei Compose-basierten Deployments alle Container gestoppt werden, bevor die neuen gestartet werden, es gibt derzeit kein Rolling Update für Compose-basierte Deployments." Rolling-Unterstützung für Compose steht auf der Roadmap für v5; v4 wird es nicht bekommen. Die vom Maintainer vorgeschlagene Umgehung besteht darin, einen Compose-Stack in einzelne Coolify-Services aufzuteilen, was eine nicht-triviale Migration ist, wenn Ihre Compose-Datei echte Beziehungen zwischen Services ausdrückt.
Die für den Nutzer spürbare Folge zeigt sich in einem Hacker-News-Thread über Coolify, in dem ein Betreiber es unverblümt formulierte: „jede ausstehende Anfrage wird beim Aktualisieren einer App einfach abgebrochen." Das trifft heute auf Compose-Deployments zu.
Coolifys Compose-Schicht fügt außerdem das hinzu, was das Projekt „magische Variablen" nennt. Das bedeutet automatische Injektion von Hilfs-Images, Netzwerk-Umschreibungen und Umgebungs-Overrides. Die Absicht ist mehr Effizienz; der Nebeneffekt ist, dass ein docker-compose.yml der auf Ihrem Laptop sauber läuft, manchmal angepasst werden muss, um auf Coolify sauber zu laufen. Derselbe Hacker-News-Thread bringt einen repräsentativen Fall zur Sprache: „8 Variablen in docker-compose hinzugefügt, nur 7 werden erkannt." Wenn Ihr Compose-Stack klein und Standard ist, treffen Sie vielleicht nicht darauf. Wenn er groß oder ungewöhnlich ist, werden Sie es.
Dokploys Haltung ist anders. LogRockets praxisorientierter Bericht stellte fest, dass Dokploy „eine bestehende docker-compose.yml mit wenig bis keiner Anpassung deployen kann" und nah am nativen, label-basierten Routing-Modell von Docker bleibt. Derselbe Bericht merkt an, dass Container-Stopp/-Start in Dokploy keinen vollständigen Rebuild auslöst, während dieselbe Aktion auf Coolify es tut. Das ist eher ein richtungsweisendes Signal zum Laufzeitverhalten als eine formelle „Zero-Downtime-Garantie" aus den Dokploy-Docs, aber es deckt sich mit dem, was Selbsthoster auf kleineren VPS-Instanzen berichten.
Dokploy unterstützt zusätzlich zu Nixpacks und Dockerfile auch Heroku Buildpacks, Paketo Buildpacks und Railpack. Für Teams, die von Heroku mit heroku.yml oder buildpack-basierten Workflows kommen, ist das der Weg des geringsten Widerstands.
Wichtigste Erkenntnis des Abschnitts: Wenn Ihre bestehenden Services ein echter Docker-Compose-Stack sind, wird Coolify Sie dazu zwingen, entweder Ihre Deployment-Strategie umzustrukturieren oder bei jedem Push kurze Ausfallzeiten in Kauf zu nehmen. Dokploy wird das nicht.
Sicherheit: Die Coolify-CVE-Offenlegungen vom Januar 2026
Ich lese die größere Geschichte so: Coolify ist heute sicher zu betreiben, wenn Sie es aktuell halten und das Dashboard nicht dem öffentlichen Internet aussetzen. Die Offenlegung disqualifiziert das Projekt nicht. Verantwortungsvolle Offenlegung wurde befolgt und die Patches gingen raus. Was sie offenbart, ist, dass die Angriffsfläche für einen Nutzer mit niedrigen Rechten und Authentifizierung größer war, als sie hätte sein sollen. Das ist eine Design-Lektion für das Projekt und eine betriebliche Lektion für den Betreiber: Verschärfen Sie das Expositionsmodell jetzt.
Profi-Tipp: Behandeln Sie Ihr Coolify-Dashboard auch nach dem Patchen wie SSH. Binden Sie es an ein privates Netzwerk, stellen Sie es hinter ein VPN oder setzen Sie es hinter Tailscale. Legen Sie Port 8000 nicht ins öffentliche Internet offen, nur weil das Installationsskript es einfach macht.
Dokploy ist von dieser Art Problem ebenfalls nicht ausgenommen. Die v0.29.3-Release-Notes bestätigen eine in Dokploy identifizierte Sicherheitslücke und liefern ein Sicherheits-Patch-Skript, das Sie zusammen mit dem Upgrade ausführen sollen. Kleinere Fläche, kürzere Projektgeschichte, aber dieselbe betriebliche Disziplin gilt: Aktualisieren Sie am Tag, an dem die Patches erscheinen, und lassen Sie das Dashboard nicht im öffentlichen Internet.
Wichtigste Erkenntnis des Abschnitts: Die CVE-Geschichte ist eine gelbe Flagge für Coolifys betriebliche Praxis, keine rote Flagge gegen das Projekt, aber sie erhöht die Anforderungen an die Update-Disziplin und daran, wie Sie das Dashboard offenlegen.
Lizenzierung: Was kostenlos ist, was nicht
Dokploys Lizenz wurde am January 21, 2026 umstrukturiert. Hier ist, was sich geändert hat und was es für Selbsthoster bedeutet.
Dokploy ist jetzt standardmäßiges Apache 2.0 für den Kern, was das frühere nicht-standardmäßige, angepasste Apache 2.0 ersetzt, das Nutzer darüber verwirrte, was Open Source war und was nicht. Eine separate Dokploy Source Available License regelt nun Code in proprietary/ Verzeichnissen: sichtbarer Quellcode, kostenpflichtig für den Produktionseinsatz. Die Funktionen, die laut Dokploy hinter dieser Lizenz liegen werden:
- Single Sign-On (SSO/SAML) und erweiterte Zugriffskontrollen
- Eigenes Branding und White-Labeling
- Hochverfügbarkeit, Auto-Scaling und Disaster Recovery
- Erweitertes Monitoring, Integrationen und Compliance-Funktionen
Das Projekt hat sich ausdrücklich verpflichtet, niemals eine bestehende Open-Source-Funktion in die kostenpflichtige Stufe zu verschieben; künftige kostenpflichtige Funktionalität richtet sich an Organisationen, die Enterprise-Verbindungsstücke brauchen. 2FA liegt heute bereits hinter der Startup-Stufe auf Dokploys Preisseite.
Coolifys Situation ist unkompliziert. Das Projekt ist Apache 2.0 auf GitHub; jede Funktion in der selbstgehosteten Version ist kostenlos. Es gibt ein Coolify-Cloud-Angebot für Teams, die wollen, dass der Maintainer es hostet, aber die selbstgehostete Version ist ein vollständiges Produkt ohne Feature-Gates und ohne Upgrade-Pfad zu einer kostenpflichtigen Stufe, die Sie heute nicht haben.
Meine Einschätzung: Für Einzelentwickler und kleine Teams, die auf ihrem eigenen VPS selbsthosten, ist Dokploy faktisch kostenlos und wird es bleiben. Für eine Organisation, die irgendwann SSO, feingranulares RBAC, Audit-Logs oder White-Labeling braucht, wird Dokploy Sie schließlich in Richtung einer kostenpflichtigen Stufe drängen. Coolify wird das nicht, weil Coolify diese Stufe nicht auf der Roadmap hat.
Eine quellenübergreifende Klarstellung, die der Erwähnung wert ist: Dokploys selbstgehosteter Build enthält grundlegende Ressourcenmetriken (CPU, Speicher, Speicherplatz, Netzwerk), und v0.29.0 fügte KI-gestützte Log- und Build-Fehleranalyse hinzu. Dokploys Monitoring-System ist für die fortgeschritteneren Monitoring-Funktionen nur in der Cloud. Das Monitoring läuft jedoch bei einer selbstgehosteten Installation weiterhin lokal für grundlegende Ressourcenmetriken vor dem Container.
Multi-Server und Clustering: Realität vs. Marketing
Früher oder später reicht ein einzelner VPS nicht aus, und beide Projekte bewerben Multi-Server-Unterstützung prominent auf ihren Landingpages. Die Realität vor Ort ist nicht dieselbe.
Coolifys offizielle Skalierbarkeits-Docs sind direkt darin: Docker-Swarm-Unterstützung ist als experimentell gekennzeichnet. Das Standard-Multi-Server-Muster verwendet validierte Remote-Server, die über SSH verbunden sind, mit einer gemeinsamen Docker-Registry und Traefik-Instanzen pro Server. Der Swarm-Modus erfordert mindestens drei Server in derselben Architektur (alle ARM oder alle AMD64). Kubernetes? „Nur geplant, aber noch nicht auf der Roadmap, also kein ETA." Wenn Sie Coolifys eigene Seite dazu lesen, lautet die Kurzfassung: Multi-Server funktioniert, Swarm ist eine Beta und Kubernetes ist eine Vision.
Dokploy liefert Docker Swarm als erstklassigen Modus ohne experimentelles Flag. Traefik übernimmt das Routing sowohl in Single-Server- als auch in Swarm-Setups. Das v0.29.0-Release fügte Non-Root-Multi-Server-Unterstützung hinzu, was eine echte Lücke schließt (kein root-only SSH mehr zum Hinzufügen von Remote-Nodes).
Wenn Multi-Node-Clustering etwas ist, das Sie in den nächsten sechs Monaten brauchen werden, nicht „irgendwann auf einer Folie", ist Dokploy heute die risikoärmere Wahl.
Wichtigste Erkenntnis des Abschnitts: Wenn Clustering auf Ihrer kurzfristigen Roadmap steht, kippt der Swarm-Unterschied die Empfehlung in Richtung Dokploy, unabhängig von den anderen Achsen.
Build-Systeme und Sprachunterstützung
Teams, die von Heroku kommen, interessieren sich am meisten dafür, welche Buildpack-Ökosysteme jedes Tool unterstützt, denn das entscheidet, wie viel Umschreiben Ihr Projekt vor seinem ersten Deployment braucht.
Coolifys Build-Pfad ist Nixpacks (Standard, automatisch aus Ihren Projektdateien erkannt), Dockerfile oder ein vorgefertigtes Docker-Image. Nixpacks ist solide für die gängigen Fälle (Node, Python, PHP, Go, Rust), aber die automatische Erkennung hat raue Kanten. Für Ihren Stack zu überprüfen: ein Nixpacks-Problem vom Januar 2026, das Laravel-Projekte mit beidem betraf composer.json und package.json erzeugte doppelte Nginx-Location-Blöcke, was eine Klasse von Deployments brach, bis es upstream behoben wurde.
Dokploy unterstützt Nixpacks, Dockerfile und Docker-Image und fügt obendrauf Heroku Buildpacks, Paketo Buildpacks und Railpack hinzu. Wenn Ihr Projekt bereits sauber mit heroku.yml oder einem Buildpack baut, lässt Dokploy Sie diesen Workflow beibehalten. Coolify wird Sie zum Konvertieren auffordern.
Oberflächlich sehen beide Tools gleich aus: Git-Push-Deployments von GitHub, GitLab, Bitbucket, automatisches Let's Encrypt SSL, eine Web-UI für Umgebungsvariablen und Datenbankverwaltung. Die Build-System-Breite ist einer der wenigen Punkte, an denen Dokploy deutlich weiter reicht.
One-Click-App-Kataloge
Für nicht-technische Betreiber, die bekannte Open-Source-Dienste deployen wollen (n8n, Plausible, Supabase, Ghost, Listmonk, die übliche selbstgehostete Belegschaft), ist die Größe der One-Click-Vorlagenbibliothek ein echtes Unterscheidungsmerkmal. Für manche Nutzer ist das wichtiger als andere Bereiche wie Leistung oder Leichtgewichtigkeit.
Coolify bietet 300+ One-Click-Services über rund 40 Kategorien hinweg: KI, Analytik, Automatisierung, Datenbanken, Sicherheit, Speicher und der Rest. Es ist mit großem Abstand die größere Bibliothek und die praktische Antwort für Nicht-Entwickler, die einen Dienst deployen wollen, ohne eine Compose-Datei zu schreiben.
Dokploys Vorlagenbibliothek ist kleiner. Die aktuellen Dokploy-Docs veröffentlichen keine saubere Zahl, daher gebe ich Ihnen keine.
Die praktische Antwort: Wenn Ihr Workflow „n8n, Supabase und Plausible in je zwei Klicks deployen" ist, gewinnt Coolify diese Achse klar. Wenn Sie Ihre eigenen Apps schreiben und sie einfach nur deployen wollen, spielt die Kataloggröße keine Rolle und die anderen Achsen schon.
Wie man wählt: Empfehlungen nach Anwendungsfall
Es gibt hier keinen einzelnen Sieger. Es gibt Übereinstimmungen zwischen einem Tool und einer Deployment-Form:
- Nicht-technisches Team, das eine Dienste-Bibliothek will: Coolify. Der Katalog mit 300+ Vorlagen ist ein bedeutender Vorsprung.
- Docker-nativer Entwickler, der leichtgewichtig + Standard-Compose-Handhabung will: Dokploy.
- ARM64-Hardware (Raspberry Pi, ARM-basierter VPS): Coolify. Dokploy bewirbt in den aktuellen Docs keine ARM64-Unterstützung; wenn Sie auf ARM sind, wählen Sie standardmäßig Coolify, bis Sie das Gegenteil bestätigt haben.
- Multi-Node-Clustering, das Sie dieses Quartal nutzen werden: Dokploy. Natives Swarm vs. experimentelles Swarm ist der ausschlaggebende Faktor.
- Reines Apache 2.0, keine mögliche künftige kostenpflichtige Stufe: Coolify.
- Migration von Heroku und Wunsch, Heroku Buildpacks zu behalten: Dokploy.
- Besorgt über die CVEs vom Januar 2026: ein aktualisiertes Coolify (v4.0.0+) ist in Ordnung. Die eigentliche Frage ist Ihr Expositionsmodell. Wenn Sie das Dashboard nicht an ein privates Netzwerk oder VPN binden können, ist Dokploy die stressärmere Wahl: kleinere Fläche und eine kürzere Geschichte von schwerwiegenden Offenlegungen.
Eine Anmerkung zum Deployen beider Tools
Sobald Sie gewählt haben, ist die Installation selbst ein Befehl bei jedem Projekt, aber es gibt eine Abkürzung, die man kennen sollte. Sowohl Coolify als auch Dokploy sind als One-Click-Deployments verfügbar in unser Marketplace, mit vorinstalliertem Ubuntu 24.04 und Docker und bereits zugänglichem Dashboard. Wenn Sie das manuelle Setup überspringen wollen, sind die Marketplace-Einträge für Coolify und Dokploy der schnellste Weg. Wenn Sie lieber von einem sauberen Betriebssystem aus starten und den offiziellen Installer selbst ausführen, veröffentlichen beide Projekte ein Einzeiler-Skript; wählen Sie, was zu Ihrem Provisioning-Workflow passt.
Häufig gestellte Fragen
Ist Dokploy nach der Lizenzänderung von 2026 noch Open Source?
Ja, für die Kernplattform. Mit Wirkung zum January 21, 2026 ist Dokploys Kern standardmäßiges Apache 2.0. Eine separate Dokploy Source Available License regelt nun Code in proprietary/ Verzeichnissen, derzeit auf künftige Enterprise-Funktionen beschränkt (SSO/SAML, feingranulares RBAC, Audit-Logs, White-Labeling). Für Solo- und Kleinteam-Selbsthosting ist Dokploy faktisch Open Source.
Sind die Coolify-Sicherheitslücken vom Januar 2026 noch ein Problem?
Die 11 offengelegten CVEs sind in Coolify v4.0.0 (veröffentlicht April 27, 2026) gepatcht. Wenn Sie v4.0.0 oder neuer betreiben, sind die offengelegten Schwachstellen behoben. Was bleibt, ist die Exposition: Halten Sie Coolify aktuell und stellen Sie das Dashboard nicht dem öffentlichen Internet zur Verfügung. Binden Sie es an ein privates Netzwerk oder setzen Sie es hinter ein VPN.
