Doco CD review: GitOps voor Docker Compose zonder de Kubernetes-overhead

Elke push volgt hetzelfde ritueel: inloggen via SSH, de repo ophalen, de Compose-stack weer opstarten, hopen dat er niets stuk is en proberen te herinneren of je de migratie hebt gedraaid. Die handmatige lus werkt tot je herhaalbare deployments nodig hebt, een duidelijk overzicht van wat er draait, of herstel van drift.

Doco CD is een direct antwoord. Het is een kleine Go-service die je Git-repo in de gaten houdt en Compose-wijzigingen toepast zodra je pusht: webhook of polling, jouw keuze. ArgoCD en Flux doen dit voor Kubernetes, maar Doco CD slaat Kubernetes over, omdat het geen control plane nodig heeft.

Deze review behandelt wat Doco CD wel doet, wat niet, en hoe het zich verhoudt tot Komodo, de GitOps-modus van Portainer, Dokploy en een eenvoudig GitHub Actions + SSH-script. Aan het eind weet je of het bij jouw opzet past en wat je anders moet kiezen.

TL;DR

• Doco CD is een piepkleine, Compose-native GitOps-agent: hij bewaakt een Git-repo (GitHub, GitLab, Gitea, Forgejo en andere) en brengt je stack weer in lijn zodra er iets verandert.
• Ingebouwde ondersteuning voor externe secret-providers, samen met SOPS-gebaseerde versleuteling, is het verschil met een zelfgebouwd deployscript.
• Volgens de eigen README positioneert het zich als "een eenvoudig alternatief voor Portainer of ArgoCD voor Docker". Dat kader klopt ongeveer.
• De echte beperkingen: één code-eigenaar, versienummers vóór 1.0, geen UI voor vlootbeheer en een reconciliatiestatus die pas na de volgende poll of webhook opnieuw wordt opgebouwd.
• Kies het als je één of enkele Compose-hosts draait en Git zonder UI als bron van waarheid wilt. Neem Komodo voor een vloot, Portainer als je een UI wilt, Dokploy voor een PaaS-gevoel, of GitHub Actions + SSH als het echt om één dienst op één host gaat.

Het gat dat Doco CD probeert te vullen

Er is een vreemd tussengebied voor iedereen die in 2026 Docker Compose draait. Grote GitOps-tools zoals Argo CD en Flux mikken op Kubernetes, terwijl het registry-polling model van Watchtower reageert op image-wijzigingen in plaats van een geversioneerde Compose-staat toe te passen. De repository werd op 17 december 2025 gearchiveerd en meldt nu dat het project niet langer wordt onderhouden.

GitHub Actions plus een SSH-deploystap werkt. Voor één dienst op één host is dat de juiste keuze. Het gedoe begint bij een tweede host, of een tweede stack, of wanneer je wilt weten welke commit nu draait. Je houdt workflow-logs, maar geen Compose-native reconciliatie, geen driftherstel en geen blijvend beeld of de host nog overeenkomt met de repo.

De pitch van Doco CD, rechtstreeks uit de README, is "een eenvoudig alternatief voor Portainer of ArgoCD voor Docker". Dat kader is precies het punt: klein, Compose-native, geen Kubernetes, geen UI om te onderhouden, geen centrale control plane om in de gaten te houden. Draai je geen K8s en wilde je dat ook niet, dan is dit de categorie die je zocht.

Hoe Doco CD echt werkt

Doco CD is één Go-binary die in een Docker-container draait, een Git-repository bewaakt en Compose-wijzigingen toepast zodra de staat van de repo verandert. Dat is het hele concept. Het interessante zit in de standaardwaarden en de integraties.

Triggers. Twee modi: webhook of polling. Een webhook is bijna instant, maar vereist een open poort, of realistischer een reverse proxy vóór Doco CD. Polling is periodiek ophalen: iets vertraagd, geen inkomende poort nodig. Polling is de eenvoudigere standaard, en volgens de officiële documentatie zijn beide volwaardig. Kies op basis van de vraag of je host een bereikbaar publiek eindpunt heeft en hoe snel je deployments moeten zijn.

Configuratie per repo. Een .doco-cd.yaml-bestand (of .doco-cd.yml) staat in de root van de repo, naast je Compose-bestand. Het enige verplichte veld is de naam van de deployment. Een minimale configuratie ziet er zo uit:

