Doco CD anmeldelse: GitOps til Docker Compose uden Kubernetes-overhead

Hvert push følger samme ritual: log ind via SSH, hent repoet, få Compose-stakken op at køre igen, håb at intet gik i stykker, og prøv at huske, om du kørte migreringen. Den manuelle løkke fungerer, indtil du får brug for gentagelige udrulninger, et klart overblik over hvad der kører, eller genopretning efter drift.

Doco CD er ét direkte svar. Det er en lille Go-tjeneste, der holder øje med dit Git-repo og anvender Compose-ændringer, når du pusher: webhook eller polling, dit valg. ArgoCD og Flux gør det samme for Kubernetes, men Doco CD springer Kubernetes over, fordi det ikke har brug for et control plane.

Denne anmeldelse dækker, hvad Doco CD gør, hvad det ikke gør, og hvordan det klarer sig mod Komodo, Portainers GitOps-tilstand, Dokploy og et helt almindeligt GitHub Actions + SSH-script. Til sidst ved du, om det passer til din opsætning, og hvad du ellers skal vælge.

TL;DR

• Doco CD er en lillebitte, Compose-native GitOps-agent: den holder øje med et Git-repo (GitHub, GitLab, Gitea, Forgejo med flere) og bringer din stak i overensstemmelse, når noget ændrer sig.
• Indbygget understøttelse af eksterne secret-udbydere plus SOPS-baseret kryptering er det, der adskiller det fra et hjemmestrikket deploy-script.
• Ifølge sin egen README positionerer det sig som "et simpelt alternativ til Portainer eller ArgoCD til Docker". Den ramme rammer nogenlunde plet.
• De reelle begrænsninger: én kodeejer, versionering før 1.0, ingen brugerflade til flådestyring og en afstemningstilstand, der først genopbygges ved næste poll eller webhook-hændelse.
• Vælg det, når du kører én eller nogle få Compose-værter og vil have Git som kilden til sandhed uden en brugerflade. Vælg Komodo til en flåde, Portainer hvis du vil have en brugerflade, Dokploy for en PaaS-fornemmelse, eller GitHub Actions + SSH når det virkelig er én tjeneste på én vært.

Hullet som Doco CD forsøger at udfylde

Der findes et mærkeligt mellemland for enhver, der kører Docker Compose i 2026. Store GitOps-værktøjer som Argo CD og Flux sigter mod Kubernetes, mens Watchtowers registry-polling reagerer på image-ændringer i stedet for at anvende en versioneret Compose-tilstand. Watchtowers repository blev arkiveret den 17. december 2025 og oplyser nu, at projektet ikke længere vedligeholdes.

GitHub Actions plus et SSH-udrulningstrin virker. Til én tjeneste på én vært er det det rigtige valg. Problemerne dukker op, når du tilføjer vært nummer to eller stak nummer to, eller når du vil vide, hvilken commit der er udrullet lige nu. Du har stadig workflow-logs, men ingen Compose-native afstemning, ingen genopretning efter drift og intet vedvarende overblik over, om værten stadig matcher repoet.

Doco CD's pitch, direkte fra README, er "et simpelt alternativ til Portainer eller ArgoCD til Docker". Netop den ramme er pointen: lille, Compose-native, ingen Kubernetes, ingen brugerflade at vedligeholde, intet centralt control plane at passe på. Kører du ikke K8s og ville du heller ikke, så er det her kategorien, du har ledt efter.

Sådan fungerer Doco CD i praksis

Doco CD er én enkelt Go-binær, der kører i en Docker-container, holder øje med et Git-repository og anvender Compose-ændringer, når repoets tilstand ændrer sig. Det er hele konceptet. Det interessante ligger i standardværdierne og integrationerne.

Udløsere. To tilstande: webhook eller polling. Webhook er næsten øjeblikkelig, men kræver en åben port, eller mere realistisk en reverse proxy foran Doco CD. Polling er periodisk hentning: lidt forsinket, ingen indgående port nødvendig. Polling er den enklere standard, og ifølge den officielle dokumentation er begge fuldgyldige. Vælg ud fra, om din vært har et offentligt tilgængeligt endepunkt, og hvor hurtigt du har brug for udrulninger.

