Test de Doco CD : le GitOps pour Docker Compose sans la lourdeur de Kubernetes

À chaque push, le même rituel : connexion SSH, récupération du dépôt, redémarrage de la stack Compose, en espérant que rien n'a cassé, et en essayant de se rappeler si la migration a bien été lancée. Cette boucle manuelle tient jusqu'au jour où il vous faut des déploiements reproductibles, une trace claire de ce qui tourne, ou un moyen de corriger la dérive.

Doco CD est une réponse directe. C'est un petit service en Go qui surveille votre dépôt Git et applique les changements Compose à chaque push : webhook ou polling, à vous de choisir. ArgoCD et Flux font la même chose pour Kubernetes, mais Doco CD s'en passe, puisqu'il n'a besoin d'aucun plan de contrôle.

Ce test couvre ce que fait Doco CD, ce qu'il ne fait pas, et comment il se compare à Komodo, au mode GitOps de Portainer, à Dokploy et à un simple script GitHub Actions + SSH. À la fin, vous saurez s'il convient à votre installation et quoi choisir dans le cas contraire.

En bref

• Doco CD est un agent GitOps minuscule et natif Compose : il surveille un dépôt Git (GitHub, GitLab, Gitea, Forgejo et d'autres) et réconcilie votre stack dès que quelque chose change.
• La prise en charge intégrée de fournisseurs de secrets externes, doublée du chiffrement basé sur SOPS, fait toute la différence face à un script de déploiement maison.
• Il se présente, selon son README, comme « une alternative simple à Portainer ou ArgoCD pour Docker ». Le cadrage est à peu près juste.
• Les vraies limites : un seul propriétaire du code, un versionnage antérieur à la 1.0, aucune interface de gestion de parc, et un état de réconciliation reconstruit seulement au prochain sondage ou événement webhook.
• Choisissez-le si vous gérez un ou quelques hôtes Compose et voulez faire de Git la source de vérité, sans interface. Prenez Komodo pour un parc de machines, Portainer si vous voulez une interface, Dokploy pour une expérience PaaS, ou GitHub Actions + SSH quand il s'agit vraiment d'un seul service sur un seul hôte.

Le vide que Doco CD cherche à combler

Il existe un entre-deux étrange pour quiconque fait tourner Docker Compose en 2026. Les grands outils GitOps comme Argo CD et Flux visent Kubernetes, tandis que le modèle de Watchtower, basé sur l'interrogation du registre, réagit aux changements d'image au lieu d'appliquer un état Compose versionné. Le dépôt a été archivé le 17 décembre 2025 et indique désormais que le projet n'est plus maintenu.

GitHub Actions avec une étape de déploiement SSH fonctionne. Pour un service sur un hôte, c'est le bon choix. Les ennuis commencent quand vous ajoutez un deuxième hôte, ou une deuxième stack, ou que vous voulez savoir quel commit est actuellement déployé. Vous gardez les journaux du workflow, mais pas la réconciliation native Compose, ni la correction de dérive, ni une vue persistante indiquant si l'hôte correspond encore au dépôt.

L'argumentaire de Doco CD, directement tiré du README, est « une alternative simple à Portainer ou ArgoCD pour Docker ». Ce cadrage est tout l'intérêt : petit, natif Compose, pas de Kubernetes, pas d'interface à maintenir, pas de plan de contrôle central à surveiller. Si vous ne faites pas tourner K8s et que vous n'en aviez pas envie, voilà exactement la catégorie que vous cherchiez.

Comment Doco CD fonctionne réellement

Doco CD est un unique binaire Go qui tourne dans un conteneur Docker, surveille un dépôt Git et applique les changements Compose dès que l'état du dépôt évolue. Voilà tout le concept. L'intéressant se joue dans les valeurs par défaut et les intégrations.

Déclencheurs. Deux modes : webhook ou sondage. Le webhook est quasi instantané mais réclame un port exposé, ou plus réalistement un reverse proxy devant Doco CD. Le sondage est une récupération périodique : légèrement décalée, sans aucun port entrant. Le sondage est la valeur par défaut la plus simple, et selon la documentation officielle , les deux sont traités sur un pied d'égalité. Choisissez selon que votre hôte dispose d'un point d'entrée public accessible et selon la rapidité de déploiement dont vous avez besoin.

Configuration par dépôt. Un fichier .doco-cd.yaml (ou .doco-cd.yml) se place à la racine du dépôt, à côté de votre fichier Compose. Le seul champ obligatoire est le nom du déploiement. Voici à quoi ressemble une configuration minimale :

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

Ce sont les valeurs par défaut documentées : un délai de 180 secondes, les conteneurs orphelins supprimés, les images élaguées, et pas de recréation forcée.

Découverte automatique. Quand la découverte automatique est activée, Doco CD parcourt les sous-dossiers à la recherche de fichiers Compose : un même dépôt peut donc héberger plusieurs stacks. Il gère aussi plusieurs configurations de déploiement dans un seul fichier, écrites sous forme de documents YAML séparés par une ligne de trois tirets. Les valeurs de nettoyage par défaut sont prudentes, et méritent une lecture avant que vous ne comptiez dessus :

Autrement dit, rien n'est démoli dans votre dos tant que vous n'avez pas activé la suppression, et même alors, vos volumes de données sont les derniers à partir.

Fournisseurs Git pris en charge. GitHub, GitLab, Gitea, Forgejo, Gogs et Azure DevOps sont pris en charge. Azure DevOps fait exception pour les webhooks, car les Azure Service Hooks ne sont pas supportés. La prise en charge de Gitea et Forgejo compte si vous hébergez vous-même votre forge.

Docker Swarm. Pris en charge comme cible. Ce que la page des paramètres de déploiement signale explicitement : en mode Swarm, la réconciliation ne vérifie ni les redémarrages de conteneurs ni l'état de santé, et l'élagage des images n'est pas pris en charge. Si Swarm est votre cible, vous obtenez des déploiements, mais pas une réconciliation complète de l'état de santé.

Réconciliation. Par défaut, une limite de 5 redémarrages sur une fenêtre de 300 secondes, prévue pour empêcher des contrôles de santé instables de boucler indéfiniment. Même dépôt avec une référence différente : exécution séquentielle ; même dépôt avec la même référence : exécution en parallèle. Ce dernier point est subtil mais utile : plusieurs déploiements de la même référence ne font pas la queue les uns derrière les autres.

Fournisseurs de secrets externes intégrés. C'est l'une des meilleures raisons de préférer Doco CD à un simple script de déploiement : il prend en charge AWS Secrets Manager, Bitwarden Secrets Manager, Bitwarden Vault / Vaultwarden, 1Password, 1Password Connect, Infisical, OpenBao et Webhook. En complément, il gère le chiffrement basé sur SOPS pour les données de déploiement sensibles. Vous obtenez ainsi une sortie propre des fichiers env en clair dans Git, sans avoir à construire vous-même toute la chaîne de résolution des secrets.

Le reste. Doco CD fournit des métriques Prometheus, la planification de tâches, des notifications, une image de conteneur distroless et une licence Apache-2.0. D'après son historique des versions, au 20 août 2026, la v0.109.2 est la dernière version stable et la v0.110.0-rc.1 la préversion la plus récente.

Le travail de Doco CD s'arrête à « appliquer le manifeste » ; à partir de là, c'est du Docker classique. Les commandes de journaux de Compose sont ce qui vous servira à inspecter ce qui tourne.

Conseil de pro sur les secrets. Si votre dépôt privé contient encore des fichiers env en clair, donnez la priorité aux fournisseurs de secrets externes de Doco CD ou à son support de SOPS. L'objectif est simple : sortir les secrets en clair de Git tout en laissant les déploiements résoudre les valeurs à l'exécution.

Là où Doco CD montre ses limites

Tout outil a ses limites, et celles de Doco CD méritent d'être connues avant de consacrer un week-end à sa mise en place.

Un seul propriétaire du code. Le fichier CODEOWNERS du dépôt attribue tous les chemins à kimdre. Les publications restent fréquentes, mais la gouvernance est concentrée sur une seule personne.

Avant la 1.0. Doco CD utilise encore un versionnage 0.x : épinglez une version testée et lisez les notes de mise à niveau avant tout déploiement. Le ticket GitHub #851 , désormais clos, illustre pourquoi : Docker v29 a contraint le projet à abandonner des modules Go Docker dépréciés.

Pas de shell dans le conteneur Doco CD. Pour des raisons de sécurité, Doco CD ne fournit pas d'environnement shell et n'exécute pas de scripts arbitraires sur l'hôte. Les tâches avant et après déploiement doivent passer par des conteneurs d'initialisation, des sidecars ou les hooks de cycle de vie de Compose, ce qui ajoute de la configuration face aux outils qui lancent directement un script de déploiement.

Perte d'état au redémarrage. L'état de réconciliation vit en mémoire. Quand Doco CD redémarre, cet état n'est reconstruit qu'au prochain sondage ou événement webhook : la durée du trou dépend donc de votre intervalle de sondage ou du délai avant le webhook suivant.

Pas d'interface de gestion de parc. Le multi-hôte n'exige plus un agent par machine. Depuis la v0.102.0, les configurations de déploiement peuvent viser des contextes Docker distants, contextes SSH compris, et un même dépôt peut définir plusieurs cibles de déploiement. Faire tourner une instance de Doco CD par hôte reste valable, mais une instance centrale peut désormais déployer vers des hôtes Docker distants. Ce qui manque encore à Doco CD, c'est l'interface de gestion de parc de Komodo et son inventaire centralisé des hôtes.

L'empreinte RAM et CPU n'est pas documentée en chiffres. La documentation officielle qualifie les besoins de « minuscules » sans publier de référence chiffrée. Dimensionnez le VPS pour les applications qu'il hébergera, gardez une marge d'exploitation, et mesurez la consommation réelle de Doco CD dans votre propre environnement.

Conseil de pro sur le multi-hôte. Utilisez un contexte Docker et une cible de déploiement distincts par machine, restreignez l'accès SSH, et gardez des secrets webhook ou API uniques. Si vous préférez des agents isolés, une instance de Doco CD par hôte reste tout à fait valable.

Doco CD face aux alternatives

Les quatre autres outils que je retiendrais cherchent tous à résoudre « déployer automatiquement Compose depuis Git », mais avec des compromis très différents. La question n'est pas de savoir s'il faut le faire : vous avez déjà tranché. La question est de savoir quelle forme d'outil convient à votre installation. Voici le face-à-face.

Un mot sur chacun, car le tableau donne la forme et le commentaire donne la raison :

Komodo. L'alternative sérieuse pour le multi-hôte. Un service Core central plus un agent Periphery sur chaque machine, une interface unique qui les voit toutes, des builds pilotés par Git en plus des déploiements, et la prise en charge de Docker Swarm. Sa mise en place est plus lourde, puisque vous faites tourner une base de données et un plan de contrôle, mais c'est la bonne forme quand vous gérez un parc. Komodo l'emporte dès que le contrôle centralisé du parc compte vraiment.

Portainer (CE ou BE) avec GitOps. Une interface graphique complète posée sur la synchronisation Git. Le bon choix quand l'équipe veut gérer ses conteneurs au clic en même temps que le CD. Si quelqu'un va de toute façon passer par l'interface pour lire des journaux et redémarrer des conteneurs, autant y avoir aussi le CD. L'empreinte en ressources est plus lourde que celle de Doco CD. OIDC/SSO et le RBAC fin sont réservés à la Business Edition payante. Notre guide des alternatives à Portainer couvre le paysage plus large de la gestion Docker.

Dokploy. Style PaaS. Un outil qui a des avis tranchés, déploie automatiquement au push, offre une interface web pour tout, et vous installe Traefik avec des URL propres dès le départ. Il convient mieux aux équipes qui veulent une sensation à la Heroku et acceptent de sacrifier la souplesse brute de Compose. Si vous êtes allergique au YAML, c'est le chemin le plus léger vers « je pousse, l'application se déploie ».

GitHub Actions + SSH. Zéro infrastructure supplémentaire. Le job de déploiement vit dans le workflow que vous avez déjà. Vous obtenez les journaux du workflow, mais aucune réconciliation native Compose, aucune correction de dérive et aucune vue persistante de l'état des hôtes, sauf à construire ces briques vous-même. Parfait pour un service sur un hôte. Cela craque dès que vous ajoutez une deuxième cible ou que vous voulez savoir ce qui tourne où sans vous connecter en SSH. Pour la frange la plus simple des lecteurs, GitHub Actions + SSH reste la bonne réponse.

Un nouveau venu répond au nom de stackd , qui se présente dans des termes voisins : « le GitOps sans l'impôt Kubernetes ». Il vaut la peine de savoir que la catégorie est vivante, pas de le choisir à pile ou face face à Doco CD aujourd'hui.

LIRE

Coolify vs Dokploy : une comparaison approfondie des PaaS auto-hébergés sur un VPS

Quand Doco CD est le bon choix (et quand il ne l'est pas)

Choisissez Doco CD quand :

• Vous gérez un ou quelques hôtes Docker Compose et voulez faire de Git la source de vérité.
• Vous préférez éditer du YAML dans votre éditeur plutôt que cliquer dans une interface.
• Vous voulez la prise en charge de fournisseurs de secrets externes et du chiffrement SOPS sans construire toute la chaîne vous-même.
• Un projet à mainteneur unique, antérieur à la 1.0 mais activement développé, ne vous dérange pas.

Komodo. Choisissez-le quand vous gérez de nombreuses machines et voulez un contrôle centralisé du parc, ou quand il vous faut des builds pilotés par Git, et pas seulement des déploiements, sous un même toit.

Portainer (CE ou BE). Choisissez-le quand l'équipe veut une interface pour l'exploitation quotidienne des conteneurs en plus du CD, quand la couche visuelle est la vraie raison pour laquelle vous envisagez l'outil.

Dokploy. Choisissez-le quand vous voulez une expérience de déploiement façon PaaS et n'avez pas besoin du contrôle brut de Compose.

GitHub Actions + SSH. Restez dessus quand il s'agit d'un service, d'un hôte, et que vous n'avez besoin ni de réconciliation ni de correction de dérive.

Pour ceux qui se trouvent dans l'entre-deux de l'après-Watchtower et de l'avant-Kubernetes, Doco CD est un choix léger et solide. Mon avis : pour un nouveau homelab ou un petit SaaS, je commencerais par Doco CD quand un fonctionnement Git d'abord et sans interface convient, puis je passerais à Komodo dès que l'inventaire centralisé, les permissions et la visibilité sur le parc deviennent des exigences.

Quel que soit l'outil retenu, faites-le tourner sur un VPS Linux dimensionné pour les charges Compose qu'il hébergera. Le VPS Linux de Cloudzy est un hébergement raisonnable pour cela, avec un accès root par défaut. Et si vous voulez éviter la valse des paquets apt, vous pouvez aussi déployer Docker en un clic depuis notre marketplace.

Notre marketplace propose aussi des images en un clic pour Gitea, avec lequel Doco CD s'intègre nativement. Il y a aussi des images pour Komodo également, ainsi que pour Portainer, si vous décidez que l'un d'eux correspond mieux à ce que vous cherchez.

Foire aux questions

Doco CD est-il prêt pour la production ?

Doco CD peut servir en production si son profil de risque convient à votre charge de travail. Il est activement développé, mais utilise encore un versionnage antérieur à la 1.0, et son fichier CODEOWNERS attribue le projet à une seule personne. Épinglez une version testée, testez les mises à niveau avant de les déployer, et envisagez une gouvernance plus large pour une infrastructure critique.

Comment gérer plusieurs hôtes avec Doco CD ?

Utilisez un contexte Docker et une cible de déploiement distincts pour chaque machine. Une seule instance de Doco CD peut déployer vers plusieurs hôtes Docker distants via SSH ou TCP ; une instance par hôte reste un modèle d'isolation optionnel. Choisissez Komodo si vous avez besoin d'un inventaire centralisé, de permissions et d'une visibilité sur tout le parc.

Quelle différence entre le mode webhook et le mode sondage ?

Le mode webhook déploie quasi instantanément dès que Git reçoit un push, mais il exige un port accessible depuis Internet, ou un reverse proxy devant Doco CD. Le mode sondage interroge le dépôt selon un calendrier : les déploiements accusent un léger retard, mais aucun port n'a besoin d'être exposé. Le sondage est la valeur par défaut la plus simple ; les webhooks se justifient si vous poussez souvent ou avez besoin de boucles de retour rapides.

Comment Doco CD se compare-t-il à Komodo ?

Doco CD est plus léger et sans interface, et il sait gérer plusieurs hôtes via des contextes Docker distants. Komodo repose sur un service Core central et des agents Periphery, et ajoute une interface de parc ainsi que des builds pilotés par Git. Prenez Doco CD pour un déploiement Compose sans interface ; prenez Komodo dès que le contrôle centralisé du parc compte.

Doco CD peut-il remplacer Watchtower ?

Pour l'usage que visaient la plupart des utilisateurs de Watchtower, « déployer ce qui est dans Git, quand Git change », oui : c'est exactement ce que fait Doco CD. Pour le modèle littéral de Watchtower, interroger un registre et tirer l'image dès qu'un nouveau tag apparaît, non : Doco CD est déclenché par Git, pas par le registre. Le modèle déclenché par Git est le choix le plus sûr et le plus auditable dès qu'on dépasse les services jouets.