# .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: false

Dat zijn de gedocumenteerde standaardwaarden: een time-out van 180 seconden, verweesde containers verwijderd, images opgeruimd en geen geforceerde hercreatie.

Automatische detectie. Met automatische detectie aan doorzoekt Doco CD submappen op Compose-bestanden, zodat één repo meerdere stacks kan bevatten. Het ondersteunt ook meerdere deployconfiguraties in één bestand, geschreven als YAML-documenten gescheiden door een regel met drie streepjes. De standaardwaarden voor opruimen zijn behoudend en het loont ze te lezen voordat je erop vertrouwt:

Met andere woorden: er wordt niets achter je rug afgebroken zolang je verwijderen niet aanzet, en zelfs dan gaan je datavolumes als laatste.

Ondersteunde Git-providers. GitHub, GitLab, Gitea, Forgejo, Gogs en Azure DevOps worden ondersteund. Azure DevOps is de uitzondering bij webhooks, omdat Azure Service Hooks niet worden ondersteund. Ondersteuning voor Gitea en Forgejo telt als je je forge zelf host.

Docker Swarm. Wordt ondersteund als doel. Wat de pagina met deploy-instellingen expliciet vermeldt: in Swarm-modus controleert de reconciliatie geen containerherstarts of health-status, en het opruimen van images wordt in Swarm niet ondersteund. Is Swarm je doel, dan krijg je deployments, maar geen volledige health-reconciliatie.

Reconciliatie. Standaard geldt een limiet van 5 herstarts binnen een venster van 300 seconden, bedoeld om instabiele health checks niet eindeloos te laten doorlopen. Dezelfde repo met een andere ref draait sequentieel, dezelfde repo met dezelfde ref draait parallel. Dat laatste is subtiel maar handig: meerdere deployments van dezelfde ref staan niet achter elkaar in de rij.

Ingebouwde externe secret-providers. Dit is een van de sterkere redenen om Doco CD boven een simpel deployscript te verkiezen: het ondersteunt AWS Secrets Manager, Bitwarden Secrets Manager, Bitwarden Vault / Vaultwarden, 1Password, 1Password Connect, Infisical, OpenBao en Webhook. Daarnaast ondersteunt het SOPS-gebaseerde versleuteling voor gevoelige deploygegevens. Zo kom je netjes weg van env-bestanden in platte tekst in Git, zonder zelf de hele secret-resolutie te bouwen.

De rest. Doco CD biedt Prometheus-metrics, jobplanning, notificaties, een distroless container-image en een Apache-2.0-licentie. Volgens de releasegeschiedenis is per 20 augustus 2026 v0.109.2 de nieuwste stabiele release en v0.110.0-rc.1 de nieuwste pre-release.

Het werk van Doco CD stopt bij "pas het manifest toe"; daarna is het gewoon Docker. De eigen logcommando's van Compose zijn waarmee je bekijkt wat er draait.

Praktische tip over secrets. Staan er in je privérepo nog env-bestanden in platte tekst, geef dan voorrang aan de externe secret-providers van Doco CD of aan de SOPS-ondersteuning. Het doel is simpel: platte secrets uit Git houden en deployments toch de waarden laten ophalen tijdens runtime.

Waar Doco CD tekortschiet

Elk hulpmiddel heeft grenzen, en die van Doco CD zijn het waard om te kennen voordat je er een weekend insteekt.

Eén code-eigenaar. Het CODEOWNERS-bestand van de repository wijst alle paden toe aan kimdre. Er verschijnen nog steeds regelmatig releases, maar het bestuur ligt bij één persoon.

Vóór 1.0. Doco CD gebruikt nog steeds 0.x-versienummers, dus pin een geteste release vast en lees de upgradenotities vóór de uitrol. Het gesloten GitHub-issue #851 laat zien waarom: Docker v29 dwong het project om afscheid te nemen van verouderde Docker-Go-modules.

Geen shell in de Doco CD-container. Om veiligheidsredenen biedt Doco CD geen shell-omgeving en voert het geen willekeurige host-scripts uit. Taken vóór en na een deployment moeten via init-containers, sidecars of Compose-lifecycle-hooks lopen, wat extra configuratie oplevert vergeleken met tools die gewoon een deployscript draaien.