Konfiguration pr. repo. En .doco-cd.yaml-fil (eller .doco-cd.yml) ligger i roden af repoet ved siden af din Compose-fil. Det eneste påkrævede felt er navnet på udrulningen. En minimal konfiguration ser sådan ud:

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

Det er de dokumenterede standardværdier: en timeout på 180 sekunder, forældreløse containere fjernes, images ryddes op, og ingen tvungen genskabelse.

Automatisk registrering. Med automatisk registrering slået til gennemsøger Doco CD undermapper for Compose-filer, så ét repo kan rumme flere stakke. Det understøtter også flere udrulningskonfigurationer i én fil, skrevet som YAML-dokumenter adskilt af en linje med tre bindestreger. Standardværdierne for oprydning er forsigtige og værd at læse, før du læner dig op ad dem:

Med andre ord bliver intet revet ned bag din ryg, før du selv slår sletning til, og selv da forsvinder dine datavolumener sidst.

Understøttede Git-udbydere. GitHub, GitLab, Gitea, Forgejo, Gogs og Azure DevOps understøttes. Azure DevOps er undtagelsen ved webhooks, fordi Azure Service Hooks ikke understøttes. Understøttelsen af Gitea og Forgejo betyder noget, hvis du selv hoster din forge.

Docker Swarm. Understøttes som mål. Det, siden med udrulningsindstillinger udtrykkeligt gør opmærksom på, er: afstemning i Swarm-tilstand kontrollerer hverken containergenstarter eller sundhedsstatus, og oprydning i images understøttes ikke i Swarm. Er Swarm dit mål, får du udrulninger, men ikke fuld sundhedsafstemning.

Afstemning. Som standard gælder en grænse på 5 genstarter inden for et vindue på 300 sekunder, som skal forhindre ustabile health checks i at køre i ring i det uendelige. Samme repo med en anden ref kører sekventielt, samme repo med samme ref kører parallelt. Det sidste er en detalje, men en nyttig en: flere udrulninger af samme ref stiller sig ikke i kø efter hinanden.

Indbyggede eksterne secret-udbydere. Det er en af de stærkere grunde til at overveje Doco CD frem for et almindeligt deploy-script: det understøtter AWS Secrets Manager, Bitwarden Secrets Manager, Bitwarden Vault / Vaultwarden, 1Password, 1Password Connect, Infisical, OpenBao og Webhook. Derudover understøtter det SOPS-baseret kryptering af følsomme udrulningsdata. Det giver dig en ren vej væk fra env-filer i klartekst i Git, uden at du selv skal bygge hele flowet til opslag af hemmeligheder.

Resten. Doco CD leverer Prometheus-metrikker, jobplanlægning, notifikationer, et distroless container-image og en Apache-2.0-licens. Ifølge dets udgivelseshistorik er v0.109.2 pr. 20. august 2026 den nyeste stabile udgivelse, og v0.110.0-rc.1 er den nyeste forhåndsudgivelse.

Doco CD's opgave stopper ved "anvend manifestet"; derfra er det helt almindelig Docker. Composes egne log-kommandoer er det, du bruger til at se, hvad der kører.

Praktisk tip om hemmeligheder. Ligger der stadig env-filer i klartekst i dit private repo, så prioriter Doco CD's eksterne secret-udbydere eller dets SOPS-understøttelse. Målet er enkelt: få klartekst-hemmeligheder ud af Git, og lad alligevel udrulningerne slå værdierne op ved kørsel.

Hvor Doco CD kommer til kort

Alle værktøjer har begrænsninger, og Doco CD's er værd at kende, før du bruger en weekend på at sætte det op.

Én kodeejer. Repositoryets CODEOWNERS-fil tildeler alle stier til kimdre. Der udkommer stadig udgivelser ofte, men styringen er samlet hos én person.

Før 1.0. Doco CD bruger stadig 0.x-versionering, så fastlås en testet udgivelse og læs opgraderingsnoterne før udrulning. Den lukkede GitHub-issue #851 viser hvorfor: Docker v29 tvang projektet til at forlade forældede Docker Go-moduler.

Ingen shell inde i Doco CD-containeren. Af sikkerhedshensyn giver Doco CD ikke et shell-miljø og kører ikke vilkårlige scripts på værten. Opgaver før og efter udrulning skal gå gennem init-containere, sidecars eller Compose-livscyklushooks, hvilket kræver mere konfiguration end værktøjer, der bare kører et deploy-script.

