Setiap push mengulang ritual yang sama: masuk lewat SSH, tarik repo, hidupkan lagi stack Compose, berharap tidak ada yang rusak, lalu berusaha mengingat apakah migrasi sudah dijalankan. Lingkaran manual itu masih jalan sampai Anda butuh deployment yang bisa diulang, catatan jelas tentang apa yang sedang berjalan, atau pemulihan dari drift.
Doco CD adalah salah satu jawaban langsungnya. Ini layanan Go kecil yang memantau repo Git Anda dan menerapkan perubahan Compose saat Anda push: webhook atau polling, terserah Anda. ArgoCD dan Flux melakukan ini untuk Kubernetes, tetapi Doco CD melewati Kubernetes karena tidak butuh control plane.
Ulasan ini membahas apa yang bisa dan tidak bisa dilakukan Doco CD, serta bagaimana ia dibandingkan dengan Komodo, mode GitOps Portainer, Dokploy, dan skrip GitHub Actions + SSH biasa. Di akhir, Anda akan tahu apakah ia cocok untuk setup Anda dan apa yang harus dipilih jika tidak.
TL;DR
- Doco CD adalah agen GitOps mungil yang asli untuk Compose: ia memantau repo Git (GitHub, GitLab, Gitea, Forgejo, dan lainnya) lalu menyelaraskan stack Anda saat ada perubahan.
- Dukungan bawaan untuk penyedia secret eksternal, ditambah enkripsi berbasis SOPS, adalah pembedanya dibanding menulis skrip deployment sendiri.
- Menurut README-nya, ia memosisikan diri sebagai "alternatif sederhana untuk Portainer atau ArgoCD di Docker". Kerangka itu kurang lebih tepat.
- Batasan yang sebenarnya: satu pemilik kode, penomoran versi pra-1.0, tidak ada UI manajemen armada, dan status rekonsiliasi yang baru dibangun ulang setelah polling atau event webhook berikutnya.
- Pilih ini kalau Anda menjalankan satu atau beberapa host Compose dan ingin Git jadi sumber kebenaran tanpa UI. Pilih Komodo untuk armada server, Portainer kalau Anda mau UI, Dokploy untuk rasa PaaS, atau GitHub Actions + SSH kalau memang cuma satu layanan di satu host.
Celah yang Coba Diisi Doco CD
Ada wilayah tengah yang aneh bagi siapa pun yang menjalankan Docker Compose di 2026. Perkakas GitOps besar seperti Argo CD dan Flux menyasar Kubernetes, sementara model polling registry milik Watchtower bereaksi terhadap perubahan image alih-alih menerapkan state Compose yang terversi. Adapun repositori diarsipkan pada 17 Desember 2025 dan kini menyatakan bahwa proyek tersebut tidak lagi dipelihara.
GitHub Actions ditambah langkah deploy lewat SSH memang jalan. Untuk satu layanan di satu host, itu pilihan yang tepat. Masalahnya muncul saat Anda menambah host kedua, stack kedua, atau ingin tahu commit mana yang sedang ter-deploy. Log workflow tetap ada, tapi tidak ada rekonsiliasi khas Compose, tidak ada pemulihan drift, dan tidak ada tampilan permanen apakah host masih cocok dengan repo.
Klaim Doco CD, langsung dari READMEadalah "alternatif sederhana untuk Portainer atau ArgoCD di Docker". Kerangka itulah intinya: kecil, asli untuk Compose, tanpa Kubernetes, tanpa UI yang harus dirawat, tanpa control plane pusat yang harus dijaga. Kalau Anda tidak menjalankan K8s dan memang tidak ingin, inilah kategori yang Anda cari.
Cara Kerja Doco CD Sebenarnya
Doco CD adalah satu biner Go yang berjalan di dalam kontainer Docker, memantau repositori Git, lalu menerapkan perubahan Compose ketika state repositori berubah. Itu seluruh konsepnya. Bagian menariknya ada pada nilai bawaan dan integrasinya.
Pemicu. Ada dua mode: webhook atau polling. Webhook nyaris seketika tetapi butuh port terbuka, atau lebih realistis lagi sebuah reverse proxy di depan Doco CD. Polling adalah pengambilan berkala: sedikit terlambat, tanpa perlu port masuk. Polling adalah bawaan yang lebih sederhana, dan menurut dokumentasi resmi keduanya sama-sama kelas satu. Pilih berdasarkan apakah host Anda punya endpoint publik yang bisa dijangkau dan seberapa cepat Anda butuh deployment.
Konfigurasi per repo. Berkas .doco-cd.yaml (atau .doco-cd.yml) diletakkan di akar repo, bersebelahan dengan berkas Compose Anda. Satu-satunya kolom wajib adalah nama deployment. Konfigurasi paling minim tampak seperti ini:
# .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
Itulah nilai bawaan yang terdokumentasi: batas waktu 180 detik, kontainer yatim dihapus, image dipangkas, dan tanpa force-recreate.
Penemuan otomatis. Saat penemuan otomatis aktif, Doco CD memindai subdirektori untuk mencari berkas Compose, sehingga satu repo bisa memuat banyak stack. Ia juga mendukung beberapa konfigurasi deployment dalam satu berkas, ditulis sebagai dokumen YAML yang dipisahkan baris tiga tanda hubung. Nilai bawaan untuk pembersihan bersifat konservatif, dan layak dibaca sebelum Anda bergantung padanya:
| Pengaturan | Bawaan | Apa artinya |
|---|---|---|
delete | false | Deployment usang dibiarkan apa adanya ketika aplikasinya hilang dari direktori kerja. |
remove_volumes | false | Volume tetap ada ketika stack hasil penemuan otomatis dihapus. |
remove_images | true | Image yang tidak terpakai dihapus ketika stack hasil penemuan otomatis dihapus. |
Dengan kata lain, tidak ada yang dibongkar di belakang Anda sampai Anda sendiri menyalakan penghapusan, dan bahkan setelah itu volume data Anda yang terakhir hilang.
Penyedia Git yang didukung. GitHub, GitLab, Gitea, Forgejo, Gogs, dan Azure DevOps didukung. Azure DevOps jadi pengecualian untuk webhook, karena Azure Service Hooks tidak didukung. Dukungan Gitea dan Forgejo penting kalau Anda meng-hosting forge sendiri.
Docker Swarm. Didukung sebagai target. Yang halaman pengaturan deployment ditandai secara eksplisit: rekonsiliasi dalam mode Swarm tidak memeriksa restart kontainer maupun status kesehatan, dan pemangkasan image tidak didukung di Swarm. Kalau target Anda Swarm, Anda mendapat deployment tetapi bukan rekonsiliasi kesehatan penuh.
Rekonsiliasi. Secara bawaan ada batas 5 restart dalam jendela 300 detik, yang ada untuk mencegah health check yang labil berputar tanpa henti. Repo yang sama dengan ref berbeda berjalan berurutan; repo yang sama dengan ref yang sama berjalan paralel. Bagian terakhir itu halus tapi berguna: beberapa deployment untuk ref yang sama tidak perlu antre di belakang satu sama lain.
Penyedia secret eksternal bawaan. Ini salah satu alasan terkuat memilih Doco CD ketimbang skrip deployment biasa: ia mendukung AWS Secrets Manager, Bitwarden Secrets Manager, Bitwarden Vault / Vaultwarden, 1Password, 1Password Connect, Infisical, OpenBao, dan Webhook. Secara terpisah, ia mendukung enkripsi berbasis SOPS untuk data deployment yang sensitif. Itu memberi Anda jalan keluar yang bersih dari berkas env polos di Git, tanpa harus membangun seluruh alur pengambilan secret sendiri.
Sisanya. Doco CD menyediakan metrik Prometheus, penjadwalan job, notifikasi, image kontainer distroless, dan lisensi Apache-2.0. Menurut riwayat rilis riwayat rilisnya, per 20 Agustus 2026, v0.109.2 adalah rilis stabil terbaru dan v0.110.0-rc.1 adalah pra-rilis terbaru.
Tugas Doco CD berhenti di "terapkan manifes"; setelah itu semuanya Docker biasa. Perintah log bawaan Compose adalah cara Anda memeriksa apa yang sedang berjalan.
Tips soal secret. Kalau repo privat Anda masih menyimpan berkas env polos, dahulukan penyedia secret eksternal Doco CD atau dukungan SOPS-nya. Tujuannya sederhana: keluarkan secret polos dari Git tapi tetap biarkan deployment mengambil nilainya saat runtime.
Bangun di VPS Linux dengan akses root, NVMe, dan tenaga AMD EPYC.
Lihat Paket LinuxDi Mana Doco CD Kurang
Setiap alat punya batas, dan batas Doco CD sebaiknya Anda ketahui sebelum menghabiskan satu akhir pekan untuk memasangnya.
Satu pemilik kode. Berkas CODEOWNERS milik repositori menetapkan semua jalur ke kimdre. Aktivitas rilis tetap sering, tetapi tata kelolanya terpusat pada satu orang.
Pra-1.0. Doco CD masih memakai penomoran 0.x, jadi kunci ke rilis yang sudah teruji dan baca catatan pemutakhiran sebelum menggelarnya. isu GitHub #851 yang sudah ditutup menggambarkan alasannya: Docker v29 memaksa proyek ini meninggalkan modul Go Docker yang sudah usang.
Tidak ada shell di dalam kontainer Doco CD. Demi keamanan, Doco CD tidak menyediakan lingkungan shell dan tidak menjalankan skrip sembarangan di host. Tugas sebelum dan sesudah deployment harus lewat kontainer init, sidecar, atau hook siklus hidup Compose, yang berarti tambahan konfigurasi dibanding alat yang langsung menjalankan skrip deployment.
Kehilangan state saat restart. Status rekonsiliasi disimpan di memori. Saat Doco CD dimulai ulang, status itu baru dibangun kembali setelah polling atau event webhook berikutnya, jadi lebar jedanya bergantung pada interval polling Anda atau seberapa cepat webhook lain datang.
Tidak ada UI manajemen armada. Multi-host tidak lagi menuntut satu agen per host. Sejak v0.102.0, konfigurasi deployment bisa menyasar konteks Docker jarak jauh, termasuk konteks SSH, dan satu repositori bisa mendefinisikan beberapa target deployment. Menjalankan satu instans Doco CD per host tetap sah, tetapi kini satu instans terpusat bisa men-deploy ke host Docker jarak jauh. Yang masih belum dimiliki Doco CD adalah UI manajemen armada milik Komodo dan inventaris host terpusat.
Konsumsi RAM dan CPU tidak didokumentasikan dalam angka. Dokumentasi resmi menyebut kebutuhannya "mungil" tetapi tidak menerbitkan angka acuan. Ukur VPS sesuai aplikasi yang akan dijalankan, sisakan ruang operasional, dan validasi pemakaian Doco CD yang sebenarnya di lingkungan Anda sendiri.
Tips soal multi-host. Pakai konteks Docker dan target deployment terpisah untuk tiap host, batasi akses SSH, dan jaga agar secret webhook atau API selalu unik. Kalau Anda lebih suka agen yang terisolasi, satu instans Doco CD per host tetap sah.
Doco CD versus Alternatifnya
Empat alat lain yang akan saya masukkan ke daftar pendek sama-sama berusaha menyelesaikan "deploy Compose otomatis dari Git", tapi dengan kompromi yang sangat berbeda. Keputusannya bukan apakah akan melakukannya; itu sudah Anda putuskan. Keputusannya adalah bentuk alat mana yang cocok dengan setup Anda. Berikut perbandingan berdampingannya.
| Tool | Pemicu | Model multi-host | Secret | Antarmuka Web | Lisensi |
|---|---|---|---|---|---|
| Doco CD | Webhook atau polling | Konteks Docker jarak jauh, tanpa UI armada | Penyedia eksternal plus SOPS | Tidak ada | Apache-2.0 |
| Komodo | Webhook plus sinkronisasi terjadwal | Core terpusat plus agen Periphery | Manajemen variabel dan secret | Ya | GPL-3.0 |
| Portainer (CE/BE) | Webhook atau polling | Agen Portainer | Terbatas, lebih banyak opsi di BE | Ya | Zlib, syarat komersial untuk BE |
| Dokploy | Dipicu oleh push | Multi-server atau Docker Swarm | Manajemen environment bawaan | Ya | Apache-2.0, dengan komponen proprietary |
| GitHub Actions + SSH | Dipicu oleh push | Sesuai skrip yang Anda tulis | Sesuai skrip yang Anda tulis | Tidak ada | Tidak berlaku |
Sedikit catatan untuk masing-masing, karena tabel memberi bentuknya dan komentar memberi alasannya:
Komodo. Alternatif serius untuk banyak host. Layanan Core terpusat plus agen Periphery di setiap host, satu UI yang melihat semuanya, build yang digerakkan Git selain deployment, dan dukungan Docker Swarm. Lebih berat dipasang, karena Anda menjalankan basis data dan control plane, tetapi inilah bentuk yang tepat kalau Anda punya armada server. Komodo lebih pas ketika kendali armada terpusat memang penting.
Portainer (CE atau BE) dengan GitOps. Antarmuka grafis penuh di atas sinkronisasi Git. Pilihan yang tepat ketika tim ingin manajemen kontainer dengan klik sekaligus CD. Kalau toh ada orang yang akan membuka UI untuk melihat log dan me-restart kontainer, sekalian saja CD-nya di tempat yang sama. Konsumsi sumber dayanya lebih berat dari Doco CD. OIDC/SSO dan RBAC granular terkunci di balik Business Edition berbayar. Lanskap manajemen Docker yang lebih luas dibahas di panduan alternatif Portainer kami yang membahas lanskap manajemen Docker secara lebih luas.
Dokploy. Bergaya PaaS. Punya pendirian kuat, otomatis men-deploy saat push, punya UI web untuk segalanya, dan langsung menyiapkan Traefik plus URL yang rapi. Lebih cocok untuk tim yang mau rasa Heroku dan rela menukar fleksibilitas mentah Compose demi itu. Kalau Anda alergi YAML, ini jalur paling ringan menuju "git push, aplikasi ter-deploy".
GitHub Actions + SSH. Nol infrastruktur tambahan. Pekerjaan deploy tinggal di dalam workflow yang sudah Anda punya. Anda dapat log workflow, tetapi tidak ada rekonsiliasi khas Compose, tidak ada pemulihan drift, dan tidak ada tampilan permanen status host, kecuali Anda membangun bagian-bagian itu sendiri. Cukup untuk satu layanan di satu host. Mulai runtuh begitu Anda menambah target kedua atau ingin tahu apa yang berjalan di mana tanpa masuk lewat SSH. Untuk lapisan pembaca yang paling sederhana, GitHub Actions + SSH tetap jawaban yang benar.
Ada pendatang yang lebih baru bernama stackd , yang memosisikan diri dengan bahasa serupa: "GitOps tanpa pajak Kubernetes". Bagus untuk tahu bahwa kategori ini masih hidup, tapi belum layak dipilih di atas Doco CD dengan lempar koin hari ini.
Kapan Doco CD Jadi Pilihan Tepat (dan Kapan Tidak)
Pilih Doco CD ketika:
- Anda menjalankan satu atau beberapa host Docker Compose dan ingin Git jadi sumber kebenaran.
- Anda lebih suka mengedit YAML di editor ketimbang mengeklik-klik di UI.
- Anda mau dukungan penyedia secret eksternal dan enkripsi berbasis SOPS tanpa membangun seluruh alurnya sendiri.
- Anda tidak masalah dengan proyek bermaintainer tunggal, pra-1.0, tapi dikembangkan secara aktif.
Komodo. Pilih ini ketika Anda mengelola banyak host dan ingin kendali armada terpusat, atau ketika Anda butuh build yang digerakkan Git, bukan hanya deployment, dalam satu atap.
Portainer (CE atau BE). Pilih ini ketika tim ingin UI untuk operasi kontainer sehari-hari berdampingan dengan CD, yaitu ketika lapisan visual itulah alasan sesungguhnya Anda mempertimbangkan alat ini.
Dokploy. Pilih ini ketika Anda ingin pengalaman deploy bergaya PaaS dan tidak butuh kendali mentah atas Compose.
GitHub Actions + SSH. Tetap pakai ini ketika cuma satu layanan di satu host dan Anda tidak butuh rekonsiliasi atau pemulihan drift.
Bagi orang-orang di wilayah tengah pasca-Watchtower dan pra-Kubernetes, Doco CD adalah pilihan ringan yang kuat. Menurut saya: untuk homelab baru atau SaaS kecil, saya akan mulai dengan Doco CD selama cara kerja Git-dulu tanpa UI masih cocok, lalu pindah ke Komodo begitu inventaris terpusat, izin akses, dan visibilitas armada jadi kebutuhan.
Alat mana pun yang Anda pilih, jalankan di VPS Linux yang ukurannya disesuaikan dengan beban kerja Compose yang akan ditanggungnya. VPS Linux Cloudzy adalah rumah yang masuk akal untuk ini, dengan akses root secara bawaan. Kalau Anda ingin melewati ritual apt, Anda juga bisa men-deploy Docker dengan satu klik dari marketplace kami.
Marketplace kami juga menyediakan image satu klik untuk Gitea, yang terintegrasi secara asli dengan Doco CD. Tersedia pula image untuk Komodo juga, dan untuk Portainer, kalau Anda memutuskan salah satunya lebih sesuai dengan yang Anda cari.
Pertanyaan yang Sering Diajukan
Apakah Doco CD Siap untuk Produksi?
Doco CD bisa dipakai di produksi kalau profil risikonya cocok dengan beban kerja Anda. Ia dikembangkan secara aktif, tapi masih memakai penomoran pra-1.0 dan berkas CODEOWNERS-nya menyerahkan proyek ini kepada satu orang. Kunci ke rilis yang sudah teruji, uji pemutakhiran sebelum digelar, dan pertimbangkan tata kelola yang lebih luas untuk infrastruktur kritis.
Bagaimana Cara Mengelola Banyak Host dengan Doco CD?
Gunakan konteks Docker dan target deployment terpisah untuk tiap host. Satu instans Doco CD bisa men-deploy ke banyak host Docker jarak jauh lewat SSH atau TCP; satu instans per host tetap jadi model isolasi opsional. Pilih Komodo kalau Anda butuh inventaris terpusat, izin akses, dan visibilitas armada.
Apa Bedanya Mode Webhook dan Mode Polling?
Mode webhook men-deploy nyaris seketika saat ada push ke Git, tetapi menuntut port yang bisa diakses dari internet, atau sebuah reverse proxy di depan Doco CD. Mode polling memeriksa repo sesuai jadwal, jadi deployment sedikit terlambat tapi tidak ada port yang perlu dibuka. Polling adalah bawaan yang lebih sederhana; webhook sepadan kalau Anda sering push atau butuh umpan balik cepat.
Bagaimana Doco CD Dibandingkan dengan Komodo?
Doco CD lebih ringan dan tanpa UI, serta bisa mengelola banyak host lewat konteks Docker jarak jauh. Komodo memakai layanan Core terpusat plus agen Periphery, dan menambahkan UI armada serta build yang digerakkan Git. Pilih Doco CD untuk deployment Compose tanpa UI; pilih Komodo ketika kendali armada terpusat memang penting.
Bisakah Doco CD Menggantikan Watchtower?
Untuk kebutuhan yang sebenarnya diinginkan kebanyakan pengguna Watchtower, yaitu "deploy apa yang ada di Git, saat Git berubah", jawabannya ya, itulah yang dilakukan Doco CD. Untuk model harfiah Watchtower, yaitu memantau registry lalu menarik image begitu muncul tag baru, jawabannya tidak; Doco CD dipicu Git, bukan registry. Model yang dipicu Git lebih aman dan lebih mudah diaudit untuk apa pun yang melampaui layanan main-main.