Statusverlies bij herstart. De reconciliatiestatus zit in het geheugen. Herstart Doco CD, dan wordt die status pas opnieuw opgebouwd bij de volgende poll of webhook, dus het gat hangt af van je pollinginterval of van hoe snel de volgende webhook binnenkomt.

Geen UI voor vlootbeheer. Multi-host vereist niet langer één agent per host. Sinds v0.102.0 kunnen deployconfiguraties gericht zijn op externe Docker-contexten, inclusief SSH-contexten, en één repository kan meerdere deploydoelen definiëren. Eén Doco CD-instantie per host draaien blijft prima, maar een centrale instantie kan nu naar externe Docker-hosts uitrollen. Wat Doco CD nog steeds mist, is de vlootinterface van Komodo en een centrale hostinventaris.

Het RAM- en CPU-verbruik is niet in cijfers gedocumenteerd. De officiële documentatie noemt de eisen "piepklein" maar publiceert geen referentiewaarden. Bemeet de VPS op de applicaties die erop draaien, houd operationele ruimte over en meet het werkelijke verbruik van Doco CD in je eigen omgeving.

Praktische tip over multi-host. Gebruik per host een eigen Docker-context en eigen deploydoel, beperk de SSH-toegang en houd webhook- of API-secrets uniek. Werk je liever met geïsoleerde agents, dan blijft één Doco CD-instantie per host prima.

Doco CD tegenover de alternatieven

De vier andere tools die ik op de shortlist zou zetten, proberen allemaal "Compose automatisch uitrollen vanuit Git" op te lossen, maar met heel verschillende afwegingen. De vraag is niet óf je dit doet, dat heb je al besloten. De vraag is welke vorm van tool bij jouw opzet past. Hier het overzicht naast elkaar.

Kort over elk, want de tabel geeft de vorm en het commentaar het waarom:

Komodo. Het serieuze multi-hostalternatief. Een centrale Core-service plus een Periphery-agent op elke host, één UI die ze allemaal ziet, Git-gestuurde builds naast deployments en ondersteuning voor Docker Swarm. Zwaarder op te zetten, want je draait een database en een control plane, maar het is de juiste vorm als je een vloot hebt. Komodo past beter zodra centrale vlootcontrole telt.

Portainer (CE of BE) met GitOps. Een volledige grafische UI bovenop Git-synchronisatie. De juiste keuze als het team containerbeheer met de muis wil naast CD. Als er toch iemand in de UI zit om logs te bekijken en containers te herstarten, kan CD er net zo goed bij. Zwaardere resourcevoetafdruk dan Doco CD. OIDC/SSO en fijnmazige RBAC zitten achter de betaalmuur van de Business Edition. Onze gids met Portainer-alternatieven behandelt het bredere landschap van Dockerbeheer.

Dokploy. PaaS-stijl. Uitgesproken in zijn keuzes, rolt automatisch uit bij een push, heeft voor alles een web-UI en zet Traefik met nette URL's meteen voor je klaar. Beter voor teams die een Heroku-gevoel willen en daarvoor de rauwe flexibiliteit van Compose willen inruilen. Ben je allergisch voor YAML, dan is dit de lichtste weg naar "git push en de app staat live".

GitHub Actions + SSH. Nul extra infrastructuur. De deployjob woont in de workflow die je al hebt. Je krijgt workflow-logs, maar geen Compose-native reconciliatie, geen driftherstel en geen blijvend beeld van de hoststaat, tenzij je die stukken zelf bouwt. Prima voor één dienst op één host. Het breekt zodra er een tweede doel bij komt of je wilt weten wat waar draait zonder in te loggen via SSH. Voor het eenvoudigste deel van het publiek is GitHub Actions + SSH nog steeds het juiste antwoord.

Er is een nieuwere kandidaat die stackd heet , dat zich in vergelijkbare bewoordingen presenteert: "GitOps zonder de Kubernetes-belasting". Goed om te weten dat de categorie leeft, maar niet goed genoeg om er vandaag met kop of munt Doco CD voor in te ruilen.

LEES

Coolify vs Dokploy: Een grondige vergelijking voor zelf-gehoste PaaS op een VPS

Wanneer Doco CD de juiste keuze is (en wanneer niet)

Kies Doco CD wanneer:

