Recenzja Doco CD: GitOps dla Docker Compose bez narzutu Kubernetes

Każdy push to ten sam rytuał: zalogować się przez SSH, pobrać repozytorium, postawić stos Compose z powrotem, mieć nadzieję, że nic się nie zepsuło, i próbować sobie przypomnieć, czy migracja została uruchomiona. Ta ręczna pętla działa do momentu, w którym potrzebujesz powtarzalnych wdrożeń, jasnego zapisu tego, co działa, albo naprawy dryfu.

Doco CD to jedna z bezpośrednich odpowiedzi. To mała usługa w Go, która obserwuje twoje repozytorium Git i stosuje zmiany Compose przy każdym pushu: webhook albo odpytywanie, twój wybór. ArgoCD i Flux robią to dla Kubernetes, ale Doco CD omija Kubernetes, bo nie potrzebuje warstwy sterowania.

Ta recenzja omawia, co Doco CD robi, czego nie robi i jak wypada na tle Komodo, trybu GitOps w Portainerze, Dokploy oraz zwykłego skryptu GitHub Actions + SSH. Na koniec będziesz wiedzieć, czy pasuje do twojej konfiguracji i co wybrać, jeśli nie.

TL;DR

• Doco CD to malutki agent GitOps natywny dla Compose: obserwuje repozytorium Git (GitHub, GitLab, Gitea, Forgejo i inne) i uzgadnia twój stos, gdy coś się zmieni.
• Wbudowana obsługa zewnętrznych dostawców sekretów wraz z szyfrowaniem opartym na SOPS to przewaga nad własnoręcznie pisanym skryptem wdrożeniowym.
• Zgodnie z własnym README przedstawia się jako „prosta alternatywa dla Portainera lub ArgoCD w Dockerze”. To ujęcie jest mniej więcej trafne.
• Prawdziwe ograniczenia: jeden właściciel kodu, wersjonowanie sprzed 1.0, brak interfejsu do zarządzania flotą i stan uzgadniania odbudowywany dopiero po kolejnym odpytaniu lub zdarzeniu webhooka.
• Wybierz je, gdy prowadzisz jeden lub kilka hostów z Compose i chcesz mieć Git jako źródło prawdy bez interfejsu. Komodo weź do floty, Portainer, gdy chcesz interfejs, Dokploy dla wrażenia PaaS, a GitHub Actions + SSH, gdy naprawdę chodzi o jedną usługę na jednym hoście.

Luka, którą Doco CD próbuje wypełnić

Dla każdego, kto w 2026 roku uruchamia Docker Compose, istnieje dziwny obszar pośredni. Duże narzędzia GitOps, takie jak Argo CD i Flux, celują w Kubernetes, a model Watchtowera oparty na odpytywaniu rejestru reaguje na zmiany obrazów, zamiast stosować wersjonowany stan Compose. Samo repozytorium zostało zarchiwizowane 17 grudnia 2025 roku i informuje teraz, że projekt nie jest już utrzymywany.

GitHub Actions plus krok wdrożenia przez SSH działa. Dla jednej usługi na jednym hoście to właściwy wybór. Kłopoty zaczynają się, gdy dodasz drugi host albo drugi stos, albo gdy chcesz wiedzieć, który commit jest właśnie wdrożony. Logi workflow nadal masz, ale nie masz uzgadniania natywnego dla Compose, naprawy dryfu ani trwałego widoku tego, czy host wciąż odpowiada repozytorium.

Deklaracja Doco CD, prosto z README, to „prosta alternatywa dla Portainera lub ArgoCD w Dockerze”. W tym ujęciu tkwi cała rzecz: małe, natywne dla Compose, bez Kubernetes, bez interfejsu do utrzymywania, bez centralnej warstwy sterowania do pilnowania. Jeśli nie używasz K8s i nie chciałeś, to właśnie ta kategoria, której szukałeś.

Jak Doco CD naprawdę działa

