Cada push repite el mismo ritual: entrar por SSH, actualizar el repositorio, volver a levantar el stack de Compose, esperar que no se haya roto nada e intentar recordar si ejecutaste la migración. Ese bucle manual funciona hasta que necesitas despliegues repetibles, un registro claro de lo que está corriendo o recuperarte de la deriva.
Doco CD es una respuesta directa. Es un pequeño servicio en Go que vigila tu repositorio Git y aplica los cambios de Compose cuando haces push: webhook o sondeo, tú decides. ArgoCD y Flux hacen esto para Kubernetes, pero Doco CD lo evita, porque no necesita un plano de control.
Este análisis cubre lo que hace Doco CD, lo que no hace y cómo se compara con Komodo, el modo GitOps de Portainer, Dokploy y un simple script de GitHub Actions + SSH. Al final sabrás si encaja en tu configuración y qué elegir si no lo hace.
TL;DR
- Doco CD es un agente GitOps diminuto y nativo de Compose: vigila un repositorio Git (GitHub, GitLab, Gitea, Forgejo y otros) y reconcilia tu stack cuando algo cambia.
- El soporte integrado de proveedores de secretos externos, junto con el cifrado basado en SOPS, es lo que lo diferencia de escribir tu propio script de despliegue.
- Según su README, se presenta como "una alternativa sencilla a Portainer o ArgoCD para Docker". El encuadre es bastante acertado.
- Límites reales: un único responsable del código, versionado anterior a 1.0, sin interfaz de gestión de flota y un estado de reconciliación que solo se reconstruye tras el siguiente sondeo o evento de webhook.
- Elígelo si gestionas uno o unos pocos hosts con Compose y quieres que Git sea la fuente de verdad, sin interfaz. Elige Komodo para flotas, Portainer si quieres una interfaz, Dokploy para una experiencia tipo PaaS, o GitHub Actions + SSH cuando de verdad es un solo servicio en un solo host.
El hueco que Doco CD intenta llenar
Existe un terreno intermedio extraño para quien usa Docker Compose en 2026. Las grandes herramientas GitOps como Argo CD y Flux apuntan a Kubernetes, mientras que el modelo de Watchtower, basado en sondear el registro, reacciona a cambios de imagen en lugar de aplicar un estado Compose versionado. El repositorio fue archivado el 17 de diciembre de 2025 y ahora indica que el proyecto ya no recibe mantenimiento.
GitHub Actions con un paso de despliegue por SSH funciona. Para un servicio en un host es la decisión correcta. El problema aparece cuando añades un segundo host, o un segundo stack, o quieres saber qué commit está desplegado ahora mismo. Sigues teniendo los registros del flujo de trabajo, pero no reconciliación nativa de Compose, ni recuperación de la deriva, ni una vista persistente de si el host sigue coincidiendo con el repositorio.
La propuesta de Doco CD, tomada directamente del README, es "una alternativa sencilla a Portainer o ArgoCD para Docker". Ese encuadre es justo el punto: pequeño, nativo de Compose, sin Kubernetes, sin interfaz que mantener, sin plano de control central que vigilar. Si no usas K8s y tampoco querías hacerlo, esta es la categoría que buscabas.
Cómo funciona realmente Doco CD
Doco CD es un único binario en Go que corre dentro de un contenedor Docker, vigila un repositorio Git y aplica los cambios de Compose cuando el estado del repositorio cambia. Ese es todo el concepto. Lo interesante está en los valores por defecto y en las integraciones.
Disparadores. Dos modos: webhook o sondeo. El webhook es casi instantáneo pero exige un puerto expuesto, o más realistamente un proxy inverso delante de Doco CD. El sondeo es una consulta periódica: algo retrasada, sin necesidad de puertos entrantes. El sondeo es el valor por defecto más sencillo y, según la documentación oficial , ambos son ciudadanos de primera clase. Elige según si tu host tiene un punto de acceso público alcanzable y según la rapidez de despliegue que necesites.
Configuración por repositorio. Un archivo .doco-cd.yaml (o .doco-cd.yml) vive en la raíz del repositorio, junto a tu archivo de Compose. El único campo obligatorio es el nombre del despliegue. Una configuración mínima se ve así:
# .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: falseEsos son los valores por defecto documentados: un tiempo de espera de 180 segundos, huérfanos eliminados, imágenes podadas y sin recreación forzada.
Descubrimiento automático. Con el descubrimiento automático activado, Doco CD recorre los subdirectorios en busca de archivos de Compose, así que un mismo repositorio puede alojar varios stacks. También admite varias configuraciones de despliegue en un solo archivo, escritas como documentos YAML separados por una línea de tres guiones. Los valores de limpieza por defecto son conservadores y conviene leerlos antes de depender de ellos:
| Configuración | Predeterminado | Qué significa |
|---|---|---|
delete | false | Un despliegue obsoleto se deja tal cual cuando su aplicación desaparece del directorio de trabajo. |
remove_volumes | false | Los volúmenes sobreviven cuando se elimina un stack detectado automáticamente. |
remove_images | true | Las imágenes sin usar se eliminan cuando se borra un stack detectado automáticamente. |
Dicho de otro modo, nada se desmonta a tus espaldas hasta que actives el borrado, y ni siquiera entonces desaparecen primero tus volúmenes de datos.
Proveedores de Git compatibles. Son compatibles GitHub, GitLab, Gitea, Forgejo, Gogs y Azure DevOps. Azure DevOps es la excepción en cuanto a webhooks, porque los Azure Service Hooks no están soportados. El soporte de Gitea y Forgejo importa si alojas tu propia forja.
Docker Swarm. Compatible como destino. Lo que la página de ajustes de despliegue señala explícitamente: en modo Swarm, la reconciliación no comprueba los reinicios de contenedores ni el estado de salud, y la poda de imágenes no está soportada. Si tu destino es Swarm, obtienes despliegues, pero no una reconciliación completa del estado de salud.
Reconciliación. Por defecto, un límite de 5 reinicios en una ventana de 300 segundos, pensado para que unos health checks inestables no entren en bucle eterno. Mismo repositorio con distinta referencia: se ejecuta en secuencia; mismo repositorio con la misma referencia: se ejecuta en paralelo. Ese último detalle es sutil pero útil: varios despliegues de la misma referencia no hacen cola unos detrás de otros.
Proveedores de secretos externos integrados. Esta es una de las razones más fuertes para preferir Doco CD a un simple script de despliegue: admite AWS Secrets Manager, Bitwarden Secrets Manager, Bitwarden Vault / Vaultwarden, 1Password, 1Password Connect, Infisical, OpenBao y Webhook. Por separado, soporta cifrado basado en SOPS para datos sensibles de despliegue. Eso te da una salida más limpia de los archivos env en texto plano dentro de Git, sin construir tú mismo todo el flujo de resolución de secretos.
Lo demás. Doco CD ofrece métricas de Prometheus, programación de tareas, notificaciones, una imagen de contenedor distroless y licencia Apache-2.0. Según su historial de versiones, al 20 de agosto de 2026, la v0.109.2 es la última versión estable y la v0.110.0-rc.1 la preversión más reciente.
El trabajo de Doco CD termina en "aplicar el manifiesto"; a partir de ahí es Docker normal y corriente. Los propios comandos de registro de Compose son lo que usarás para inspeccionar qué está corriendo.
Consejo práctico sobre secretos. Si tu repositorio privado todavía tiene archivos env en texto plano, prioriza los proveedores de secretos externos de Doco CD o su soporte de SOPS. El objetivo es simple: sacar los secretos en claro de Git y permitir que los despliegues resuelvan los valores en tiempo de ejecución.
Construye sobre un VPS Linux con acceso root, NVMe y la potencia de AMD EPYC.
Ver planes LinuxDónde se queda corto Doco CD
Toda herramienta tiene límites, y conviene conocer los de Doco CD antes de dedicar un fin de semana a montarlo.
Un único responsable del código. El archivo CODEOWNERS del repositorio asigna todas las rutas a kimdre. Las publicaciones siguen siendo frecuentes, pero el gobierno del proyecto está concentrado en una sola persona.
Anterior a la 1.0. Doco CD todavía usa versionado 0.x, así que fija una versión probada y lee las notas de actualización antes de desplegar. El issue #851 de GitHub , ya cerrada, ilustra por qué: Docker v29 obligó al proyecto a abandonar módulos Go de Docker obsoletos.
Sin shell dentro del contenedor de Doco CD. Por seguridad, Doco CD no ofrece un entorno de shell ni ejecuta scripts arbitrarios del host. Las tareas previas y posteriores al despliegue deben pasar por contenedores de inicialización, sidecars o los hooks de ciclo de vida de Compose, lo que añade configuración frente a herramientas que ejecutan un script de despliegue directamente.
Pérdida de estado al reiniciar. El estado de reconciliación vive en memoria. Cuando Doco CD se reinicia, ese estado solo se reconstruye tras el siguiente sondeo o evento de webhook, así que el hueco depende de tu intervalo de sondeo o de cuándo llegue otro webhook.
Sin interfaz de gestión de flota. El multi-host ya no exige un agente por máquina. Desde la v0.102.0, las configuraciones de despliegue pueden apuntar a contextos Docker remotos, incluidos los contextos SSH, y un mismo repositorio puede definir varios destinos de despliegue. Ejecutar una instancia de Doco CD por host sigue siendo válido, pero ahora una instancia central puede desplegar en hosts Docker remotos. Lo que a Doco CD le sigue faltando es la interfaz de gestión de flota de Komodo y su inventario centralizado de hosts.
La huella de RAM y CPU no está documentada con cifras. La documentación oficial califica los requisitos de "diminutos" pero no publica ninguna referencia. Dimensiona el VPS para las aplicaciones que va a ejecutar, deja margen operativo y comprueba el consumo real de Doco CD en tu propio entorno.
Consejo práctico sobre multi-host. Usa un contexto Docker y un destino de despliegue distintos por máquina, restringe el acceso SSH y mantén únicos los secretos de webhook o de API. Si prefieres agentes aislados, una instancia de Doco CD por host sigue siendo válida.
Doco CD frente a las alternativas
Las otras cuatro herramientas que pondría en la lista corta intentan resolver "desplegar Compose automáticamente desde Git", pero con compromisos muy distintos. La decisión no es si hacerlo; eso ya lo decidiste. La decisión es qué forma de herramienta encaja en tu configuración. Aquí va la comparación directa.
| Herramienta | Disparador | Modelo multi-host | Secretos | Interfaz web | Licencia |
|---|---|---|---|---|---|
| Doco CD | Webhook o sondeo | Contextos Docker remotos, sin interfaz de flota | Proveedores externos y SOPS | Ninguna | Apache-2.0 |
| Komodo | Webhook y sincronización programada | Servicio Core central y agentes Periphery | Gestión de variables y secretos | Sí | GPL-3.0 |
| Portainer (CE/BE) | Webhook o sondeo | Agente de Portainer | Limitados, más opciones en BE | Sí | Zlib, condiciones comerciales para BE |
| Dokploy | Disparado por push | Multiservidor o Docker Swarm | Gestión de entornos integrada | Sí | Apache-2.0, con componentes propietarios |
| GitHub Actions + SSH | Disparado por push | Lo que programes en el script | Lo que programes en el script | Ninguna | No aplica |
Un apunte sobre cada uno, porque la tabla da la forma y el comentario da el porqué:
Komodo. La alternativa seria para varios hosts. Un servicio Core central más un agente Periphery en cada máquina, una sola interfaz que las ve todas, compilaciones dirigidas por Git además de los despliegues y soporte de Docker Swarm. Montarlo cuesta más, porque acabas ejecutando una base de datos y un plano de control, pero es la forma correcta si tienes una flota. Komodo encaja mejor cuando el control centralizado de la flota importa.
Portainer (CE o BE) con GitOps. Una interfaz gráfica completa sobre la sincronización con Git. La opción adecuada cuando el equipo quiere gestionar contenedores a golpe de clic además del CD. Si alguien va a estar igualmente en la interfaz mirando registros y reiniciando contenedores, más vale tener también ahí el CD. Consume más recursos que Doco CD. OIDC/SSO y el RBAC granular están detrás del muro de pago de la Business Edition. Nuestra guía de alternativas a Portainer cubre el panorama más amplio de la gestión de Docker.
Dokploy. Estilo PaaS. Es opinado, despliega automáticamente al hacer push, tiene interfaz web para todo y te deja Traefik con URLs limpias desde el principio. Encaja mejor con equipos que quieren una sensación tipo Heroku y aceptan ceder flexibilidad pura de Compose a cambio. Si eres alérgico al YAML, este es el camino más ligero hacia "hago push y la aplicación se despliega".
GitHub Actions + SSH. Cero infraestructura adicional. El trabajo de despliegue vive en el flujo de trabajo que ya tienes. Obtienes los registros del flujo, pero ninguna reconciliación nativa de Compose, ninguna recuperación de la deriva y ninguna vista persistente del estado del host, salvo que construyas esas piezas tú mismo. Perfecto para un servicio en un host. Se rompe en cuanto añades un segundo destino o quieres saber qué está corriendo dónde sin entrar por SSH. Para el tramo más sencillo del público, GitHub Actions + SSH sigue siendo la respuesta correcta.
Hay un recién llegado llamado stackd , que se presenta con un lenguaje parecido: "GitOps sin el impuesto de Kubernetes". Conviene saber que la categoría está viva, pero no conviene elegirlo frente a Doco CD echándolo a suertes hoy.
Cuándo Doco CD es la elección correcta (y cuándo no)
Elige Doco CD cuando:
- Gestionas uno o unos pocos hosts con Docker Compose y quieres que Git sea la fuente de verdad.
- Prefieres editar YAML en tu editor antes que ir haciendo clics en una interfaz.
- Quieres soporte de proveedores de secretos externos y cifrado basado en SOPS sin construir todo el flujo tú mismo.
- No te importa un proyecto con un único mantenedor, anterior a la 1.0 y en desarrollo activo.
Komodo. Elígelo cuando gestionas muchos hosts y quieres control centralizado de la flota, o cuando necesitas compilaciones dirigidas por Git, y no solo despliegues, bajo un mismo techo.
Portainer (CE o BE). Elígelo cuando el equipo quiere una interfaz para la operación diaria de contenedores junto con el CD, cuando la capa visual es el verdadero motivo por el que estás considerando la herramienta.
Dokploy. Elígelo cuando quieres una experiencia de despliegue tipo PaaS y no necesitas el control crudo de Compose.
GitHub Actions + SSH. Quédate con esto cuando es un servicio, un host, y no necesitas reconciliación ni recuperación de la deriva.
Para quienes están en ese medio de después de Watchtower y antes de Kubernetes, Doco CD es una opción ligera y sólida. Mi lectura: para un homelab nuevo o un SaaS pequeño, empezaría con Doco CD cuando encaje una operación Git primero y sin interfaz, y pasaría a Komodo en cuanto el inventario centralizado, los permisos y la visibilidad de la flota se vuelvan requisitos.
Elijas la herramienta que elijas, ejecútala en un VPS Linux dimensionado para las cargas de Compose que va a alojar. El VPS Linux de Cloudzy es un buen sitio para esto, con acceso root por defecto. Y si quieres saltarte el baile de apt, también puedes desplegar Docker con un clic desde nuestro marketplace.
Nuestro marketplace también tiene imágenes de un clic para Gitea, con el que Doco CD se integra de forma nativa. También hay imágenes para Komodo y también para Portainer, por si decides que alguno de ellos es la forma que prefieres.
Preguntas frecuentes
¿Está Doco CD listo para producción?
Doco CD puede usarse en producción si su perfil de riesgo encaja con tu carga de trabajo. Se desarrolla activamente, pero sigue usando versionado anterior a la 1.0 y su archivo CODEOWNERS asigna el proyecto a una sola persona. Fija una versión probada, prueba las actualizaciones antes de desplegarlas y valora una gobernanza más amplia para infraestructura crítica.
¿Cómo gestiono varios hosts con Doco CD?
Usa un contexto Docker y un destino de despliegue distintos para cada host. Una sola instancia de Doco CD puede desplegar en varios hosts Docker remotos por SSH o TCP; una instancia por host sigue siendo un modelo de aislamiento opcional. Elige Komodo si necesitas inventario centralizado, permisos y visibilidad de toda la flota.
¿Cuál es la diferencia entre el modo webhook y el modo sondeo?
El modo webhook despliega casi al instante cuando Git recibe un push, pero exige un puerto accesible desde internet o un proxy inverso delante de Doco CD. El modo sondeo consulta el repositorio según un calendario, así que los despliegues se retrasan un poco pero no hace falta exponer ningún puerto. El sondeo es el valor por defecto más sencillo; los webhooks compensan si haces push a menudo o necesitas ciclos de retroalimentación rápidos.
¿Cómo se compara Doco CD con Komodo?
Doco CD es más ligero y no tiene interfaz, y puede gestionar varios hosts mediante contextos Docker remotos. Komodo usa un servicio Core central más agentes Periphery, y añade una interfaz de flota y compilaciones dirigidas por Git. Elige Doco CD para desplegar Compose sin interfaz; elige Komodo cuando importa el control centralizado de la flota.
¿Puede Doco CD sustituir a Watchtower?
Para el caso de uso que buscaba la mayoría de usuarios de Watchtower, "desplegar lo que está en Git, cuando Git cambia", sí: eso es justo lo que hace Doco CD. Para el modelo literal de Watchtower, sondear un registro y descargar la imagen cuando aparece una etiqueta nueva, no: Doco CD se dispara con Git, no con el registro. El modelo disparado por Git es la opción más segura y auditable en cuanto pasas de servicios de juguete.
