マネージドPaaSをすでに離れたなら、VPSはプロビジョニング済みで、SSHキーは追加され、ターミナルのカーソルがインストール行で点滅しているはずです。残る唯一の問いは：実行するのは curl ... | bash Coolifyにするか、それともDokployか？
どちらのツールも1コマンドでインストールできます。どちらもGitプッシュによるデプロイ、自動SSL、Web UI、そしてDockerの上で動くリバースプロキシを提供します。興味深い違いは、本番環境で現れるものです：それぞれが標準的な docker-compose.yml、デプロイ中に何が起こるか、そして2026年にこの比較を作り変えたニュースに各プロジェクトがどう対応したか。ここでは2つのニュースが大きな比重を占めます： 2026年1月のCoolify CVE開示 そして Dokployのライセンス再編 同月の。
この記事は、勝者を決めるのではなく、各ツールを特定のユースケースに対応づけます。読み終える頃には、どちらが自分のワークフローに合うか分かっていただけるはずです。
要点まとめ
- Coolify は古く、より大きなエコシステムを持ち（GitHubスター約55k、300以上のワンクリックサービステンプレート）、アイドル時はやや重く、全体がApache 2.0で、セルフホスト側に有料ティアはありません。
- Dokploy は新しく（スター約34k）、アイドル時は軽量で、Apache 2.0のコアに加え、将来の有料機能（SSO、RBAC、監査ログ、ホワイトラベル化）を制限する別個のSource Available Licenseを備えています。
- Coolifyは現時点ではDocker Compose経由でゼロダウンタイムデプロイができません。可能なのはDockerfile、Nixpacks、または単一イメージデプロイ経由のみです。DokployはDocker Swarmを第一級モードとして提供しますが、CoolifyのSwarmは実験的とされています。
- 2026年1月のCoolify CVEはv4.0.0（April 27, 2026）で修正されています。Coolifyを更新し、ダッシュボードを公開しないようにしましょう。
どちらのツールも正解でない場合
CoolifyもDokployも、一部のセットアップには形が合いません。知っておく価値のある代替案を3つ、手短に：
- Kamal （37signals製）：1つか2つのアプリを持ち、UIを一切望まないチーム向け。ノートパソコンから
kamal deployだけ。CoolifyやDokployよりはるかにシンプルで、ダッシュボードが不要なときの正しい選択です。 - Dokku：定番の、Gitプッシュ、単一サーバーモデル。古く、スコープは小さいが、非常に安定しています。「1台のVPS上のHeroku」の元祖です。
- ベアVPS上のGitHub Actions + Docker Compose：考えうる最小のスタック。オーケストレーションUIはありませんが、その分オーケストレーションのオーバーヘッドもありません。デプロイフローが
docker compose pull && docker compose up -dCIからトリガーされる単一アプリに最適です。
あなたの形が1台のサーバー上の1つのアプリなら、CoolifyもDokployもおそらく過剰でしょう。まず上記のいずれかを試してみてください。複数のアプリ、複数のデータベース、あるいは操作にUIを必要とする非技術系メンバーのいるチームがあるなら、Coolify対Dokployの選択こそが正しい検討対象です。このカテゴリの選択肢をより広く概観するには、当社のまとめをご覧ください： ウェブ UI 付きセルフホストクラウドプラットフォーム.
CoolifyとDokployの概要
Coolify v4.0.0安定版 は長いベータ期間を経てApril 27, 2026にリリースされました。Dokployは v0.29.4 をMay 11, 2026時点で提供しています。どちらもHeroku/Render/Vercelの代替領域におけるオープンソースのセルフホスト型PaaSプロジェクトで、いずれもDockerをUI、デフォルトでHTTPSのリバースプロキシ（Traefik）、そしてGitベースのデプロイで包んでいます。
| 機能 | Coolify | Dokploy |
|---|---|---|
| 最新の安定版リリース | v4.0.0（April 27, 2026） | v0.29.4（May 11, 2026） |
| ライセンス | Apache 2.0 | Apache 2.0コア + 有料機能向けSource Available |
| 技術スタック | PHP / Laravel | TypeScript / Node.js |
| GitHubスター | ~55,000 | ~34,000 |
| 最小RAM（公式） | 2 GB | 2 GB |
| 最小CPU（公式） | 2コア | 指定なし |
| アイドルRAM（コミュニティ報告） | 500 MB – 1.2 GB | 300 – 400 MB |
| Docker Composeのゼロダウンタイム | 非対応（Dockerfile/Nixpacksのみ） | 標準的なCompose処理 |
| マルチサーバークラスタリング | Docker Swarm（実験的） | Docker Swarm（ネイティブ） |
| ARM64サポート | あり（Raspberry Pi OSを含む） | ドキュメントでは非公表 |
| ビルドシステム | Nixpacks、Dockerfile、Dockerイメージ | Nixpacks、Dockerfile、Dockerイメージ、Heroku Buildpacks、Paketo、Railpack |
| リバースプロキシ | Traefik | Traefik |
| セルフホスト監視の範囲 | 組み込みメトリクス + ログビューア | 基本的なリソースメトリクス + AIログ/ビルドエラー解析（v0.29.0以降） |
当社の見解：アイドル時のオーバーヘッドを抑えたい、ネイティブなマルチサーバー対応が欲しい、プラットフォーム固有の調整なしで標準的なDocker Compose処理が欲しいならDokployを選びましょう。より大きなワンクリックアプリのライブラリ、ARM64/Raspberry Piサポート、あるいは将来の有料ティアが控えていない純粋なApache 2.0が欲しいならCoolifyを選びましょう。
リソースフットプリントとVPSのサイジング
セルフホスト型PaaSはHerokuのコストを節約できます。しかしオーケストレーション層がアイドル時に2 GBのVPSのうち1.5 GBを食ってしまったら、デプロイする余地は何も残りません。そこで小さなサーバーでの最初の現実的な問いはこうです：1つもアプリをデプロイする前に、各ツールはどれだけのコストを要するのか？
Coolifyのアイドル時RAM使用量は有効にしている監視内容に依存し、ベースラインで5～7%のCPUフットプリントを持ち、メトリクスのスクレイプが走るとそれが急上昇します。Coolify自身のドキュメントは、3つのNode.jsアプリ、4つの静的サイト、いくつかのデータベースを動かす8 GB RAM、4コア、150 GBストレージという代表的な本番ワークロードを用いています。あなたのスタックが似た構成なら、これは妥当なサイジングの目安になります。
対照的に、Dokployははるかに軽量で動作し、何もデプロイしていないときはCPU使用率が2%を十分に下回ります。
A LogRocketの本番運用レポート 両ツールを並べて動かしたこのレポートも、同じ方向の結論に至りました： docker stop && docker start Dokployアプリでの操作はフルリビルドをトリガーしませんが、Coolifyでの同じ操作はトリガーします。それだけでも定常状態のコストはDokployに有利に傾き、特にリビルドの嵐がCPU予算を食い潰す小さめのVPSプランで顕著です。
サイジングについては、私が推奨するVPS構成はこちらです：
- Coolify、軽量ワークロード： 2 vCPU / 4 GB RAM / 120 GB NVMe is the practical starting point for Coolify plus a couple of small apps.
- Coolify、本番リファレンスワークロード： 4 vCPU / 8 GB RAM / 160 GB NVMe to match Coolify's own documented 3 Node.js + 4 static sites + databases example.
- Dokploy、軽量ワークロード： 1 vCPU / 2 GB RAM / 60 GB NVMe is comfortable for a single small app.
- Dokploy、本番向けの余裕を持たせた構成： 2 vCPU / 4 GB RAM / 120 GB NVMe gives you room for a small production stack.
ヒント：CoolifyのアイドルRAMは監視設定とともに増減します。メモリが厳しいなら、より大きなサーバーをプロビジョニングする前に、メトリクスのスクレイプ間隔を緩める（あるいは、すでにPrometheus/Grafanaを別で運用しているなら組み込み監視を完全に無効化する）とよいでしょう。
デプロイの実態：Docker Compose、Dockerfile、そしてゼロダウンタイム
多くのチームは、既存の docker-compose.yml と一つの期待を持ってこれらのツールにたどり着きます：ファイルを貼り付け、デプロイをクリックし、アプリが立ち上がるのを見る、と。各プラットフォームが標準的なComposeをどう扱うか、そして次のデプロイ中に処理中のリクエストがどうなるか、そこに実用上の違いが現れます。
CoolifyはDocker Compose、Dockerfile、Nixpacks（プロジェクトファイルから自動検出）、そして直接のDockerイメージデプロイに対応しています。ただし、明示しておく価値のある落とし穴があります：ゼロダウンタイムデプロイ（ローリングアップデート、ブルー/グリーン）はCoolifyではDockerfile、Nixpacks、または単一イメージデプロイ経由でのみ機能します。Docker Compose経由では機能しません。Coolifyのメンテナは あるGitHubディスカッション で「composeベースのデプロイでは、新しいコンテナを起動する前にすべてのコンテナが停止され、composeベースのデプロイには現在ローリングアップデートはありません」と認めています。Composeのローリング対応はv5のロードマップに載っており、v4では入りません。メンテナが提案する回避策は、Composeスタックを個別のCoolifyサービスに分割することですが、Composeファイルが実際のサービス間関係を表現している場合、これは簡単ではない移行になります。
ユーザーに直接影響する結果は、 Coolifyに関するHacker Newsのスレッドに現れています。あるオペレーターは率直にこう述べました：「アプリを更新する際、処理待ちのリクエストはすべて単に切り捨てられる」と。これは今日のComposeデプロイについて正確です。
CoolifyのCompose層は、プロジェクトが「マジック変数」と呼ぶものも追加します。つまり、ヘルパーイメージの自動注入、ネットワークの書き換え、環境のオーバーライドです。その意図はより効率的にすることですが、副作用として、ノートパソコン上ではきれいに動く docker-compose.yml がCoolify上できれいに動かすために調整を必要とすることがあります。同じ Hacker Newsのスレッド には代表的な例が浮かび上がっています：「docker-compose内に8つの変数を追加したが、認識されるのは7つだけ」。あなたのComposeスタックが小さく標準的なら、これらに遭遇しないかもしれません。大きかったり変わっていたりすれば、遭遇するでしょう。
Dokployの姿勢は異なります。LogRocketの 実践レポート は、Dokployが「既存のdocker-compose.ymlをほとんど、あるいは全く変更せずにデプロイできる」ことを見出し、Dockerのネイティブなラベルベースのルーティングモデルに近い形を保っています。同じレポートは、Dokployでのコンテナの停止/起動はフルリビルドをトリガーしないが、Coolifyでの同じ操作はトリガーする、と指摘しています。これはDokployのドキュメントによる正式な「ゼロダウンタイム保証」というより、ランタイムの挙動についての方向性を示す手がかりですが、小さめのVPSインスタンスでセルフホスターが報告する内容と一致しています。
DokployはNixpacksやDockerfileに加えて、Heroku Buildpacks、Paketo Buildpacks、Railpackもサポートしています。 heroku.yml やbuildpackベースのワークフローでHerokuから移ってくるチームにとって、それが最も抵抗の少ない道です。
このセクションの要点：既存のサービスが本物のDocker Composeスタックなら、Coolifyはデプロイ戦略を再構築するか、プッシュごとの短いダウンタイムを受け入れるかをあなたに求めます。Dokployはそうではありません。
セキュリティ：2026年1月のCoolify CVE開示
私はこの全体像をこう読み解きます：Coolifyは、更新を続け、ダッシュボードを公開インターネットにさらさなければ、今日でも安全に運用できます。この開示がプロジェクトの資格を失わせるものではありません。責任ある開示が守られ、パッチもリリースされました。それが明らかにしたのは、低権限の認証済みユーザーが利用できる攻撃対象領域が、あるべきよりも広かったということです。これはプロジェクトにとっての設計上の教訓であり、運用者にとっての運用上の教訓です：今すぐ露出モデルを引き締めましょう。
ヒント：パッチを当てた後でも、CoolifyのダッシュボードはSSHのように扱いましょう。プライベートネットワークにバインドするか、VPNの背後に置くか、 Tailscaleで前面を覆ってください。インストールスクリプトが簡単だからといって、ポート8000を公開インターネットにさらしてはいけません。
Dokployもこの種の問題から免れているわけではありません。 v0.29.3のリリースノート はDokployで特定されたセキュリティ脆弱性を認め、アップグレードと並行して実行することを前提としたセキュリティパッチスクリプトを同梱しています。攻撃対象領域は小さく、プロジェクトの歴史は短いものの、同じ運用上の規律が当てはまります：パッチが出た当日に更新し、ダッシュボードを公開インターネットに放置しないことです。
このセクションの要点：CVEの一件はCoolifyの運用慣行に対する黄信号であり、プロジェクトそのものに対する赤信号ではありません。しかし、更新の規律と、ダッシュボードをどう露出させるかについての基準を引き上げるものです。
ライセンス：何が無料で、何が有料か
DokployのライセンスはJanuary 21, 2026に再編されました。何が変わり、それがセルフホスターにとって何を意味するかをここで説明します。
Dokployは現在、 コアが標準的なApache 2.0となり、何がオープンソースで何がそうでないかをユーザーに混乱させていた、以前の非標準的に改変されたApache 2.0を置き換えました。別個のDokploy Source Available Licenseが、現在は proprietary/ ディレクトリ内のコードを統治します：ソースは閲覧可能、本番利用は有料。Dokployがこのライセンスの背後に置くとしている機能は次のとおりです：
- シングルサインオン（SSO/SAML）と高度なアクセス制御
- カスタムブランディングとホワイトラベル化
- 高可用性、オートスケーリング、ディザスタリカバリ
- 高度な監視、統合、コンプライアンス機能
プロジェクトは、既存のオープンソース機能を有料ティアに移すことは決してないと明確に約束しています。将来の有料機能は、エンタープライズの接着剤を必要とする組織を対象としています。今日でも2FAはすでにStartupティアの背後にあり、その詳細は Dokployの料金ページ.
Coolifyの状況は単純明快です。このプロジェクトは GitHub上でApache 2.0であり、セルフホスト版のすべての機能は無料です。メンテナにホスティングを任せたいチーム向けに Coolify Cloudの提供 がありますが、セルフホスト版は機能制限のない完全な製品で、今日持っていない有料ティアへのアップグレード経路もありません。
私の読み：自前のVPSでセルフホストするソロ開発者や小規模チームにとって、Dokployは実質無料であり、これからもそうあり続けます。最終的にSSO、きめ細かなRBAC、監査ログ、あるいはホワイトラベル化が必要になる組織にとって、Dokployはいずれ有料ティアへとあなたを押しやるでしょう。Coolifyはそうしません。なぜならCoolifyにはそのティアがロードマップにないからです。
クロスソースで明確にしておく価値があること：Dokployのセルフホストビルドには基本的なリソースメトリクス（CPU、メモリ、ストレージ、ネットワーク）が含まれており、v0.29.0で AIによるログとビルドエラーの解析が追加されました。Dokployの監視システムは、より高度な監視機能についてはクラウド限定です。ただし監視自体は、コンテナ以前の基本的なリソースメトリクスについては、セルフホストインストール上でもローカルで動作し続けます。
マルチサーバーとクラスタリング：実態とマーケティング
遅かれ早かれ1台のVPSでは足りなくなり、両プロジェクトともランディングページでマルチサーバー対応を目立つように宣伝しています。しかし現場の実態は同じではありません。
Coolifyの 公式スケーラビリティドキュメント はそれについて率直です：Docker Swarmのサポートは実験的とされています。標準的なマルチサーバーパターンは、SSH経由で接続された検証済みのリモートサーバーを、それらの間で共有されるDocker Registryと、サーバーごとに動作するTraefikインスタンスとともに用います。Swarmモードは、同じアーキテクチャ（すべてARM、またはすべてAMD64）の最低3台のサーバーを必要とします。Kubernetesは？「計画されているだけで、まだロードマップにはないので、ETAはありません」。Coolify自身のこのページを読むと、要約すればこうです：マルチサーバーは機能し、Swarmはベータで、Kubernetesはビジョンです。
DokployはDocker Swarmを、実験的フラグなしの第一級モードとして提供します。Traefikが単一サーバー構成でもSwarm構成でもルーティングを処理します。v0.29.0のリリースでは非rootのマルチサーバー対応が追加され、これが本物のギャップ（リモートノード追加のためのroot限定SSHがもう不要）を埋めました。
今後6か月以内にマルチノードのクラスタリングが「いつかスライドの上で」ではなく実際に必要になるなら、Dokployは今日の時点でリスクの低い選択です。
このセクションの要点：クラスタリングが近い将来のロードマップにあるなら、Swarmの違いは他の軸に関わらず推奨をDokployへと傾けます。
ビルドシステムと言語サポート
Herokuから移ってくるチームが最も気にするのは、各ツールがどのbuildpackエコシステムをサポートするかでしょう。なぜならそれが、最初のデプロイの前にプロジェクトをどれだけ書き換える必要があるかを左右するからです。
Coolifyのビルド経路はNixpacks（デフォルト、プロジェクトファイルから自動検出）、Dockerfile、または事前ビルド済みのDockerイメージです。Nixpacksは一般的なケース（Node、Python、PHP、Go、Rust）には堅実ですが、自動検出には粗さがあります。あなたのスタックでは検証する価値があります：両方を持つLaravelプロジェクトに影響する2026年1月のNixpacksの問題は、 composer.json と package.json 重複するNginxのlocationブロックを生成し、上流が修正するまである種のデプロイを壊しました。
DokployはNixpacks、Dockerfile、Dockerイメージをサポートし、その上にHeroku Buildpacks、Paketo Buildpacks、Railpackを加えます。あなたのプロジェクトがすでに heroku.yml やbuildpackできれいにビルドできるなら、Dokployはそのワークフローを維持させてくれます。Coolifyは変換を求めるでしょう。
表面上は両ツールとも同じに見えます：GitHub、GitLab、BitbucketからのGitプッシュデプロイ、自動的なLet's Encrypt SSL、環境変数とデータベース管理のためのWeb UI。ビルドシステムの幅広さは、Dokployが明らかに一歩先へ伸びている数少ない点の一つです。
ワンクリックアプリのカタログ
既知のオープンソースサービス（n8n、Plausible、Supabase、Ghost、Listmonkなど、おなじみのセルフホスト常連）をデプロイしたい非技術系オペレーターにとって、ワンクリックテンプレートライブラリの大きさは本物の差別化要因です。一部のユーザーにとっては、それが性能や軽量性といった他の領域よりも重要です。
Coolifyは、AI、分析、自動化、データベース、セキュリティ、ストレージなど、おおよそ40カテゴリにわたって 300以上のワンクリックサービス を提供しています。これは群を抜いて大きなライブラリであり、Composeファイルを書かずにサービスをデプロイしたい非開発者にとっての実用的な答えです。
Dokployのテンプレートライブラリはより小さいです。現在のDokployドキュメントには明確な数が掲載されていないので、数字を示すことはしません。
実用的な答え：あなたのワークフローが「n8n、Supabase、Plausibleをそれぞれ2クリックでデプロイする」なら、Coolifyはこの軸で明快に勝ちます。自分のアプリを書いて、それをただデプロイしたいだけなら、カタログの大きさは問題にならず、他の軸が効いてきます。
選び方：ユースケース別の推奨
ここに唯一の勝者はいません。あるのは、ツールとデプロイの形との対応です：
- サービスライブラリを求める非技術系チーム： Coolify。300以上のテンプレートカタログは意味のある優位性です。
- 軽量さ + 標準的なCompose処理を求めるDockerネイティブな開発者： Dokploy。
- ARM64ハードウェア（Raspberry Pi、ARMベースのVPS）： Coolify。Dokployは現在のドキュメントでARM64サポートを宣伝していません。ARM上なら、別の確認が取れるまではCoolifyをデフォルトにしましょう。
- 今四半期に使うマルチノードクラスタリング： Dokploy。ネイティブSwarm対実験的Swarmが決め手です。
- 純粋なApache 2.0、将来の有料ティアの可能性なし： Coolify。
- Herokuから移行し、Heroku Buildpacksを維持したい： Dokploy。
- 2026年1月のCVEが心配： 更新済みのCoolify（v4.0.0以降）なら問題ありません。本当の問いはあなたの露出モデルです。ダッシュボードをプライベートネットワークやVPNにバインドできないなら、Dokployはより気の楽な選択です：攻撃対象領域が小さく、高深刻度の開示の歴史も短いからです。
いずれかのツールをデプロイすることについての注記
選んだら、インストール自体はどちらのプロジェクトでも1コマンドですが、知っておく価値のある近道があります。CoolifyもDokployも マーケットプレイスでワンクリックデプロイとして利用でき、Ubuntu 24.04とDockerがプリインストール済みで、ダッシュボードもすでにアクセス可能です。手動セットアップを省きたいなら、 Coolify と Dokploy のマーケットプレイス掲載が最速の道です。きれいなOSから始めて公式インストーラを自分で実行したいなら、両プロジェクトとも1行のスクリプトを公開しています。プロビジョニングのワークフローに合う方を選んでください。
よくある質問
2026年のライセンス変更後、Dokployはまだオープンソースか？
コアプラットフォームについてははい。January 21, 2026より、Dokployのコアは標準的なApache 2.0です。別個のDokploy Source Available Licenseが現在 proprietary/ ディレクトリ内のコードを統治し、現時点では将来のエンタープライズ機能（SSO/SAML、きめ細かなRBAC、監査ログ、ホワイトラベル化）に範囲が限定されています。ソロや小規模チームのセルフホスト利用にとって、Dokployは実質的にオープンソースです。
2026年1月のCoolifyセキュリティ脆弱性はまだ懸念事項か？
開示された11件のCVEはCoolify v4.0.0（April 27, 2026リリース）で修正されています。v4.0.0以降を実行しているなら、開示された脆弱性は対処済みです。残るのは露出の問題です：Coolifyを更新し続け、ダッシュボードを公開インターネットにさらさないこと。プライベートネットワークにバインドするか、VPNの背後に置きましょう。