Doco CD to pojedynczy plik binarny w Go, działający w kontenerze Dockera, który obserwuje repozytorium Git i stosuje zmiany Compose, gdy stan repozytorium się zmieni. To cała koncepcja. Ciekawe rzeczy kryją się w wartościach domyślnych i integracjach.

Wyzwalacze. Dwa tryby: webhook albo odpytywanie. Webhook działa niemal natychmiast, ale wymaga wystawionego portu, a realnie odwrotnego proxy przed Doco CD. Odpytywanie to okresowe pobieranie: nieco opóźnione, bez portu przychodzącego. Odpytywanie to prostsze ustawienie domyślne, a zgodnie z oficjalną dokumentacją oba są równorzędne. Wybierz w zależności od tego, czy twój host ma osiągalny publiczny punkt końcowy i jak szybkich wdrożeń potrzebujesz.

Konfiguracja per repozytorium. Plik .doco-cd.yaml (albo .doco-cd.yml) leży w katalogu głównym repozytorium, obok twojego pliku Compose. Jedynym wymaganym polem jest nazwa wdrożenia. Minimalna konfiguracja wygląda tak:

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

To są udokumentowane wartości domyślne: limit czasu 180 sekund, usuwanie osieroconych kontenerów, czyszczenie obrazów i brak wymuszonego odtwarzania.

Automatyczne wykrywanie. Przy włączonym automatycznym wykrywaniu Doco CD przeszukuje podkatalogi w poszukiwaniu plików Compose, więc jedno repozytorium może mieścić wiele stosów. Obsługuje też wiele konfiguracji wdrożeniowych w jednym pliku, zapisanych jako dokumenty YAML rozdzielone linią trzech myślników. Domyślne ustawienia sprzątania są zachowawcze i warto je przeczytać, zanim na nich polegniesz:

Innymi słowy, nic nie zostanie rozebrane za twoimi plecami, dopóki sam nie włączysz usuwania, a nawet wtedy wolumeny z danymi znikają na końcu.

Obsługiwani dostawcy Git. Obsługiwane są GitHub, GitLab, Gitea, Forgejo, Gogs i Azure DevOps. Wyjątkiem przy webhookach jest Azure DevOps, bo Azure Service Hooks nie są wspierane. Wsparcie dla Gitei i Forgejo ma znaczenie, jeśli hostujesz własną forge.

Docker Swarm. Obsługiwany jako cel wdrożenia. To, co strona ustawień wdrożenia wyraźnie zaznacza: w trybie Swarm uzgadnianie nie sprawdza restartów kontenerów ani stanu zdrowia, a czyszczenie obrazów nie jest w Swarmie wspierane. Jeśli twoim celem jest Swarm, dostajesz wdrożenia, ale nie pełne uzgadnianie stanu zdrowia.

Uzgadnianie stanu. Domyślnie obowiązuje limit 5 restartów w oknie 300 sekund, po to, by niestabilne health checki nie kręciły się w nieskończoność. To samo repozytorium z inną referencją działa sekwencyjnie, a z tą samą referencją równolegle. Ten ostatni szczegół jest subtelny, ale przydatny: kilka wdrożeń tej samej referencji nie ustawia się w kolejce jedno za drugim.

Wbudowani zewnętrzni dostawcy sekretów. To jeden z mocniejszych powodów, by rozważyć Doco CD zamiast zwykłego skryptu wdrożeniowego: obsługuje AWS Secrets Manager, Bitwarden Secrets Manager, Bitwarden Vault / Vaultwarden, 1Password, 1Password Connect, Infisical, OpenBao i Webhook. Osobno wspiera szyfrowanie oparte na SOPS dla wrażliwych danych wdrożeniowych. Dostajesz dzięki temu czyste wyjście z plików env trzymanych jawnie w repozytorium Git, bez budowania całego procesu rozwiązywania sekretów samodzielnie.