Tab af tilstand ved genstart. Afstemningstilstanden ligger i hukommelsen. Når Doco CD genstarter, genopbygges den først ved næste poll eller webhook-hændelse, så hullets længde afhænger af dit pollinginterval, eller hvor hurtigt den næste webhook kommer.

Ingen brugerflade til flådestyring. Multi-vært kræver ikke længere én agent pr. vært. Siden v0.102.0 kan udrulningskonfigurationer pege på fjerne Docker-kontekster, inklusive SSH-kontekster, og ét repository kan definere flere udrulningsmål. Det er stadig gyldigt at køre én Doco CD-instans pr. vært, men en central instans kan nu udrulle til fjerne Docker-værter. Det, Doco CD stadig mangler, er Komodos flådebrugerflade og et centraliseret overblik over værterne.

RAM- og CPU-forbruget er ikke dokumenteret i tal. Den officielle dokumentation beskriver kravene som "minimale", men offentliggør ingen udgangsværdier. Dimensioner din VPS efter de applikationer, den skal køre, hold operationel luft, og mål Doco CD's faktiske forbrug i dit eget miljø.

Praktisk tip om multi-vært. Brug en separat Docker-kontekst og et separat udrulningsmål pr. vært, begræns SSH-adgangen, og hold webhook- eller API-hemmeligheder unikke. Foretrækker du isolerede agenter, er én Doco CD-instans pr. vært stadig en gyldig løsning.

Doco CD over for alternativerne

De fire andre værktøjer, jeg ville sætte på listen, forsøger alle at løse "udrul Compose automatisk fra Git", men med meget forskellige afvejninger. Spørgsmålet er ikke, om du skal gøre det; det har du allerede besluttet. Spørgsmålet er, hvilken form for værktøj der passer til din opsætning. Her er sammenligningen side om side.

Kort om hver enkelt, for tabellen giver formen, og kommentaren giver hvorfor:

Komodo. Det seriøse multi-vært-alternativ. En central Core-tjeneste plus en Periphery-agent på hver vært, én brugerflade der ser dem alle, Git-drevne builds ud over udrulninger, og understøttelse af Docker Swarm. Tungere at sætte op, for du kører en database og et control plane, men det er den rigtige form, hvis du har en flåde. Komodo passer bedre, når central flådestyring betyder noget.

Portainer (CE eller BE) med GitOps. En fuld grafisk brugerflade oven på Git-synkronisering. Det rigtige valg, når teamet vil have klik-og-styr containerhåndtering ved siden af CD. Når nogen alligevel sidder i brugerfladen og læser logs og genstarter containere, kan CD lige så godt bo samme sted. Tungere ressourceforbrug end Doco CD. OIDC/SSO og finkornet RBAC ligger bag betalingsmuren i Business Edition. Vores guide til Portainer-alternativer dækker det bredere landskab for Docker-håndtering.

Dokploy. PaaS-stil. Meningsstærkt, udruller automatisk ved push, har en webbrugerflade til alt og sætter Traefik og pæne URL'er op fra start. Bedre til teams, der vil have en Heroku-fornemmelse og gerne bytter Composes rå fleksibilitet væk for det. Er du allergisk over for YAML, er det her den letteste vej til "git push, og appen er udrullet".

GitHub Actions + SSH. Nul ekstra infrastruktur. Deploy-jobbet bor i det workflow, du allerede har. Du får workflow-logs, men ingen Compose-native afstemning, ingen genopretning efter drift og intet vedvarende billede af værtstilstanden, medmindre du selv bygger de dele. Fint til én tjeneste på én vært. Det knækker, så snart du tilføjer et mål nummer to eller vil vide, hvad der kører hvor, uden at logge ind via SSH. For den enkleste del af publikum er GitHub Actions + SSH stadig det rigtige svar.

Der er en nyere spiller ved navn stackd , som beskriver sig selv i lignende vendinger: "GitOps uden Kubernetes-skatten". Værd at vide, at kategorien lever, men ikke værd at vælge frem for Doco CD på et møntkast i dag.

LÆS

Coolify vs Dokploy: En grundig sammenligning af selvhostet PaaS på en VPS

Hvornår Doco CD er det rigtige valg (og hvornår ikke)

