Обзор Doco CD: GitOps для Docker Compose без накладных расходов Kubernetes

Каждый push — один и тот же ритуал: зайти по SSH, обновить репозиторий, поднять стек Compose, надеяться, что ничего не сломалось, и вспоминать, запускали ли вы миграцию. Этот ручной цикл работает ровно до того момента, когда вам понадобятся воспроизводимые развёртывания, ясная картина того, что запущено, или восстановление после дрейфа.

Doco CD — один из прямых ответов. Это небольшой сервис на Go, который следит за вашим Git-репозиторием и применяет изменения Compose при push: webhook или опрос, на ваш выбор. ArgoCD и Flux делают то же самое для Kubernetes, но Doco CD обходится без Kubernetes, потому что ему не нужен control plane.

В этом обзоре разбирается, что Doco CD умеет, чего не умеет и как он смотрится на фоне Komodo, режима GitOps в Portainer, Dokploy и обычного скрипта GitHub Actions + SSH. К концу вы поймёте, подходит ли он вашей инфраструктуре и что выбрать, если нет.

Кратко (TL;DR)

• Doco CD — крошечный GitOps-агент, родной для Compose: он следит за Git-репозиторием (GitHub, GitLab, Gitea, Forgejo и другими) и приводит стек в соответствие, как только что-то меняется.
• Встроенная поддержка внешних провайдеров секретов вместе с шифрованием на основе SOPS — вот что отличает его от самописного скрипта развёртывания.
• Согласно README, проект позиционирует себя как «простую альтернативу Portainer или ArgoCD для Docker». Формулировка в целом верная.
• Реальные ограничения: один владелец кода, версии до 1.0, отсутствие интерфейса управления парком машин и состояние согласования, которое восстанавливается только после следующего опроса или события webhook.
• Берите его, если у вас один или несколько хостов с Compose и вы хотите сделать Git источником истины без всякого интерфейса. Komodo подойдёт для парка серверов, Portainer — если нужен интерфейс, Dokploy — ради ощущения PaaS, а GitHub Actions + SSH — когда речь и правда об одном сервисе на одном хосте.

Какую нишу пытается закрыть Doco CD

Для всех, кто в 2026 году работает с Docker Compose, есть странная промежуточная зона. Крупные GitOps-инструменты вроде Argo CD и Flux нацелены на Kubernetes, а модель Watchtower с опросом реестра реагирует на смену образов, вместо того чтобы применять версионированное состояние Compose. Официальный репозиторий был заархивирован 17 декабря 2025 года и теперь сообщает, что проект больше не поддерживается.

GitHub Actions плюс шаг развёртывания по SSH работает. Для одного сервиса на одном хосте это правильный выбор. Проблемы начинаются, когда появляется второй хост, вторая стека или желание знать, какой коммит развёрнут прямо сейчас. Логи workflow у вас останутся, а вот согласования на уровне Compose, восстановления после дрейфа и постоянной картины соответствия хоста репозиторию — нет.

Заявка Doco CD, прямо из README — «простая альтернатива Portainer или ArgoCD для Docker». В этой формулировке и весь смысл: компактно, нативно для Compose, без Kubernetes, без интерфейса, который надо поддерживать, без центрального control plane, за которым надо присматривать. Если вы не используете K8s и не собирались, это именно та категория, которую вы искали.

Как на самом деле работает Doco CD

Doco CD — это один бинарник на Go, который работает в Docker-контейнере, следит за Git-репозиторием и применяет изменения Compose, когда состояние репозитория меняется. Вот и вся концепция. Самое интересное скрыто в настройках по умолчанию и интеграциях.

Триггеры. Два режима: webhook или опрос. Webhook срабатывает почти мгновенно, но требует открытого порта или, что реалистичнее, обратного прокси перед Doco CD. Опрос — это периодический запрос: с небольшой задержкой и без входящих портов. Опрос проще и стоит по умолчанию, а согласно официальной документации оба режима равноправны. Выбирайте исходя из того, есть ли у вашего хоста доступная публичная точка входа и насколько быстро вам нужны развёртывания.

Конфигурация на уровне репозитория. Файл .doco-cd.yaml (или .doco-cd.yml) лежит в корне репозитория рядом с вашим файлом Compose. Единственное обязательное поле — имя развёртывания. Минимальная конфигурация выглядит так:

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