Reszta. Doco CD dostarcza metryki Prometheusa, harmonogramowanie zadań, powiadomienia, distroless obraz kontenera i licencję Apache-2.0. Zgodnie z jego historią wydań na 20 sierpnia 2026 roku najnowszym stabilnym wydaniem jest v0.109.2, a najświeższą wersją zapowiadającą v0.110.0-rc.1.

Zadanie Doco CD kończy się na „zastosuj manifest”, a dalej jest już zwykły Docker. Własne polecenia logów Compose są tym, czym sprawdzisz, co jest uruchomione.

Praktyczna rada o sekretach. Jeśli w twoim prywatnym repozytorium wciąż leżą jawne pliki env, zacznij od zewnętrznych dostawców sekretów w Doco CD albo od obsługi SOPS. Cel jest prosty: wyprowadzić jawne sekrety z Gita, a mimo to pozwolić wdrożeniom pobierać wartości w czasie działania.

Gdzie Doco CD zawodzi

Każde narzędzie ma ograniczenia, a te w Doco CD warto poznać, zanim poświęcisz weekend na jego uruchomienie.

Jeden właściciel kodu. Plik CODEOWNERS w repozytorium przypisuje wszystkie ścieżki do kimdre. Wydania nadal pojawiają się często, ale zarządzanie skupia się w jednej osobie.

Przed wersją 1.0. Doco CD wciąż stosuje wersjonowanie 0.x, więc przypnij przetestowane wydanie i przeczytaj notatki o aktualizacji przed wdrożeniem. Zamknięte zgłoszenie GitHub #851 pokazuje dlaczego: Docker v29 zmusił projekt do odejścia od przestarzałych modułów Go Dockera.

Brak powłoki wewnątrz kontenera Doco CD. Ze względów bezpieczeństwa Doco CD nie udostępnia środowiska powłoki ani nie uruchamia dowolnych skryptów na hoście. Zadania przed wdrożeniem i po nim muszą przechodzić przez kontenery init, sidecary albo hooki cyklu życia Compose, co oznacza więcej konfiguracji niż w narzędziach uruchamiających skrypt wdrożeniowy wprost.

Utrata stanu po restarcie. Stan uzgadniania trzymany jest w pamięci. Po restarcie Doco CD odbudowuje go dopiero przy kolejnym odpytaniu lub zdarzeniu webhooka, więc długość luki zależy od twojego interwału odpytywania albo od tego, jak szybko przyjdzie następny webhook.

Brak interfejsu do zarządzania flotą. Praca z wieloma hostami nie wymaga już jednego agenta na host. Od wersji v0.102.0 konfiguracje wdrożeń mogą wskazywać na zdalne konteksty Dockera, w tym konteksty SSH, a jedno repozytorium może definiować wiele celów wdrożenia. Uruchamianie jednej instancji Doco CD na host wciąż jest w porządku, ale centralna instancja może teraz wdrażać na zdalne hosty Dockera. Doco CD nadal brakuje interfejsu do zarządzania flotą, jaki ma Komodo, i scentralizowanego spisu hostów.

Zużycie RAM i CPU nie jest udokumentowane liczbowo. Oficjalna dokumentacja opisuje wymagania jako „znikome”, ale nie podaje żadnej wartości odniesienia. Dobierz VPS pod aplikacje, które będzie obsługiwał, zostaw zapas operacyjny i sprawdź rzeczywiste zużycie Doco CD we własnym środowisku.

Praktyczna rada o wielu hostach. Dla każdego hosta używaj osobnego kontekstu Dockera i osobnego celu wdrożenia, ograniczaj dostęp po SSH i pilnuj, by sekrety webhooków i API były unikalne. Jeśli wolisz odizolowane agenty, jedna instancja Doco CD na host wciąż jest w porządku.

Doco CD kontra alternatywy

Cztery pozostałe narzędzia, które wziąłbym pod uwagę, próbują rozwiązać to samo, czyli „automatyczne wdrażanie Compose z Gita”, ale przy bardzo różnych kompromisach. Pytanie nie brzmi, czy to robić, bo to już postanowiłeś. Pytanie brzmi, jaki kształt narzędzia pasuje do twojej konfiguracji. Oto zestawienie obok siebie.

