Welche Plattform passt zu Ihrer Anwendung? WZ-IT ordnet Plattform und Betriebsverantwortung ein: Coolify betreiben lassen oder Kubernetes planen und betreiben.
Docker Compose, Coolify und Kubernetes lösen nicht dasselbe Problem auf drei Qualitätsstufen. Sie liegen auf unterschiedlichen Abstraktionsebenen und passen zu unterschiedlichen Betriebsmodellen:
- Docker Compose beschreibt eine Anwendung aus mehreren Containern und führt sie typischerweise auf einem Docker-System aus.
- Coolify setzt eine selbst gehostete Plattformoberfläche auf Docker-Infrastruktur und automatisiert Git-Deployments, Domains, TLS und zahlreiche Anwendungsaufgaben.
- Kubernetes ist eine verteilte Orchestrierungs-API für Cluster, Workloads und gemeinsame Plattformstandards.
Die beste Lösung ist nicht die mit den meisten Funktionen, sondern die kleinste, die Verfügbarkeit, Delivery, Sicherheit und Wachstum zuverlässig abbildet.
Inhaltsverzeichnis
- Die drei Modelle in einem Satz
- Docker Compose: direkt und kontrollierbar
- Coolify: selbst gehostete Anwendungsplattform
- Kubernetes: verteilte Plattform-API
- Docker Compose vs. Kubernetes vs. Coolify im Vergleich
- Produktivbetrieb und Hochverfügbarkeit in den drei Modellen
- Welche Plattform für welches Szenario
- Wechsel ohne Big Bang: von Compose zu Coolify oder Kubernetes
- Unsere Entscheidungslogik
Die drei Modelle in einem Satz
| Modell | Kernidee | Typischer Einsatz |
|---|---|---|
| Docker Compose | deklarierte Container eines Stacks auf einem Docker-System | wenige Anwendungen, überschaubares Team, direkte Kontrolle |
| Coolify | selbst gehostete PaaS-artige Bedien- und Delivery-Schicht auf Docker | mehrere Apps, Git-Deployments, wenig Plattformpersonal |
| Kubernetes | deklarative, verteilte Orchestrierungs- und Plattform-API | viele Workloads, mehrere Teams, Clusterbetrieb, Policies und Skalierung |
Docker Compose kann auch innerhalb größerer Organisationen eine geeignete Basis für stabile, klar abgegrenzte Systeme sein. Kubernetes macht eine Anwendung umgekehrt nicht automatisch resilient oder sicher.
Docker Compose: direkt und kontrollierbar
Die Docker Compose-Dokumentation beschreibt Compose als Werkzeug zum Definieren und Ausführen von Multi-Container-Anwendungen. Eine YAML-Datei bündelt Services, Netzwerke, Volumes, Umgebungsvariablen und Abhängigkeiten. Ein Aufruf startet den gesamten Stack.
Stärken
- kleine Lern- und Betriebsfläche,
- transparentes Verhältnis zwischen Host, Containern, Ports und Volumes,
- lokal und auf Servern ähnlich nutzbar,
- sehr großes Docker-Ökosystem,
- einfache Sicherung und Wiederherstellung bei gut strukturierten Volumes,
- kaum zusätzliche Plattformkomponenten.
Grenzen
- kein eigener Scheduler für mehrere Hosts,
- kein eingebauter Cluster-Regelkreis, der Workloads nach Hostausfall anderswo startet,
- Rollouts, Secrets, Policies und hostübergreifendes Netzwerk brauchen zusätzliche Werkzeuge oder Prozesse,
- Self-Service und Trennung mehrerer Teams sind nicht der Kern des Modells.
Compose eignet sich besonders, wenn die Anwendung mit einem definierten Host oder einer kleinen Zahl bewusst getrennter Hosts zuverlässig betrieben werden kann. Redundanz lässt sich extern bauen, aber sie wird dann nicht durch Compose orchestriert.
Coolify: selbst gehostete Anwendungsplattform
Coolify ist eine Open-Source-Plattform, die Server über SSH verwaltet und Anwendungen auf Docker-Basis bereitstellt. Sie verbindet Git-Repositories, Buildpacks oder Dockerfiles mit Deployment, Domains, automatischem TLS, Umgebungsvariablen und einer Weboberfläche. Ein Katalog vorkonfigurierter Services vereinfacht den Betrieb vieler Open-Source-Anwendungen.
Stärken
- Git-basiertes Deployment ohne eigene Plattformoberfläche entwickeln zu müssen,
- Vorschau-Deployments und automatische Builds,
- Domains, Reverse Proxy und TLS integriert,
- Bedienoberfläche für Entwickler und Administratoren,
- mehrere Server können von einer zentralen Coolify-Instanz verwaltet werden,
- self-hosted und damit auf Proxmox, Hetzner, OVHcloud oder eigener Hardware betreibbar.
Grenzen
Coolify bleibt im Kern eine Docker-basierte Plattform. Seine Dokumentation zu mehreren Servern stellt klar (Stand Oktober 2026), dass zusätzliche Server allein keinen Verkehr verteilen und noch kein vollständig hochverfügbares System ergeben: Load Balancer mit Health Checks, DNS, Firewall-Regeln sowie gemeinsamer Daten- und Session-Speicher müssen separat eingerichtet werden. Docker-Compose-Anwendungen und Anwendungen mit persistentem Storage lassen sich zudem nicht auf weitere Server verteilen. Die zentrale Coolify-Instanz verwaltet Zielserver, sie ersetzt aber nicht das vollständige Scheduling-, Policy- und Controller-Modell von Kubernetes.
Das ist kein grundsätzlicher Nachteil. Es ist genau der Grund, warum Coolify für viele Teams schneller verständlich und günstiger zu betreiben ist.
Wir betreiben Coolify für Kunden und setzen es auch für eigene Anwendungen ein. Coolify-Betrieb umfasst Updates, Backups und Monitoring. Mehr zur Auswahl im PaaS-Vergleich.
Kubernetes: verteilte Plattform-API
Kubernetes verwaltet Workloads über eine gemeinsame Cluster-API. Scheduler und Controller verteilen Pods und gleichen den gewünschten Zustand kontinuierlich mit der Realität ab. Deployments, Services, StatefulSets, Jobs, RBAC, NetworkPolicies und Erweiterungen bilden eine umfassende Plattformbasis.
Stärken
- Orchestrierung über mehrere Nodes,
- deklarative Rollouts und Selbstheilung,
- standardisierte API für Plattformautomation und GitOps,
- horizontale Skalierung und flexible Platzierungsregeln,
- Namespaces, RBAC, Quotas und Policies für mehrere Teams,
- großes Ökosystem für Netzwerk, Storage, Security und Observability,
- portabel zwischen Proxmox, Bare Metal, europäischen Clouds und EKS, AKS oder GKE.
Grenzen
- deutlich mehr Komponenten und Wechselwirkungen,
- regelmäßige Cluster- und Add-on-Upgrades,
- komplexere Fehlersuche über Anwendung, Pod, Node, CNI, Ingress und Storage,
- höhere Anforderungen an Monitoring, Security und Betriebsbereitschaft,
- persistente Workloads brauchen eine explizite Storage- und Backup-Architektur.
Die Grundlage erklärt Was ist Kubernetes?. Ob diese zusätzlichen Fähigkeiten gebraucht werden, behandelt Brauchen wir Kubernetes?.
Docker Compose vs. Kubernetes vs. Coolify im Vergleich
| Kriterium | Docker Compose | Coolify | Kubernetes |
|---|---|---|---|
| Einstieg | niedrig | niedrig bis mittel | hoch |
| Primäre Ebene | Anwendungsstack | App-Delivery auf Docker | Cluster- und Plattform-API |
| Weboberfläche | nein | ja | abhängig von Zusatzwerkzeugen |
| Git-Deployments | über CI/CD ergänzen | integriert | über CI/CD oder GitOps |
| Mehrere Hosts | manuell getrennte Stacks | zentral verwaltbare Zielserver | nativ als Cluster |
| Scheduler | nein | Docker-/Server-Zuordnung durch Plattform | ja |
| Selbstheilung | Container-Restart auf Host | Docker- und Plattformmechanismen | Controller über Nodes hinweg |
| Rolling Updates | eigener Prozess | plattformgestützt | nativ über Workload-Controller |
| Autoscaling | extern | begrenzt/eigene Automation | HPA/VPA und Cluster-Autoscaling |
| Teamtrennung | über Umgebung/Hosts | Projekte, Teams und Rollen | Namespaces, RBAC, Quotas, Policies |
| Netzwerk-Policies | host-/firewallbasiert | Docker-Netze und externe Regeln | CNI-abhängige NetworkPolicies |
| Persistenter Storage | Volumes/Bind Mounts | Docker-Volumes und Storage-Ziele | CSI, StorageClasses, PVCs |
| Plattformaufwand | gering | mittel | hoch |
„Nativ“ bedeutet dabei nicht „automatisch korrekt“. Ein Kubernetes-HPA skaliert nur sinnvoll, wenn Metriken, Resource Requests und Anwendung dafür geeignet sind. Ein StatefulSet ist noch kein Datenbank-Backup.
Produktivbetrieb und Hochverfügbarkeit in den drei Modellen
| Was zusätzlich nötig ist | Verantwortung im Betrieb |
|---|---|
| Backup und Restore-Test | Daten und Plattformkonfiguration sichern, Wiederanlauf prüfen |
| Monitoring | Host, Plattform und Anwendung überwachen, Alarmempfänger benennen |
| Updates | Host, Images und Plattform kontrolliert aktualisieren |
| Secrets | Zugriff, Ablage und Rotation festlegen |
| Hostausfall | Wiederanlauf oder Failover samt Datenabhängigkeiten testen |
Die häufigste Fehlentscheidung entsteht, wenn „mehrere Container“ mit „hochverfügbar“ gleichgesetzt werden.
Compose
Ein Container kann nach einem Prozessfehler automatisch neu starten. Fällt aber der Host aus, braucht es externe Virtualisierungs-HA, einen zweiten vorbereiteten Host oder einen Wiederanlaufprozess. Für viele Businesssysteme ist ein klarer RTO mit Proxmox HA und Backup wirtschaftlicher als ein kompletter Kubernetes-Stack.
Coolify
Coolify kann mehrere Server verwalten und Deployments vereinfachen. Eine hochverfügbare Gesamtarchitektur umfasst dennoch Load Balancer, redundante Zielsysteme, Datenhaltung und auch die Control-Plane-Komponenten der Plattform. Das muss bewusst geplant werden.
Kubernetes
Kubernetes kann Workloads bei Node-Ausfällen neu verteilen, wenn genug unabhängige Nodes, Netzwerk und verfügbarer Storage vorhanden sind. Eine hochverfügbare Control Plane, mehrere Failure Domains und eine Anwendung mit mehreren Replikaten sind gesonderte Voraussetzungen. Drei Kubernetes-VMs auf einem einzelnen Hypervisor sind kein hochverfügbares Gesamtsystem.
Welche Plattform für welches Szenario
Kleine interne Businessanwendung
Empfehlung: meist Compose oder Coolify. Wenig Komponenten, einfache Zuständigkeit und kontrollierbare Wartungsfenster rechtfertigen selten einen Cluster.
Agentur oder Produktteam mit mehreren Webanwendungen
Empfehlung: Coolify kann Git-Deployments, Domains und TLS mit überschaubarem Aufwand bündeln. Kubernetes wird interessant, wenn Teamtrennung, komplexe Delivery und verteilte Resilienz wichtiger werden.
SaaS mit mehreren APIs, Workern und Umgebungen
Empfehlung: Kubernetes prüfen. Häufige Rollouts, mehrere Workloads, Skalierung und standardisierte Policies können den Plattformaufwand rechtfertigen.
Bestehende Legacy-Anwendung
Anwendungsmodernisierung ist der Einstieg für Legacy-Anwendungen. Kubernetes-Anwendungsmodernisierung beschreibt den Weg zum Cluster.
Empfehlung: zuerst containerisieren und Betriebsabhängigkeiten ordnen. Compose ist oft die beste Zwischen- oder Dauerlösung. Kubernetes erst wählen, wenn die Zielanforderungen es verlangen.
Souveräne Multi-Tenant-Plattform
Empfehlung: Kubernetes auf Proxmox oder europäischer Infrastruktur, wenn Namespaces, Policies, getrennte Teams und standardisierte Delivery tatsächlich gebraucht werden. Für wenige Mandanten kann eine saubere VM- oder Coolify-Trennung einfacher und stärker isolierend sein.
Mittelweg: k3s statt Vollcluster
k3s, RKE2 und Talos im Vergleich hilft bei der Distributionswahl. k3s reduziert die Installationsfläche, übernimmt aber weiterhin Kubernetes-Verantwortung für Storage, Updates und Wiederanlauf.
Wechsel ohne Big Bang: von Compose zu Coolify oder Kubernetes
Die Plattformwahl ist nicht endgültig. Eine saubere Containerisierung erhält Optionen:
Von VM zu Compose
Anwendung und Abhängigkeiten werden in Images überführt, Konfiguration externalisiert, Daten in definierte Volumes oder externe Dienste verschoben und Health Checks ergänzt. Delivery und Backup werden reproduzierbar.
Von Compose zu Coolify
Bestehende Dockerfiles und Repositories lassen sich häufig weiterverwenden. Coolify übernimmt Build, Deployment, Domains und Zertifikate. Volumes, Datenbanken und Wechselwirkungen müssen dennoch vor der Migration bewertet werden.
Von Compose oder Coolify zu Kubernetes
Container-Images bleiben oft verwendbar, die Betriebsdefinition ändert sich jedoch. Aus Compose-Services werden Deployments oder StatefulSets, Services, ConfigMaps, Secrets, PVCs und Policies. Zusätzlich braucht es Ingress/Gateway, Storage, Observability und einen Upgrade-Prozess. Eine automatische Dateikonvertierung ersetzt diese Architekturarbeit nicht.
Unsere Entscheidungslogik
WZ-IT entscheidet in dieser Reihenfolge:
- Workload: Zustand, Daten, Protokolle, Skalierung und Abhängigkeiten verstehen.
- Betriebsziel: Verfügbarkeit, RTO/RPO, Deployment-Frequenz und Security festlegen.
- Organisation: Teams, Rollen, Plattformkompetenz und Service Level einordnen.
- Infrastruktur: Public Cloud, europäische Provider, Proxmox oder On-Premises betrachten.
- Kleinste passende Plattform wählen: Compose, Coolify oder Kubernetes.
- Lebenszyklus belegen: Monitoring, Upgrade, Backup und Restore vor Produktion testen.
Aus diesen Kriterien entsteht ein dokumentiertes Zielmodell. Wenn ein Cluster passt, verbinden wir Plattform, privaten NetBird-Zugriff und Managed Operations.
Fazit
Docker Compose maximiert Einfachheit und direkte Kontrolle. Coolify ergänzt eine produktive Self-Service- und Delivery-Schicht für Docker-Anwendungen. Kubernetes liefert eine verteilte Plattform-API für umfangreichere Automatisierung, Resilienz und Governance.
Die drei Modelle sind Werkzeuge in demselben Modernisierungsbaukasten. Die Auswahl richtet sich nach Anwendung, Verfügbarkeitsziel, Delivery-Prozess, Skalierung und verfügbarer Betriebskapazität.
Für einen beschlossenen Wechsel folgt die Compose-zu-Kubernetes-Anleitung mit Kompose.