Это задокументированные значения по умолчанию: тайм-аут 180 секунд, «осиротевшие» контейнеры удаляются, образы вычищаются, принудительное пересоздание выключено.

Автообнаружение. При включённом автообнаружении Doco CD просматривает подкаталоги в поисках файлов Compose, так что один репозиторий может держать несколько стеков. Он также поддерживает несколько конфигураций развёртывания в одном файле, записанных как YAML-документы, разделённые строкой из трёх дефисов. Значения очистки по умолчанию консервативны, и их стоит прочитать, прежде чем на них полагаться:

Другими словами, ничего не сносится у вас за спиной, пока вы сами не включите удаление, да и тогда тома с данными уходят последними.

Поддерживаемые Git-провайдеры. Поддерживаются GitHub, GitLab, Gitea, Forgejo, Gogs и Azure DevOps. Azure DevOps — исключение по части webhook, поскольку Azure Service Hooks не поддерживаются. Поддержка Gitea и Forgejo важна, если вы держите свою кузницу кода на своём сервере.

Docker Swarm. Поддерживается как цель развёртывания. То, о чём прямо предупреждает страница настроек развёртывания явно: в режиме Swarm согласование не проверяет ни перезапуски контейнеров, ни состояние здоровья, а очистка образов в Swarm не поддерживается. Если ваша цель — Swarm, вы получаете развёртывания, но не полное согласование по здоровью.

Согласование состояния. По умолчанию действует лимит в 5 перезапусков за окно в 300 секунд, чтобы «дёргающиеся» проверки здоровья не зациклились навсегда. Тот же репозиторий с другой ссылкой выполняется последовательно; тот же репозиторий с той же ссылкой — параллельно. Последняя деталь неочевидна, но полезна: несколько развёртываний одной и той же ссылки не выстраиваются в очередь друг за другом.

Встроенные внешние провайдеры секретов. Это один из самых весомых доводов в пользу Doco CD против обычного скрипта развёртывания: он поддерживает AWS Secrets Manager, Bitwarden Secrets Manager, Bitwarden Vault / Vaultwarden, 1Password, 1Password Connect, Infisical, OpenBao и Webhook. Отдельно поддерживается шифрование на основе SOPS для чувствительных данных развёртывания. Это даёт чистый способ уйти от env-файлов в открытом виде в Git, не выстраивая всю цепочку разрешения секретов самостоятельно.

Всё остальное. Doco CD предоставляет метрики Prometheus, планирование задач, уведомления, distroless-образ контейнера и лицензию Apache-2.0. Согласно его истории релизов на 20 августа 2026 года последний стабильный релиз — v0.109.2, а самый свежий предварительный — v0.110.0-rc.1.

Работа Doco CD заканчивается на «примени манифест», дальше начинается обычный Docker. Собственные команды логов Compose и будут вашим инструментом, чтобы посмотреть, что запущено.

Совет по секретам. Если в вашем приватном репозитории всё ещё лежат env-файлы открытым текстом, начните с внешних провайдеров секретов Doco CD или его поддержки SOPS. Цель проста: убрать открытые секреты из Git, но при этом дать развёртываниям получать значения во время выполнения.

В чём Doco CD не дотягивает

У любого инструмента есть ограничения, и об ограничениях Doco CD стоит знать до того, как вы потратите выходные на его настройку.

Один владелец кода. Файл CODEOWNERS этого репозитория назначает все пути пользователю kimdre. Релизы выходят по-прежнему часто, но управление проектом сосредоточено в руках одного человека.

Версии до 1.0. Doco CD всё ещё использует нумерацию 0.x, поэтому закрепляйте проверенную версию и читайте заметки об обновлении перед выкаткой. Закрытая задача GitHub #851 показывает, почему: Docker v29 вынудил проект уйти от устаревших Go-модулей Docker.

Внутри контейнера Doco CD нет оболочки. Из соображений безопасности Doco CD не даёт окружения оболочки и не выполняет произвольные скрипты на хосте. Задачи до и после развёртывания приходится запускать через init-контейнеры, sidecar-контейнеры или хуки жизненного цикла Compose, а это добавляет настройки по сравнению с инструментами, которые просто запускают скрипт развёртывания.