Krótko o każdym, bo tabela pokazuje kształt, a komentarz wyjaśnia dlaczego:

Komodo. Poważna alternatywa dla wielu hostów. Centralna usługa Core plus agent Periphery na każdym hoście, jeden interfejs, który widzi je wszystkie, budowanie sterowane Gitem obok wdrożeń oraz obsługa Docker Swarm. Uruchomienie jest cięższe, bo prowadzisz bazę danych i warstwę sterowania, ale to właściwy kształt, gdy masz flotę. Komodo pasuje lepiej, gdy liczy się scentralizowana kontrola nad flotą.

Portainer (CE albo BE) z GitOps. Pełny interfejs graficzny nałożony na synchronizację z Gitem. Właściwy wybór, gdy zespół chce zarządzać kontenerami myszką obok CD. Skoro i tak ktoś będzie siedział w interfejsie, czytał logi i restartował kontenery, niech CD mieszka w tym samym miejscu. Zużywa więcej zasobów niż Doco CD. OIDC/SSO oraz szczegółowy RBAC są za paywallem Business Edition. Nasz przewodnik po alternatywach dla Portainera obejmuje szerszy krajobraz zarządzania Dockerem.

Dokploy. W stylu PaaS. Ma wyraziste zdanie na temat tego, jak się to robi, wdraża automatycznie po pushu, ma interfejs webowy do wszystkiego i od razu ustawia Traefika oraz czyste adresy URL. Lepszy dla zespołów, które chcą wrażenia Heroku i godzą się oddać za to surową elastyczność Compose. Jeśli masz alergię na YAML, to najlżejsza droga do „robię push i aplikacja się wdraża”.

GitHub Actions + SSH. Zero dodatkowej infrastruktury. Zadanie wdrożenia mieszka w workflow, który już masz. Dostajesz logi workflow, ale nie dostajesz uzgadniania natywnego dla Compose, naprawy dryfu ani trwałego widoku stanu hostów, chyba że zbudujesz te elementy samodzielnie. Dla jednej usługi na jednym hoście jest w porządku. Rozsypuje się, gdy dojdzie drugi cel albo gdy chcesz wiedzieć, co gdzie działa, bez logowania po SSH. Dla najprostszej części odbiorców GitHub Actions + SSH nadal jest właściwą odpowiedzią.

Jest też nowszy gracz o nazwie stackd , który opisuje się podobnym językiem: „GitOps bez podatku od Kubernetes”. Warto wiedzieć, że kategoria żyje, ale nie warto dziś wybierać go zamiast Doco CD rzutem monetą.

CZYTAJ

Coolify vs Dokploy: Szczegółowe porównanie samodzielnie hostowanego PaaS na VPS

Kiedy Doco CD to właściwy wybór (a kiedy nie)

Wybierz Doco CD, gdy:

• Prowadzisz jeden lub kilka hostów z Docker Compose i chcesz mieć Git jako źródło prawdy.
• Wolisz edytować YAML w edytorze, niż klikać po interfejsie.
• Chcesz obsługi zewnętrznych dostawców sekretów i szyfrowania opartego na SOPS bez budowania całego procesu samodzielnie.
• Nie masz nic przeciwko projektowi z jednym opiekunem, sprzed wersji 1.0, ale aktywnie rozwijanemu.

Komodo. Wybierz je, gdy zarządzasz wieloma hostami i chcesz scentralizowanej kontroli nad flotą albo gdy pod jednym dachem potrzebujesz też budowania sterowanego Gitem, nie tylko wdrożeń.

Portainer (CE albo BE). Wybierz je, gdy zespół obok CD chce interfejsu do codziennej obsługi kontenerów, czyli gdy warstwa wizualna jest prawdziwym powodem, dla którego w ogóle rozważasz to narzędzie.

Dokploy. Wybierz je, gdy chcesz wdrażania w stylu PaaS i nie potrzebujesz surowej kontroli nad Compose.