• Je draait één of enkele Docker Compose-hosts en wilt Git als bron van waarheid.
• Je bewerkt liever YAML in je editor dan dat je door een UI klikt.
• Je wilt ondersteuning voor externe secret-providers en SOPS-gebaseerde versleuteling zonder de hele flow zelf te bouwen.
• Je hebt geen bezwaar tegen een project met één maintainer, van vóór 1.0, dat wel actief wordt ontwikkeld.

Komodo. Kies het wanneer je veel hosts beheert en centrale vlootcontrole wilt, of wanneer je Git-gestuurde builds nodig hebt en niet alleen deployments, onder één dak.

Portainer (CE of BE). Kies het wanneer het team naast CD een UI wil voor dagelijkse containeroperaties, wanneer die visuele laag de echte reden is dat je de tool overweegt.

Dokploy. Kies het wanneer je een deployervaring in PaaS-stijl wilt en de rauwe Compose-controle niet nodig hebt.

GitHub Actions + SSH. Blijf hierbij wanneer het om één dienst op één host gaat en je geen reconciliatie of driftherstel nodig hebt.

Voor wie in dat tussengebied zit, na Watchtower en vóór Kubernetes, is Doco CD een sterke lichte keuze. Mijn inschatting: voor een nieuw homelab of kleine SaaS zou ik met Doco CD beginnen zolang Git-first en zonder UI past, en overstappen op Komodo zodra centrale inventarisatie, rechten en zicht op de vloot eisen worden.

Welke tool je ook kiest, draai hem op een Linux VPS die is afgestemd op de Compose-workloads die erop komen. Cloudzy's Linux VPS is hiervoor een prima plek, met standaard root-toegang. Wil je de apt-dans overslaan, dan kun je ook Docker met één klik uitrollen vanuit onze marketplace.

Onze marketplace heeft ook één-klik-images voor Gitea, waarmee Doco CD native integreert. Er zijn ook images voor Komodo en voor Portainer, mocht je besluiten dat een van die twee beter bij je past.

Veelgestelde vragen

Is Doco CD klaar voor productie?

Doco CD kan in productie, als het risicoprofiel bij je workload past. Het wordt actief ontwikkeld, maar gebruikt nog versienummers van vóór 1.0 en het CODEOWNERS-bestand wijst het project aan één persoon toe. Pin een geteste release vast, test upgrades vóór de uitrol en denk bij kritieke infrastructuur na over bredere governance.

Hoe beheer ik meerdere hosts met Doco CD?

Gebruik voor elke host een eigen Docker-context en eigen deploydoel. Eén Doco CD-instantie kan via SSH of TCP naar meerdere externe Docker-hosts uitrollen; één instantie per host blijft een optioneel isolatiemodel. Kies Komodo als je centrale inventarisatie, rechten en zicht op de hele vloot nodig hebt.

Wat is het verschil tussen webhook- en pollingmodus?

De webhookmodus rolt bijna direct uit zodra er naar Git wordt gepusht, maar vereist een vanaf internet bereikbare poort of een reverse proxy vóór Doco CD. De pollingmodus controleert de repo volgens een schema, dus deployments lopen iets achter, maar er hoeft geen poort open. Polling is de eenvoudigere standaard; webhooks zijn de moeite waard als je vaak pusht of snelle feedback nodig hebt.

Hoe verhoudt Doco CD zich tot Komodo?

Doco CD is lichter en zonder UI, en het kan meerdere hosts beheren via externe Docker-contexten. Komodo gebruikt een centrale Core-service plus Periphery-agents en voegt een vloot-UI en Git-gestuurde builds toe. Neem Doco CD voor Compose-deployments zonder UI, en Komodo wanneer centrale vlootcontrole telt.

Kan Doco CD Watchtower vervangen?

Voor het gebruik dat de meeste Watchtower-gebruikers eigenlijk wilden, "rol uit wat er in Git staat, zodra Git verandert", is het antwoord ja: dat is precies wat Doco CD doet. Voor Watchtowers letterlijke model, een registry pollen en pullen zodra er een nieuwe image-tag verschijnt, is het antwoord nee: Doco CD wordt getriggerd door Git, niet door de registry. Het Git-gedreven model is de veiligere en beter controleerbare keuze voor alles voorbij speelgoeddiensten.