Потеря состояния при перезапуске. Состояние согласования хранится в памяти. После перезапуска Doco CD оно восстанавливается только со следующим опросом или событием webhook, так что длительность провала зависит от интервала опроса или от того, скоро ли придёт очередной webhook.

Нет интерфейса управления парком машин. Работа с несколькими хостами больше не требует по агенту на каждый. Начиная с v0.102.0 конфигурации развёртывания могут указывать на удалённые контексты Docker, включая SSH-контексты, а один репозиторий может описывать несколько целей развёртывания. Держать по экземпляру Doco CD на хост по-прежнему допустимо, но центральный экземпляр теперь умеет разворачивать на удалённые Docker-хосты. Чего Doco CD по-прежнему не хватает, так это интерфейса управления парком машин, как у Komodo, и централизованной описи хостов.

Потребление RAM и CPU не задокументировано в цифрах. Официальная документация называет требования «крошечными», но не публикует базовых цифр. Подбирайте VPS под приложения, которые он будет обслуживать, оставляйте запас на эксплуатацию и проверяйте реальное потребление Doco CD в своей среде.

Совет по нескольким хостам. Заводите отдельный контекст Docker и отдельную цель развёртывания на каждый хост, ограничивайте доступ по SSH и держите секреты webhook и API уникальными. Если вам ближе изолированные агенты, вариант с одним экземпляром Doco CD на хост никуда не делся.

Doco CD против альтернатив

Четыре других инструмента, которые я бы включил в шорт-лист, решают одну и ту же задачу «автоматически разворачивать Compose из Git», но с очень разными компромиссами. Вопрос не в том, делать ли это: вы уже решили. Вопрос в том, какая форма инструмента подойдёт вашей инфраструктуре. Вот сравнение бок о бок.

Коротко о каждом, потому что таблица показывает форму, а комментарий объясняет почему:

Komodo. Серьёзная альтернатива для нескольких хостов. Центральный сервис Core плюс агент Periphery на каждой машине, единый интерфейс, который видит их все, сборки под управлением Git в дополнение к развёртываниям и поддержка Docker Swarm. Настройка тяжелее, ведь вы поднимаете базу данных и control plane, зато это правильная форма, когда у вас парк серверов. Komodo выигрывает там, где важен централизованный контроль над парком.

Portainer (CE или BE) с GitOps. Полноценный графический интерфейс поверх синхронизации с Git. Правильный выбор, когда команде нужен «кликабельный» контейнерный менеджмент вместе с CD. Если кто-то всё равно будет сидеть в интерфейсе, смотреть логи и перезапускать контейнеры, пусть CD живёт там же. Ресурсов ест больше, чем Doco CD. OIDC/SSO и детальный RBAC доступны только в платной Business Edition. Наше руководство по альтернативам Portainer охватывает более широкий ландшафт управления Docker.

Dokploy. В стиле PaaS. Инструмент с характером: разворачивает автоматически по push, имеет веб-интерфейс для всего и из коробки настраивает Traefik с аккуратными URL. Лучше подходит командам, которым нужно ощущение Heroku и которые готовы обменять на это гибкость чистого Compose. Если у вас аллергия на YAML, это самый лёгкий путь к «сделал push, приложение развернулось».

GitHub Actions + SSH. Никакой дополнительной инфраструктуры. Задача развёртывания живёт в том workflow, который у вас уже есть. Вы получаете логи workflow, но не получаете ни согласования на уровне Compose, ни восстановления после дрейфа, ни постоянной картины состояния хостов, если только не построите это сами. Отлично для одного сервиса на одном хосте. Ломается, как только появляется вторая цель или желание узнать, что где запущено, не заходя по SSH. Для самой простой части аудитории GitHub Actions + SSH по-прежнему правильный ответ.

Есть и более новый участник под названием stackd , который описывает себя похожими словами: «GitOps без налога на Kubernetes». Полезно знать, что категория живая, но выбирать его вместо Doco CD подбрасыванием монетки сегодня не стоит.

ЧИТАТЬ

Coolify против Dokploy: подробное сравнение self-hosted PaaS на VPS

Когда Doco CD — правильный выбор (и когда нет)