GitHub Actions + SSH. Zostań przy tym, gdy chodzi o jedną usługę na jednym hoście i nie potrzebujesz uzgadniania ani naprawy dryfu.

Dla osób w tym obszarze pośrednim, po Watchtowerze a przed Kubernetesem, Doco CD to mocny lekki wybór. Moja ocena: dla nowego homelaba albo małego SaaS zacząłbym od Doco CD, dopóki pasuje praca w stylu Git na pierwszym miejscu i bez interfejsu, a przeszedłbym na Komodo, gdy scentralizowany spis, uprawnienia i widoczność floty staną się wymaganiem.

Którekolwiek narzędzie wybierzesz, uruchom je na VPS z Linuksem dobranym pod obciążenia Compose, które będzie obsługiwał. VPS z Linuksem od Cloudzy to sensowny dom dla tego zadania, z dostępem root domyślnie. A jeśli chcesz pominąć tańce z apt, możesz też wdrożyć Dockera jednym kliknięciem z naszego marketplace.

W naszym marketplace są też obrazy instalowane jednym kliknięciem dla Gitea, z którym Doco CD integruje się natywnie. Są też obrazy dla Komodo oraz dla Portainer, jeśli uznasz, że któreś z nich lepiej pasuje do tego, czego szukasz.

Często zadawane pytania

Czy Doco CD nadaje się na produkcję?

Doco CD może działać na produkcji, jeśli jego profil ryzyka pasuje do twojego obciążenia. Jest aktywnie rozwijane, ale wciąż korzysta z wersjonowania sprzed 1.0, a plik CODEOWNERS przypisuje projekt jednej osobie. Przypnij przetestowane wydanie, przetestuj aktualizacje przed wdrożeniem i przy krytycznej infrastrukturze pomyśl o szerszym nadzorze.

Jak zarządzać wieloma hostami za pomocą Doco CD?

Dla każdego hosta używaj osobnego kontekstu Dockera i osobnego celu wdrożenia. Jedna instancja Doco CD może wdrażać na wiele zdalnych hostów Dockera po SSH lub TCP, a jedna instancja na host pozostaje opcjonalnym modelem izolacji. Wybierz Komodo, jeśli potrzebujesz scentralizowanego spisu, uprawnień i widoczności całej floty.

Czym różni się tryb webhooka od trybu odpytywania?

Tryb webhooka wdraża niemal natychmiast po pushu do Gita, ale wymaga portu dostępnego z internetu albo odwrotnego proxy przed Doco CD. Tryb odpytywania sprawdza repozytorium według harmonogramu, więc wdrożenia są nieco opóźnione, za to nie trzeba wystawiać żadnego portu. Odpytywanie to prostsze ustawienie domyślne, a webhooki opłacają się, gdy pushujesz często albo potrzebujesz szybkiej informacji zwrotnej.

Jak Doco CD wypada na tle Komodo?

Doco CD jest lżejsze i pozbawione interfejsu, a wieloma hostami zarządza przez zdalne konteksty Dockera. Komodo opiera się na centralnej usłudze Core i agentach Periphery, dokładając interfejs floty oraz budowanie sterowane Gitem. Wybierz Doco CD do wdrażania Compose bez interfejsu, a Komodo wtedy, gdy liczy się scentralizowana kontrola nad flotą.

Czy Doco CD może zastąpić Watchtowera?

Dla zastosowania, o które większości użytkowników Watchtowera naprawdę chodziło, czyli „wdrażaj to, co jest w Gicie, gdy Git się zmieni”, odpowiedź brzmi tak: dokładnie to robi Doco CD. Dla dosłownego modelu Watchtowera, czyli odpytywania rejestru i pobierania obrazu, gdy pojawi się nowy tag, odpowiedź brzmi nie; Doco CD wyzwala Git, a nie rejestr. Model sterowany Gitem jest bezpieczniejszym i łatwiejszym do audytu wyborem dla wszystkiego poza zabawkowymi usługami.