Jeder Push läuft nach demselben Ritual ab: per SSH einloggen, das Repository ziehen, den Compose-Stack wieder hochfahren, hoffen, dass nichts kaputt ist, und versuchen sich zu erinnern, ob die Migration lief. Diese manuelle Schleife funktioniert, bis Sie wiederholbare Deployments brauchen, einen klaren Nachweis darüber, was läuft, oder eine Erholung von Drift.
Doco CD ist eine direkte Antwort darauf. Es ist ein kleiner Go-Dienst, der Ihr Git-Repository beobachtet und Compose-Änderungen beim Push anwendet: Webhook oder Polling, Ihre Wahl. ArgoCD und Flux machen das für Kubernetes, doch Doco CD umgeht Kubernetes, weil es keine Control Plane braucht.
Dieser Test behandelt, was Doco CD leistet, was nicht, und wie es sich gegen Komodo, den GitOps-Modus von Portainer, Dokploy und ein schlichtes Skript aus GitHub Actions + SSH schlägt. Am Ende wissen Sie, ob es zu Ihrem Setup passt und was Sie sonst wählen sollten.
Kurzfassung
- Doco CD ist ein winziger, Compose-nativer GitOps-Agent: Er beobachtet ein Git-Repository (GitHub, GitLab, Gitea, Forgejo und andere) und gleicht Ihren Stack ab, sobald sich etwas ändert.
- Die eingebaute Unterstützung für externe Secret-Provider, zusammen mit SOPS-basierter Verschlüsselung, ist der Unterschied zu einem selbst gebauten Deploy-Skript.
- Laut seiner README positioniert es sich als „eine einfache Portainer- oder ArgoCD-Alternative für Docker“. Diese Einordnung trifft es ungefähr.
- Die echten Grenzen: ein einziger Code-Owner, Versionierung vor 1.0, keine Oberfläche für Flottenverwaltung und ein Reconciliation-Status, der erst beim nächsten Poll oder Webhook-Ereignis neu aufgebaut wird.
- Wählen Sie es, wenn Sie einen oder wenige Compose-Hosts betreiben und Git ohne Oberfläche zur Quelle der Wahrheit machen wollen. Komodo passt zu einer Flotte, Portainer, wenn Sie eine Oberfläche möchten, Dokploy für ein PaaS-Gefühl, und GitHub Actions + SSH, wenn es wirklich nur ein Dienst auf einem Host ist.
Die Lücke, die Doco CD schließen will
Für alle, die 2026 Docker Compose betreiben, gibt es einen seltsamen Zwischenraum. Große GitOps-Werkzeuge wie Argo CD und Flux zielen auf Kubernetes, während Watchtower mit seinem Registry-Polling auf Image-Änderungen reagiert, statt einen versionierten Compose-Zustand anzuwenden. Das Repository wurde am 17. Dezember 2025 archiviert und weist inzwischen darauf hin, dass das Projekt nicht mehr gepflegt wird.
GitHub Actions plus ein SSH-Deploy-Schritt funktioniert. Für einen Dienst auf einem Host ist das die richtige Wahl. Ärger gibt es, sobald ein zweiter Host oder ein zweiter Stack dazukommt oder Sie wissen wollen, welcher Commit gerade ausgerollt ist. Workflow-Logs bekommen Sie weiterhin, aber keine Compose-native Reconciliation, keine Drift-Korrektur und keinen dauerhaften Blick darauf, ob der Host noch zum Repository passt.
Der Pitch von Doco CD, direkt aus der README, lautet: „eine einfache Portainer- oder ArgoCD-Alternative für Docker“. Genau darin liegt der Punkt: klein, Compose-nativ, kein Kubernetes, keine Oberfläche zu pflegen, keine zentrale Control Plane zu betreuen. Wenn Sie kein K8s betreiben und es auch nie wollten, ist das die Kategorie, nach der Sie gesucht haben.
Wie Doco CD tatsächlich arbeitet
Doco CD ist eine einzige Go-Binärdatei, die in einem Docker-Container läuft, ein Git-Repository beobachtet und Compose-Änderungen anwendet, sobald sich der Repository-Zustand ändert. Das ist das ganze Konzept. Spannend wird es bei den Standardwerten und den Integrationen.
Auslöser. Zwei Modi: Webhook oder Polling. Der Webhook ist nahezu sofort, braucht aber einen offenen Port oder, realistischer, einen Reverse Proxy vor Doco CD. Polling ist ein periodisches Abholen: leicht verzögert, ohne eingehenden Port. Polling ist die einfachere Voreinstellung, und laut der offiziellen Dokumentation sind beide gleichrangig. Entscheiden Sie danach, ob Ihr Host einen erreichbaren öffentlichen Endpunkt hat und wie schnell Sie deployen müssen.
Konfiguration pro Repository. Eine Datei .doco-cd.yaml (oder .doco-cd.yml) liegt im Wurzelverzeichnis des Repositorys neben Ihrer Compose-Datei. Das einzige Pflichtfeld ist der Name des Deployments. Eine minimale Konfiguration sieht so aus:
# .doco-cd.yaml
name: my-stack
# Everything below is optional. These are the defaults.
timeout: 180 # seconds
remove_orphans: true
prune_images: true
force_recreate: falseDas sind die dokumentierten Standardwerte: 180 Sekunden Timeout, verwaiste Container werden entfernt, Images werden aufgeräumt, kein erzwungenes Neuerstellen.
Automatische Erkennung. Bei aktivierter automatischer Erkennung durchsucht Doco CD Unterverzeichnisse nach Compose-Dateien, sodass ein einziges Repository mehrere Stacks beherbergen kann. Es unterstützt außerdem mehrere Deployment-Konfigurationen in einer Datei, geschrieben als YAML-Dokumente, getrennt durch eine Zeile aus drei Bindestrichen. Die Standardwerte fürs Aufräumen sind vorsichtig gewählt und lohnen einen Blick, bevor Sie sich darauf verlassen:
| Einstellung | Standardwert | Was das bedeutet |
|---|---|---|
delete | false | Ein veraltetes Deployment bleibt bestehen, wenn seine App aus dem Arbeitsverzeichnis verschwindet. |
remove_volumes | false | Volumes überleben, wenn ein automatisch erkannter Stack gelöscht wird. |
remove_images | true | Ungenutzte Images werden entfernt, wenn ein automatisch erkannter Stack gelöscht wird. |
Anders gesagt: Hinter Ihrem Rücken wird nichts abgerissen, solange Sie das Löschen nicht einschalten, und selbst dann gehen Ihre Datenvolumes als Letztes.
Unterstützte Git-Anbieter. Unterstützt werden GitHub, GitLab, Gitea, Forgejo, Gogs und Azure DevOps. Azure DevOps ist die Ausnahme bei Webhooks, denn Azure Service Hooks werden nicht unterstützt. Die Unterstützung für Gitea und Forgejo zählt, wenn Sie Ihre Forge selbst hosten.
Docker Swarm. Wird als Ziel unterstützt. Was die Seite zu den Deploy-Einstellungen ausdrücklich festhält: Im Swarm-Modus prüft die Reconciliation weder Container-Neustarts noch den Health-Status, und das Aufräumen von Images wird in Swarm nicht unterstützt. Ist Swarm Ihr Ziel, bekommen Sie Deployments, aber keine vollständige Health-Reconciliation.
Reconciliation. Standardmäßig gilt ein Limit von 5 Neustarts in einem Fenster von 300 Sekunden, damit flatternde Health Checks nicht endlos in einer Schleife laufen. Dasselbe Repository mit anderer Ref läuft sequenziell, dasselbe Repository mit gleicher Ref läuft parallel. Dieser letzte Punkt ist subtil, aber nützlich: Mehrere Deployments derselben Ref stellen sich nicht hintereinander an.
Eingebaute externe Secret-Provider. Das ist einer der stärkeren Gründe, Doco CD einem einfachen Deploy-Skript vorzuziehen: Es unterstützt AWS Secrets Manager, Bitwarden Secrets Manager, Bitwarden Vault / Vaultwarden, 1Password, 1Password Connect, Infisical, OpenBao und Webhook. Getrennt davon unterstützt es SOPS-basierte Verschlüsselung für sensible Deployment-Daten. Damit haben Sie einen sauberen Weg weg von env-Dateien im Klartext in Git, ohne den gesamten Ablauf zur Auflösung von Secrets selbst zu bauen.
Der Rest. Doco CD liefert Prometheus-Metriken, Job-Scheduling, Benachrichtigungen, ein Distroless-Container-Image und eine Apache-2.0-Lizenz. Laut seiner Release-Historie ist mit Stand 20. August 2026 v0.109.2 das neueste stabile Release und v0.110.0-rc.1 die neueste Vorabversion.
Die Aufgabe von Doco CD endet bei „das Manifest anwenden“, danach ist es ganz normales Docker. Die eigenen Log-Befehle von Compose sind das Mittel, mit dem Sie prüfen, was läuft.
Praxistipp zu Secrets. Liegen in Ihrem privaten Repository noch env-Dateien im Klartext, setzen Sie zuerst auf die externen Secret-Provider von Doco CD oder auf seine SOPS-Unterstützung. Das Ziel ist einfach: Klartext-Secrets raus aus Git, und die Deployments lösen die Werte trotzdem zur Laufzeit auf.
Entwickeln Sie auf einem Linux-VPS mit Root-Zugriff, NVMe und AMD-EPYC-Power.
Linux-Pläne ansehenWo Doco CD an Grenzen stößt
Jedes Werkzeug hat Grenzen, und die von Doco CD sollte man kennen, bevor man ein Wochenende in die Einrichtung steckt.
Ein einziger Code-Owner. Die CODEOWNERS-Datei des Repositorys weist alle Pfade kimdre zu. Releases erscheinen weiterhin häufig, doch die Steuerung liegt bei einer einzigen Person.
Vor 1.0. Doco CD nutzt weiterhin die 0.x-Versionierung, also fixieren Sie ein getestetes Release und lesen Sie vor dem Rollout die Upgrade-Hinweise. Das geschlossene GitHub-Issue #851 zeigt, warum: Docker v29 zwang das Projekt, von veralteten Docker-Go-Modulen wegzugehen.
Keine Shell im Container von Doco CD. Aus Sicherheitsgründen bietet Doco CD keine Shell-Umgebung und führt keine beliebigen Host-Skripte aus. Aufgaben vor und nach dem Deployment müssen über Init-Container, Sidecars oder Compose-Lifecycle-Hooks laufen, was gegenüber Werkzeugen, die einfach ein Deploy-Skript ausführen, zusätzliche Konfiguration bedeutet.
Zustandsverlust beim Neustart. Der Reconciliation-Status liegt im Arbeitsspeicher. Startet Doco CD neu, wird er erst beim nächsten Poll oder Webhook-Ereignis wieder aufgebaut, die Lücke hängt also von Ihrem Polling-Intervall ab oder davon, wie schnell der nächste Webhook eintrifft.
Keine Oberfläche für Flottenverwaltung. Multi-Host verlangt nicht länger einen Agenten pro Host. Seit v0.102.0 können Deployment-Konfigurationen auf entfernte Docker-Kontexte zielen, SSH-Kontexte eingeschlossen, und ein einzelnes Repository kann mehrere Deployment-Ziele definieren. Eine Doco-CD-Instanz pro Host zu betreiben, ist weiterhin legitim, doch eine zentrale Instanz kann jetzt auf entfernte Docker-Hosts ausrollen. Was Doco CD weiterhin fehlt, ist die Flottenoberfläche von Komodo und ein zentrales Host-Inventar.
Der RAM- und CPU-Bedarf ist nicht in Zahlen dokumentiert. Die offizielle Dokumentation nennt die Anforderungen „winzig“, veröffentlicht aber keine Basiswerte. Dimensionieren Sie den VPS nach den Anwendungen, die darauf laufen sollen, lassen Sie betrieblichen Spielraum und prüfen Sie den tatsächlichen Verbrauch von Doco CD in Ihrer eigenen Umgebung.
Praxistipp zu Multi-Host. Nutzen Sie pro Host einen eigenen Docker-Kontext und ein eigenes Deployment-Ziel, beschränken Sie den SSH-Zugang und halten Sie Webhook- oder API-Secrets eindeutig. Wenn Sie isolierte Agenten bevorzugen, bleibt eine Instanz von Doco CD pro Host weiterhin gültig.
Doco CD gegen die Alternativen
Die vier anderen Werkzeuge, die ich in die engere Wahl nehmen würde, lösen alle „Compose automatisch aus Git ausrollen“, aber mit sehr unterschiedlichen Kompromissen. Die Frage ist nicht, ob Sie das tun, das haben Sie längst entschieden. Die Frage ist, welche Bauform zu Ihrem Setup passt. Hier der direkte Vergleich.
| Tool | Auslöser | Multi-Host-Modell | Secrets | Weboberfläche | Lizenz |
|---|---|---|---|---|---|
| Doco CD | Webhook oder Polling | Entfernte Docker-Kontexte, keine Flottenoberfläche | Externe Provider plus SOPS | Nichts | Apache-2.0 |
| Komodo | Webhook plus geplante Synchronisierung | Zentraler Core plus Periphery-Agenten | Verwaltung von Variablen und Secrets | Ja | GPL-3.0 |
| Portainer (CE/BE) | Webhook oder Polling | Portainer-Agent | Eingeschränkt, mehr Optionen in BE | Ja | Zlib, kommerzielle Bedingungen für BE |
| Dokploy | Durch Push ausgelöst | Mehrere Server oder Docker Swarm | Eingebaute Umgebungsverwaltung | Ja | Apache-2.0, mit proprietären Komponenten |
| GitHub Actions + SSH | Durch Push ausgelöst | Was Sie selbst skripten | Was Sie selbst skripten | Nichts | Nicht zutreffend |
Kurz zu jedem, denn die Tabelle liefert die Form und der Kommentar das Warum:
Komodo. Die ernsthafte Multi-Host-Alternative. Ein zentraler Core-Dienst plus ein Periphery-Agent auf jedem Host, eine Oberfläche, die alle sieht, Git-gesteuerte Builds zusätzlich zu Deployments und Unterstützung für Docker Swarm. Die Einrichtung ist schwerer, denn Sie betreiben eine Datenbank und eine Control Plane, aber es ist die richtige Bauform, wenn Sie eine Flotte haben. Komodo passt besser, sobald zentrale Flottensteuerung zählt.
Portainer (CE oder BE) mit GitOps. Eine vollwertige grafische Oberfläche über der Git-Synchronisierung. Die richtige Wahl, wenn das Team Container per Klick verwalten will und dabei auch CD braucht. Wenn ohnehin jemand in der Oberfläche Logs liest und Container neu startet, kann CD gleich dort mitwohnen. Der Ressourcenbedarf ist höher als bei Doco CD. OIDC/SSO und feingranulares RBAC stecken hinter der Bezahlschranke der Business Edition. Unser Leitfaden zu Portainer-Alternativen deckt die breitere Landschaft der Docker-Verwaltung ab.
Dokploy. PaaS-Stil. Meinungsstark, rollt beim Push automatisch aus, hat für alles eine Weboberfläche und richtet Ihnen Traefik samt sauberen URLs von Haus aus ein. Besser für Teams, die ein Heroku-Gefühl wollen und dafür die rohe Compose-Flexibilität eintauschen. Wenn Sie allergisch auf YAML reagieren, ist das der leichteste Weg zu „git push, App ist ausgerollt“.
GitHub Actions + SSH. Null zusätzliche Infrastruktur. Der Deploy-Job lebt in dem Workflow, den Sie ohnehin haben. Sie bekommen Workflow-Logs, aber keine Compose-native Reconciliation, keine Drift-Korrektur und keinen dauerhaften Blick auf den Host-Zustand, es sei denn, Sie bauen diese Teile selbst. Prima für einen Dienst auf einem Host. Es bricht, sobald ein zweites Ziel dazukommt oder Sie wissen wollen, was wo läuft, ohne sich per SSH einzuloggen. Für den einfachsten Teil der Leserschaft ist GitHub Actions + SSH weiterhin die richtige Antwort.
Es gibt einen neueren Kandidaten namens stackd , das sich mit ähnlichen Worten beschreibt: „GitOps ohne die Kubernetes-Steuer“. Es lohnt sich zu wissen, dass die Kategorie lebt, aber nicht, es heute per Münzwurf Doco CD vorzuziehen.
Wann Doco CD die richtige Wahl ist (und wann nicht)
Wählen Sie Doco CD, wenn:
- Sie betreiben einen oder wenige Docker-Compose-Hosts und wollen Git als Quelle der Wahrheit.
- Sie bearbeiten lieber YAML in Ihrem Editor, als sich durch eine Oberfläche zu klicken.
- Sie wollen Unterstützung für externe Secret-Provider und SOPS-basierte Verschlüsselung, ohne den gesamten Ablauf selbst zu bauen.
- Ein Projekt mit einem einzigen Maintainer, vor 1.0, aber aktiv entwickelt, ist für Sie in Ordnung.
Komodo. Wählen Sie es, wenn Sie viele Hosts verwalten und zentrale Flottensteuerung brauchen, oder wenn Sie Git-gesteuerte Builds und nicht nur Deployments unter einem Dach benötigen.
Portainer (CE oder BE). Wählen Sie es, wenn das Team neben CD eine Oberfläche für den täglichen Containerbetrieb will, wenn also die visuelle Ebene der eigentliche Grund für die Überlegung ist.
Dokploy. Wählen Sie es, wenn Sie ein Deploy-Erlebnis im PaaS-Stil möchten und die rohe Compose-Kontrolle nicht brauchen.
GitHub Actions + SSH. Bleiben Sie dabei, wenn es ein Dienst auf einem Host ist und Sie weder Reconciliation noch Drift-Korrektur brauchen.
Für alle im Zwischenraum nach Watchtower und vor Kubernetes ist Doco CD eine starke leichtgewichtige Wahl. Meine Einschätzung: Für ein neues Homelab oder kleines SaaS würde ich mit Doco CD starten, solange Git-first und ohne Oberfläche passt, und dann auf Komodo wechseln, sobald zentrales Inventar, Berechtigungen und Flottentransparenz zur Anforderung werden.
Welches Werkzeug Sie auch wählen, betreiben Sie es auf einem Linux-VPS, der auf die Compose-Lasten ausgelegt ist, die er tragen soll. Cloudzys Linux-VPS ist dafür ein vernünftiges Zuhause, mit Root-Zugriff ab Werk. Und wenn Sie sich den apt-Tanz sparen wollen, können Sie auch Docker mit einem Klick ausrollen aus unserem Marketplace.
Unser Marketplace hat außerdem Ein-Klick-Images für Gitea, mit dem sich Doco CD nativ integriert. Es gibt außerdem Images für Komodo sowie für Portainer, falls Sie entscheiden, dass eines davon eher Ihre Bauform ist.
Häufig gestellte Fragen
Ist Doco CD produktionsreif?
Doco CD lässt sich produktiv einsetzen, wenn sein Risikoprofil zu Ihrer Last passt. Es wird aktiv entwickelt, nutzt aber weiterhin Versionierung vor 1.0, und seine CODEOWNERS-Datei ordnet das Projekt einer einzigen Person zu. Fixieren Sie ein getestetes Release, testen Sie Upgrades vor dem Rollout, und denken Sie bei kritischer Infrastruktur über eine breitere Governance nach.
Wie verwalte ich mehrere Hosts mit Doco CD?
Nutzen Sie mit Doco CD für jeden Host einen eigenen Docker-Kontext und ein eigenes Deployment-Ziel. Eine einzige Doco-CD-Instanz kann per SSH oder TCP auf mehrere entfernte Docker-Hosts ausrollen; eine Instanz pro Host bleibt ein optionales Isolationsmodell. Nehmen Sie Komodo, wenn Sie zentrales Inventar, Berechtigungen und Flottentransparenz brauchen.
Was ist der Unterschied zwischen Webhook- und Polling-Modus?
Der Webhook-Modus rollt fast sofort aus, sobald ein Push in Git landet, verlangt aber einen aus dem Internet erreichbaren Port oder einen Reverse Proxy vor Doco CD. Der Polling-Modus prüft das Repository nach Zeitplan, Deployments verzögern sich also leicht, dafür muss kein Port offen sein. Polling ist die einfachere Voreinstellung; Webhooks lohnen sich, wenn Sie oft pushen oder schnelle Rückmeldung brauchen.
Wie schlägt sich Doco CD gegen Komodo?
Doco CD ist leichter und kommt ohne Oberfläche aus, und es kann mehrere Hosts über entfernte Docker-Kontexte verwalten. Komodo setzt auf einen zentralen Core-Dienst plus Periphery-Agenten und ergänzt eine Flottenoberfläche sowie Git-gesteuerte Builds. Nehmen Sie Doco CD für Compose-Deployments ohne Oberfläche, Komodo dann, wenn zentrale Flottensteuerung zählt.
Kann Doco CD Watchtower ersetzen?
Für den Anwendungsfall, den die meisten Watchtower-Nutzer wirklich wollten, „rolle aus, was in Git steht, sobald sich Git ändert“, lautet die Antwort ja: Genau das macht Doco CD. Für Watchtowers wörtliches Modell, eine Registry abzufragen und zu ziehen, sobald ein neuer Image-Tag auftaucht, lautet sie nein: Doco CD wird von Git ausgelöst, nicht von der Registry. Das Git-getriebene Modell ist für alles jenseits von Spielzeugdiensten die sicherere und besser prüfbare Wahl.