Выбирайте Doco CD, когда:

• У вас один или несколько хостов с Docker Compose и вы хотите сделать Git источником истины.
• Вам приятнее править YAML в редакторе, чем кликать по интерфейсу.
• Вам нужна поддержка внешних провайдеров секретов и шифрования на основе SOPS без самостоятельной сборки всей цепочки.
• Вас устраивает проект с единственным мейнтейнером, до версии 1.0, но активно развивающийся.

Komodo. Берите его, когда у вас много хостов и нужен централизованный контроль над парком, или когда под одной крышей требуются не только развёртывания, но и сборки под управлением Git.

Portainer (CE или BE). Берите его, когда команде нужен интерфейс для повседневной работы с контейнерами вместе с CD, когда визуальный слой и есть настоящая причина, по которой вы вообще смотрите на инструмент.

Dokploy. Берите его, когда хотите развёртывание в духе PaaS и не нуждаетесь в прямом контроле над Compose.

GitHub Actions + SSH. Оставайтесь на нём, когда речь об одном сервисе на одном хосте и вам не нужны ни согласование, ни восстановление после дрейфа.

Для тех, кто оказался в промежутке после Watchtower и до Kubernetes, Doco CD — сильный лёгкий вариант. Моё мнение: для нового домашнего сервера или небольшого SaaS я бы начал с Doco CD, пока подходит работа в стиле Git-first без интерфейса, а затем перешёл на Komodo, когда централизованная опись, права доступа и обзор парка станут требованиями.

Какой бы инструмент вы ни выбрали, запускайте его на Linux VPS, подобранном под те нагрузки Compose, которые он будет обслуживать. Linux VPS от Cloudzy — вполне разумный дом для этого, с root-доступом по умолчанию. А если хочется пропустить пляски с apt, можно ещё развернуть Docker в один клик из нашего маркетплейса.

В нашем маркетплейсе есть и образы в один клик для Gitea, с которым Doco CD интегрируется нативно. Есть образы и для Komodo , а также для Portainer — на случай, если вы решите, что вам ближе один из них.

Часто задаваемые вопросы

Готов ли Doco CD к продакшену?

Doco CD можно использовать в продакшене, если его профиль рисков подходит вашей нагрузке. Проект активно развивается, но всё ещё живёт на версиях до 1.0, а файл CODEOWNERS закрепляет его за одним человеком. Закрепите проверенную версию, тестируйте обновления до выкатки и подумайте о более широком управлении, если речь о критичной инфраструктуре.

Как управлять несколькими хостами с помощью Doco CD?

Заведите отдельный контекст Docker и отдельную цель развёртывания для каждого хоста. Один экземпляр Doco CD может разворачивать на несколько удалённых Docker-хостов по SSH или TCP; вариант «по экземпляру на хост» остаётся необязательной моделью изоляции. Выбирайте Komodo, если нужны централизованная опись, права доступа и обзор всего парка.

Чем режим webhook отличается от режима опроса?

Режим webhook разворачивает почти мгновенно, как только в Git приходит push, но требует порта, доступного из интернета, или обратного прокси перед Doco CD. Режим опроса проверяет репозиторий по расписанию: развёртывания слегка запаздывают, зато открывать порт не нужно. Опрос проще и стоит по умолчанию; webhook оправдан, если вы часто пушите или вам нужна быстрая обратная связь.

Как Doco CD смотрится на фоне Komodo?

Doco CD легче и обходится без интерфейса, а несколькими хостами управляет через удалённые контексты Docker. Komodo строится на центральном сервисе Core и агентах Periphery, добавляя интерфейс для парка машин и сборки под управлением Git. Берите Doco CD для развёртывания Compose без интерфейса, а Komodo — когда важен централизованный контроль над парком.

Может ли Doco CD заменить Watchtower?

Для сценария, которого на самом деле хотело большинство пользователей Watchtower, «разверни то, что лежит в Git, когда Git меняется», ответ да: именно это Doco CD и делает. Для буквальной модели Watchtower, опроса реестра и загрузки образа при появлении нового тега, ответ нет: Doco CD запускается от Git, а не от реестра. Модель на основе Git безопаснее и лучше поддаётся аудиту для всего, что серьёзнее игрушечных сервисов.