Vælg Doco CD, når:

• Du kører én eller nogle få Docker Compose-værter og vil have Git som kilden til sandhed.
• Du vil hellere redigere YAML i din editor end at klikke dig gennem en brugerflade.
• Du vil have understøttelse af eksterne secret-udbydere og SOPS-baseret kryptering uden selv at bygge hele flowet.
• Du er okay med et projekt med én vedligeholder, før 1.0, men aktivt udviklet.

Komodo. Vælg det, når du styrer mange værter og vil have central flådekontrol, eller når du har brug for Git-drevne builds og ikke bare udrulninger under samme tag.

Portainer (CE eller BE). Vælg det, når teamet vil have en brugerflade til daglig containerdrift ved siden af CD, altså når det visuelle lag er den egentlige grund til, at du overvejer værktøjet.

Dokploy. Vælg det, når du vil have en deploy-oplevelse i PaaS-stil og ikke har brug for rå Compose-kontrol.

GitHub Actions + SSH. Bliv ved det, når det er én tjeneste på én vært, og du ikke har brug for afstemning eller genopretning efter drift.

For folk i det mellemland efter Watchtower og før Kubernetes er Doco CD et stærkt, let valg. Min vurdering: til et nyt homelab eller et lille SaaS ville jeg starte med Doco CD, så længe Git-først og uden brugerflade passer, og skifte til Komodo, så snart centralt overblik, rettigheder og flådesynlighed bliver krav.

Uanset hvilket værktøj du vælger, så kør det på en Linux VPS, der er dimensioneret til de Compose-arbejdsbelastninger, den skal huse. Cloudzy's Linux VPS er et fornuftigt hjem til dette, med root-adgang som standard. Vil du springe apt-dansen over, kan du også udrulle Docker med ét klik fra vores marketplace.

Vores marketplace har også ét-klik-images til Gitea, som Doco CD integrerer med indbygget. Der er også images til Komodo og til Portainer, hvis du beslutter, at en af dem passer bedre til det, du er ude efter.

Ofte stillede spørgsmål

Er Doco CD klar til produktion?

Doco CD kan bruges i produktion, hvis dets risikoprofil passer til din arbejdsbyrde. Det udvikles aktivt, men bruger stadig versionering før 1.0, og dets CODEOWNERS-fil tildeler projektet til én person. Fastlås en testet udgivelse, test opgraderinger før udrulning, og overvej bredere styring, hvis der er tale om kritisk infrastruktur.

Hvordan styrer jeg flere værter med Doco CD?

Brug en separat Docker-kontekst og et separat udrulningsmål for hver vært. Én Doco CD-instans kan udrulle til flere fjerne Docker-værter over SSH eller TCP; én instans pr. vært er stadig en valgfri isolationsmodel. Vælg Komodo, hvis du har brug for centralt overblik, rettigheder og flådesynlighed.

Hvad er forskellen på webhook- og polling-tilstand?

Webhook-tilstand udruller næsten øjeblikkeligt, når der pushes til Git, men kræver en port, der kan nås fra internettet, eller en reverse proxy foran Doco CD. Polling-tilstand tjekker repoet efter en tidsplan, så udrulninger er lidt forsinkede, men ingen port skal eksponeres. Polling er den enklere standard; webhooks er indsatsen værd, når du pusher ofte eller har brug for hurtige tilbagemeldinger.

Hvordan klarer Doco CD sig mod Komodo?

Doco CD er lettere og uden brugerflade, og det kan styre flere værter via fjerne Docker-kontekster. Komodo bruger en central Core-tjeneste plus Periphery-agenter og lægger en flådebrugerflade og Git-drevne builds oveni. Vælg Doco CD til Compose-udrulning uden brugerflade; vælg Komodo, når central flådestyring betyder noget.

Kan Doco CD erstatte Watchtower?

Til det formål, de fleste Watchtower-brugere i virkeligheden ville have, altså "udrul det, der ligger i Git, når Git ændrer sig", er svaret ja: det er præcis, hvad Doco CD gør. Til Watchtowers bogstavelige model, altså at polle et registry og hente, når et nyt image-tag dukker op, er svaret nej; Doco CD udløses af Git, ikke af registryet. Den Git-udløste model er det sikrere og mere reviderbare valg til alt ud over legetøjstjenester.