プッシュのたびに同じ儀式が始まります。SSH でログインし、リポジトリを取得し、Compose スタックを立ち上げ直し、何も壊れていないことを祈り、マイグレーションを実行したかどうか思い出そうとする。この手作業のループは、再現可能なデプロイ、稼働中の構成の明確な記録、あるいはドリフトからの復旧が必要になるまでは通用します。
Doco CD はその直接的な答えのひとつです。Git リポジトリを監視し、プッシュに応じて Compose の変更を適用する小さな Go 製サービスで、webhook かポーリングかは自由に選べます。ArgoCD や Flux は同じことを Kubernetes 上で行いますが、Doco CD はコントロールプレーンを必要としないため Kubernetes を回避します。
このレビューでは、Doco CD ができること、できないこと、そして Komodo、Portainer の GitOps モード、Dokploy、素の GitHub Actions + SSH スクリプトと比べてどうかを取り上げます。読み終える頃には、自分の環境に合うかどうか、合わない場合は何を選ぶべきかが分かるはずです。
要約
- Doco CD は Compose ネイティブの極小 GitOps エージェントです。Git リポジトリ（GitHub、GitLab、Gitea、Forgejo など）を監視し、変更があればスタックを目標状態に合わせます。
- 外部シークレットプロバイダーの標準サポートと SOPS ベースの暗号化こそが、自作のデプロイスクリプトとの決定的な差です。
- README によれば、本プロジェクトは自らを「Docker 向けのシンプルな Portainer や ArgoCD の代替」と位置づけています。おおむね妥当な言い方です。
- 現実的な限界は次のとおりです。コードオーナーが 1 人、1.0 未満のバージョニング、複数ホストを束ねる管理 UI がないこと、そして次のポーリングか webhook イベントを待って初めて再構築される調整状態です。
- Compose のホストが 1 台か数台で、UI なしに Git を信頼できる唯一の情報源にしたいなら、これを選んでください。台数が多いなら Komodo、UI が欲しいなら Portainer、PaaS のような感覚が欲しいなら Dokploy、本当に 1 台のホストで 1 サービスだけなら GitHub Actions + SSH です。
Doco CD が埋めようとしている空白
2026 年に Docker Compose を運用している人には、奇妙な中間地帯があります。Argo CD や Flux といった主要な GitOps ツールは Kubernetes を対象としており、Watchtower のレジストリをポーリングする方式は、バージョン管理された Compose の状態を適用するのではなくイメージの変更に反応するだけです。Watchtower の リポジトリ は 2025 年 12 月 17 日にアーカイブされ、現在はプロジェクトがメンテナンスされていない旨を明記しています。
GitHub Actions に SSH のデプロイ手順を足す方法でも動きます。1 台のホストで 1 サービスなら、それが正解です。問題は 2 台目のホストや 2 つ目のスタックを足したとき、あるいは今どのコミットがデプロイされているかを知りたくなったときに現れます。ワークフローのログは残りますが、Compose ネイティブな調整も、ドリフトからの復旧も、ホストがリポジトリと今も一致しているかを示す継続的なビューもありません。
Doco CD の売り文句は、 README にそのまま書かれているとおり「Docker 向けのシンプルな Portainer や ArgoCD の代替」です。この位置づけこそが要点で、小さく、Compose ネイティブで、Kubernetes は不要、維持すべき UI もなく、面倒を見る中央コントロールプレーンもありません。K8s を動かしておらず、動かすつもりもなかったのなら、これこそ探していたカテゴリです。
Doco CD の実際の仕組み
Doco CD は Docker コンテナ内で動く単一の Go バイナリで、Git リポジトリを監視し、リポジトリの状態が変わると Compose の変更を適用します。コンセプトはこれだけです。面白いのはデフォルト設定と連携機能のほうです。
トリガー。 モードは 2 つ、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 ファイルを探すため、1 つのリポジトリで複数のスタックを扱えます。ハイフン 3 つの行で区切った YAML ドキュメントとして、1 つの設定ファイルに複数のデプロイ構成を書くこともできます。クリーンアップのデフォルトは慎重な設定になっており、頼りにする前に目を通しておく価値があります。
| 設定 | デフォルト | 意味 |
|---|---|---|
delete | false | アプリが作業ディレクトリから消えても、古いデプロイはそのまま残されます。 |
remove_volumes | false | 自動検出されたスタックを削除しても、ボリュームは残ります。 |
remove_images | true | 自動検出されたスタックを削除すると、未使用のイメージは削除されます。 |
つまり、自分で削除を有効にするまでは背後で何かが取り壊されることはなく、有効にした後でもデータボリュームが消えるのは最後です。
対応している Git プロバイダー。 GitHub、GitLab、Gitea、Forgejo、Gogs、Azure DevOps に対応しています。webhook については Azure DevOps が例外で、Azure Service Hooks がサポートされていないためです。コードホスティングを自前で運用しているなら、Gitea と Forgejo への対応が効いてきます。
Docker Swarm。 デプロイ先としてサポートされています。 デプロイ設定のページ デプロイ設定のページが明示している点は次のとおりです。Swarm モードでの調整はコンテナの再起動やヘルス状態を確認せず、Swarm ではイメージの整理もサポートされません。Swarm を対象にするなら、デプロイは手に入りますが、完全なヘルス調整は手に入りません。
状態の調整。 デフォルトでは 300 秒のウィンドウ内で再起動は 5 回までという制限があり、不安定なヘルスチェックが延々とループするのを防ぎます。同じリポジトリで参照が異なる場合は順番に、同じリポジトリで参照も同じ場合は並列に実行されます。最後の点は地味ですが便利で、同じ参照に対する複数のデプロイが互いの後ろで順番待ちになりません。
組み込みの外部シークレットプロバイダー。 素のデプロイスクリプトではなく Doco CD を検討する理由として、これはかなり強い部類です。AWS Secrets Manager、Bitwarden Secrets Manager、Bitwarden Vault / Vaultwarden、1Password、1Password Connect、Infisical、OpenBao、Webhook に対応しています。さらに別枠で、機密性の高いデプロイデータ向けに SOPS ベースの暗号化もサポートします。おかげで、シークレット解決の仕組みを丸ごと自作しなくても、Git 上の平文 env ファイルから無理なく卒業できます。
その他。 Doco CD は Prometheus メトリクス、ジョブスケジューリング、通知、distroless なコンテナイメージ、そして Apache-2.0 ライセンスを提供します。 リリース履歴リリース履歴によれば、2026 年 8 月 20 日時点で最新の安定版は v0.109.2、最新のプレリリースは v0.110.0-rc.1 です。
Doco CD の仕事は「マニフェストを適用する」ところで終わり、そこから先は通常の Docker です。 Compose 自身のログコマンド を使って、稼働中の内容を確認することになります。
シークレットに関する実践的なヒント。プライベートリポジトリにまだ平文の env ファイルが残っているなら、Doco CD の外部シークレットプロバイダーか SOPS 対応を優先しましょう。目的は単純で、平文の秘密情報を Git の外に出しつつ、デプロイ時には値を解決できる状態を保つことです。
root権限、NVMe、AMD EPYCのパワーを備えたLinux VPSで開発を。
Linuxプランを見るDoco CD の弱いところ
どんなツールにも限界はあり、Doco CD の限界は、週末を丸ごと設定に費やす前に知っておく価値があります。
コードオーナーが 1 人。 リポジトリの CODEOWNERS ファイル は、すべてのパスを kimdre に割り当てています。リリースの頻度は依然として高いものの、統治は 1 人に集中しています。
1.0 未満。 Doco CD はいまも 0.x のバージョニングを使っているため、検証済みのリリースを固定し、展開前にアップグレードノートを読んでおきましょう。クローズ済みの GitHub issue #851 がその理由をよく示しています。Docker v29 によって、プロジェクトは非推奨となった Docker の Go モジュールから離れる必要に迫られました。
Doco CD のコンテナにはシェルがない。 セキュリティ上の理由から、Doco CD はシェル環境を提供せず、ホスト上で任意のスクリプトも実行しません。デプロイ前後の処理は init コンテナ、サイドカー、または Compose のライフサイクルフックを経由する必要があり、デプロイスクリプトをそのまま実行するツールに比べて設定の手間が増えます。
再起動で状態が失われる。 調整状態はメモリ上にあります。Doco CD が再起動すると、その状態は次のポーリングか webhook イベントを待って初めて再構築されるため、空白の長さはポーリング間隔や次の webhook がどれだけ早く届くかで決まります。
複数ホストを束ねる管理 UI がない。 マルチホスト運用は、もはやホストごとにエージェントを置く必要がありません。v0.102.0 以降、デプロイ構成は リモートの Docker コンテキストを対象にできるようになりました。SSH コンテキストも含まれ、1 つのリポジトリで複数のデプロイ先を定義できます。ホストごとに Doco CD のインスタンスを 1 つ置く運用も依然として有効ですが、いまでは中央のインスタンスからリモートの Docker ホストへデプロイできます。それでも Doco CD に欠けているのは、Komodo のようなフリート管理 UI と、ホストの一元的な台帳です。
RAM と CPU の使用量は数値で文書化されていない。 公式ドキュメントは要件を「ごくわずか」と表現していますが、基準となる数値は公開していません。VPS のサイズはその上で動かすアプリケーションに合わせて決め、運用上の余裕を残し、Doco CD の実際の使用量は自分の環境で確かめてください。
マルチホストに関する実践的なヒント。ホストごとに別々の Docker コンテキストとデプロイ先を用意し、SSH アクセスを制限し、webhook や API のシークレットは重複させないでください。エージェントを分離しておきたいなら、ホストごとに Doco CD のインスタンスを 1 つ置く方式も依然として有効です。
Doco CD と代替ツールの比較
候補に挙げる残り 4 つのツールは、いずれも「Git から Compose を自動デプロイする」という同じ課題に取り組んでいますが、トレードオフはまるで違います。決めるべきは、やるかどうかではありません。それはもう決まっています。決めるべきは、どんな形のツールが自分の環境に合うかです。以下が横並びの比較です。
| ツール | トリガー | マルチホストモデル | シークレット | Webユーザーインターフェース | ライセンス |
|---|---|---|---|---|---|
| Doco CD | webhook またはポーリング | リモートの Docker コンテキスト、フリート UI なし | 外部プロバイダーと SOPS | なし | Apache-2.0 |
| Komodo | webhook とスケジュール同期 | 中央の Core と Periphery エージェント | 変数とシークレットの管理 | あり | GPL-3.0 |
| Portainer（CE/BE） | webhook またはポーリング | Portainer エージェント | 限定的、BE ではより多くの選択肢 | あり | Zlib、BE は商用ライセンス |
| Dokploy | プッシュで起動 | マルチサーバーまたは Docker Swarm | 組み込みの環境管理 | あり | Apache-2.0、一部にプロプライエタリな構成要素あり |
| GitHub Actions + SSH | プッシュで起動 | スクリプト次第 | スクリプト次第 | なし | 該当なし |
それぞれについて簡単に。表が形を示し、コメントが理由を示すからです。
Komodo。 マルチホスト向けの本格的な選択肢です。中央の Core サービスに加えて各ホストに Periphery エージェントを置き、すべてを 1 つの UI から見渡せ、デプロイに加えて Git 駆動のビルドもでき、Docker Swarm にも対応します。データベースとコントロールプレーンを動かすぶん構築は重くなりますが、台数が多いならこれが正しい形です。台数を一元管理したいなら Komodo のほうが向いています。
GitOps を有効にした Portainer（CE または BE）。 Git 同期の上に載る本格的なグラフィカル UI です。チームが CD と並行してクリック操作でコンテナ管理をしたい場合の正解です。どのみち誰かが UI でログを眺めたりコンテナを再起動したりするなら、CD も同じ場所にあってよいでしょう。リソース消費は Doco CD より重くなります。OIDC/SSO ときめ細かい RBAC は有料の Business Edition に囲い込まれています。この点については、 Portainer の代替ツールガイド では、より広い Docker 管理の全体像を扱っています。
Dokploy。 PaaS 的なスタイルです。方針がはっきりしていて、プッシュすれば自動でデプロイし、あらゆる操作に Web UI があり、Traefik ときれいな URL 構成を最初から用意してくれます。Heroku のような感触を求め、その代わりに Compose の生の柔軟性を手放してよいチームに向いています。YAML アレルギーなら、「git push すればアプリが上がる」への最も軽い道はこれです。
GitHub Actions + SSH。 追加のインフラはゼロです。デプロイジョブは、すでに持っているワークフローの中に収まります。ワークフローのログは手に入りますが、Compose ネイティブな調整も、ドリフトからの復旧も、ホスト状態の継続的なビューもありません。自分で作らない限りは。1 台のホストで 1 サービスなら十分です。2 つ目のデプロイ先が増えたとき、あるいは SSH で入らずに何がどこで動いているか知りたくなったときに破綻します。最もシンプルな層の読者にとっては、GitHub Actions + SSH がいまも正解です。
より新しい参入者として stackd という名前のツールがあり、「Kubernetes 税なしの GitOps」という似た言い回しで自らを位置づけています。この分野が活発だと知っておく価値はありますが、今日の時点でコイントスのノリで Doco CD より優先するほどではありません。
Doco CD が正解になるとき（ならないとき）
次のような場合に Doco CD を選びましょう。
- Docker Compose のホストが 1 台か数台で、Git を信頼できる唯一の情報源にしたい。
- UI をクリックして回るより、エディタで YAML を編集するほうが好みだ。
- 外部シークレットプロバイダー対応と SOPS ベースの暗号化を、仕組みを丸ごと自作せずに手に入れたい。
- メンテナが 1 人で 1.0 未満、それでも活発に開発されているプロジェクトでも構わない。
Komodo。 多数のホストを管理していて一元的な統制が欲しいとき、あるいはデプロイだけでなく Git 駆動のビルドも同じ場所で行いたいときに選んでください。
Portainer（CE または BE）。 チームが CD と並行して日々のコンテナ運用のための UI を欲しがるとき、つまり見える化そのものがこのツールを検討する本当の理由であるときに選んでください。
Dokploy。 PaaS のようなデプロイ体験が欲しく、Compose を生のまま制御する必要がないときに選んでください。
GitHub Actions + SSH。 サービスもホストも 1 つで、調整もドリフト復旧も必要ないなら、このままで構いません。
Watchtower の後、Kubernetes の手前という中間地帯にいる人にとって、Doco CD は軽量ながら有力な選択肢です。私の見立てはこうです。新しいホームラボや小規模な SaaS なら、Git 中心で UI なしの運用が合っているうちは Doco CD から始め、一元的な台帳、権限管理、全体の可視性が要件になった時点で Komodo に移ります。
どのツールを選ぶにせよ、そこで動かす Compose のワークロードに見合ったサイズの Linux VPS で運用してください。 CloudzyのLinux VPS はそのための無理のない置き場所で、標準で root アクセスが付いてきます。apt のお決まりの手順を省きたいなら、 Docker をワンクリックでデプロイ することも、マーケットプレイスから可能です。
マーケットプレイスには、ワンクリックで導入できるイメージも用意しています。 GiteaDoco CD がネイティブに連携する Gitea のほか、 Komodo や Portainerのイメージもあるので、そちらのほうが自分に合うと判断した場合はそれを選べます。
よくある質問
Doco CD は本番環境で使えますか？
リスクの度合いが自分のワークロードに見合うなら、Doco CD は本番でも使えます。開発は活発ですが、バージョニングはいまも 1.0 未満で、CODEOWNERS ファイルはプロジェクト全体を 1 人に割り当てています。検証済みのリリースを固定し、アップグレードは展開前に試し、重要なインフラであればより広い統治体制も検討してください。
Doco CD で複数のホストを管理するにはどうすればよいですか？
ホストごとに別々の Docker コンテキストとデプロイ先を用意してください。Doco CD のインスタンス 1 つで、SSH または TCP 経由で複数のリモート Docker ホストにデプロイできます。ホストごとに 1 インスタンスという構成も、任意の分離モデルとして残っています。一元的な台帳、権限管理、全体の可視性が必要なら Komodo を選んでください。
webhook モードとポーリングモードの違いは何ですか？
webhook モードは Git にプッシュされた時点でほぼ即座にデプロイしますが、インターネットから到達できるポート、もしくは Doco CD の前段のリバースプロキシが必要です。ポーリングモードはスケジュールに従ってリポジトリを確認するため、デプロイはわずかに遅れる代わりにポートを公開せずに済みます。ポーリングのほうがシンプルなデフォルトで、頻繁にプッシュする場合や素早いフィードバックが必要な場合には webhook を使う価値があります。
Doco CD は Komodo と比べてどうですか？
Doco CD のほうが軽く UI もなく、リモートの Docker コンテキストを通じて複数ホストを扱えます。Komodo は中央の Core サービスと Periphery エージェントを使い、そこにフリート UI と Git 駆動のビルドを加えます。UI なしで Compose をデプロイしたいなら Doco CD、台数を一元的に統制したいなら Komodo です。
Doco CD は Watchtower の代わりになりますか？
Watchtower の利用者の多くが本当に求めていた用途、つまり「Git が変わったら Git にあるものをデプロイする」であれば、答えは「はい」です。まさにそれが Doco CD の仕事です。一方、Watchtower の文字どおりの仕組み、つまりレジストリをポーリングして新しいイメージタグが現れたら取得する、という点では「いいえ」です。Doco CD の起点はレジストリではなく Git だからです。おもちゃレベルを超えるサービスであれば、Git を起点とする方式のほうが安全で監査もしやすい選択です。
