Кожен 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-документи, розділені рядком із трьох дефісів. Значення очищення за замовчуванням консервативні, і їх варто прочитати, перш ніж покладатися на них:
| Налаштування | Типово | Що це означає |
|---|---|---|
delete | false | Застаріле розгортання лишається на місці, коли його застосунок зникає з робочого каталогу. |
remove_volumes | false | Томи зберігаються при видаленні автоматично виявленого стеку. |
remove_images | true | Невикористовувані образи видаляються при видаленні автоматично виявленого стеку. |
Інакше кажучи, ніщо не зноситься за вашою спиною, доки ви самі не ввімкнете видалення, та й тоді томи з даними зникають останніми.
Підтримувані 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, але дати розгортанням отримувати значення під час виконання.
Розробляйте на Linux VPS з root-доступом, NVMe та потужністю AMD EPYC.
Переглянути тарифи LinuxУ чому Doco CD не дотягує
У кожного інструмента є межі, і межі Doco CD варто знати ще до того, як ви витратите вихідні на його налаштування.
Один власник коду. Файл CODEOWNERS цього репозиторію призначає всі шляхи користувачеві kimdre. Релізи виходять і далі часто, але управління проєктом зосереджене в одній людині.
Версії до 1.0. Doco CD досі використовує нумерацію 0.x, тож закріплюйте перевірений реліз і читайте нотатки про оновлення перед розгортанням. Закрите issue 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», але з дуже різними компромісами. Питання не в тому, робити це чи ні: ви вже вирішили. Питання в тому, яка форма інструмента пасує вашій конфігурації. Ось порівняння пліч-о-пліч.
| Інструмент | Тригер | Модель багатьох хостів | Секрети | Веб-інтерфейс | Ліцензія |
|---|---|---|---|---|---|
| Doco CD | Webhook або опитування | Віддалені контексти Docker, без інтерфейсу для парку машин | Зовнішні постачальники плюс SOPS | Нічого | Apache-2.0 |
| Komodo | Webhook плюс синхронізація за розкладом | Центральний Core плюс агенти Periphery | Керування змінними та секретами | Так | GPL-3.0 |
| Portainer (CE/BE) | Webhook або опитування | Агент Portainer | Обмежено, більше можливостей у BE | Так | Zlib, комерційні умови для BE |
| Dokploy | Запускається за push | Кілька серверів або Docker Swarm | Вбудоване керування середовищами | Так | Apache-2.0, з пропрієтарними компонентами |
| GitHub Actions + SSH | Запускається за push | Усе, що ви напишете в скрипті | Усе, що ви напишете в скрипті | Нічого | Не застосовно |
Коротко про кожен, бо таблиця дає форму, а коментар — причину:
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 підкиданням монетки сьогодні не варто.
Коли 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 — сильний легкий варіант. Моя думка: для нового домашнього серверa чи невеликого 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 безпечніша й краще піддається аудиту для всього, що серйозніше за іграшкові сервіси.
