使い慣れた Docker 管理 UI、幅広いランタイム対応、そして単一ホストの基本構成を超える規模にも耐えるツールが欲しいなら、Portainer は 2026 年でも良い選択です。今の構成に必要なのが基本的なコンテナ管理、Compose スタック、簡単なアクセス制御、複数環境の可視化だけであれば、Portainer CE を急いで捨てる理由はありません。
とはいえ、無料の OIDC/SSO、ファイル優先の Compose 管理、脆弱性スキャンの内蔵、あるいは Git 起点のマルチサーバー運用を、Portainer Business Edition に移らずに実現したくなった時点で、Portainer は最適解ではなくなります。本ガイドで扱う代替ツールが意味を持ってくるのは、まさにそこからです。
結論を先に言えば、Portainer が今のユースケースに合っているならそのまま使い続けてください。手作業のセットアップを省きたいなら、 Cloudzy の Portainer ワンクリックアプリ を使えば、数クリックで VPS 上に Portainer を立ち上げられます。root アクセス、NVMe ストレージ、Docker がすぐ使える環境付きです。すでに Portainer CE の限界にぶつかっているなら、この先で検討に値する代替ツールを紹介します。Dockge、Arcane、Dockhand、Komodo の 4 つです。
要約
- Dockge は、シングルノードのホームラボを運用していて、compose ファイルをディスク上にプレーンな YAML として見える形で置きたい場合に。
- Arcane は、小規模チーム向けに無料の OIDC/SSO とシングルバイナリのインストールが必要な場合に。
- Dockhand は、Portainer BE を買わずに脆弱性スキャンの内蔵と安全なイメージ取得が欲しく、BSL ライセンスを許容できる場合に。
- Komodo は、複数の VPS インスタンスにまたがって Docker を運用し、Git を信頼できる唯一の情報源にしたい場合に。
- Portainer CE は、上記のいずれも必要ない場合に。
本記事が扱わないこと
いくつかのカテゴリは意図的に比較から外しています。Coolify と Dokploy は PaaS ツールで、Docker の UI というよりセルフホスト版 Heroku を目指すものです。解こうとしている問題が違います。Rancher と OpenShift は Kubernetes のクラスタ管理ツールで、VPS が 1 台から数台という読者にはスケールが合いません。Lazydocker は優れたツールですが TUI 専用で、UX のカテゴリが異なります。他の比較記事に登場する UsulNet は、2026 年 2 月時点で開発者 1 名による初のパブリックベータ段階であり、実際のリリースサイクルを重ねてきたツールと並べて推薦するには時期尚早です。
人々が Portainer を離れる理由
Portainer から人を押し出す最初の要因は、バグではありません。チーム向け・企業向けの高度な機能の多くが Business Edition 側にあることです。たとえば次のような機能です。
- OIDC
- きめ細かい RBAC
- AD/LDAP
- GitOps
- 自動アップデート
- 監査ログ
- レジストリ管理
- Kubernetes クラスタのプロビジョニング
個人のホームラボユーザーなら、気にならないかもしれません。しかし SSO と監査証跡が必要な 3 人の運用チームにとっては、すぐに問題になります。
Portainer は Business Edition を 3 ノードまで無料で提供しています。ごく小規模な構成には確かに有用です。3 ノードを超えると、価格は問い合わせベースの領域に入ります。公開されている金額は変動し続けているため、ここで具体的な価格は挙げません。実際に購入する段階で、公式の価格ページを確認するのが正解です。
2 つ目はアーキテクチャの問題です。Portainer の Web エディタで作成したスタックは Portainer のデータベースに保存され、Git ベースのデプロイではリポジトリが外部のソースとして扱われます。ローカルで管理するすべての Compose スタックを、ホスト上の通常の YAML ファイルとして見える状態に保ちたい、という要求がなければこれで問題ありません。Dockge のようなツールは、そのファイル優先のモデルを既定にしています。Compose ファイルはディスク上に存在し、UI はすでにそこにあるものを管理するだけです。これが重要かどうかは、スタックをどう管理しバックアップしたいかによります。
3 つ目は UI の重さです。Portainer は Docker、Swarm、Kubernetes、複数環境にまたがるエージェント群まで、あらゆるものを扱えるように作られています。複雑な環境にスケールするからこそ、シングルノードのホームラボのユーザーには必要以上に重く感じられます。 Dockge に戻った経緯を綴った XDA Developers の記事 は、この点をうまく言い表しています。始めたばかりで全機能が必要なうちは Portainer が理にかなっている。構成が安定してきたら、スタックのファイルベースな形を尊重する、より小さなツールのほうが合うこともある、というわけです。

本当に競合になりうる 4 つのツール
GitHub には「Docker UI」を名乗るプロジェクトが何十とあります。その多くは放棄済みか、いまだベータか、あるいは別の問題を解いています。ここで取り上げる 4 つは、この読者層にとっての Portainer の中心的な役割、つまり 1 台から複数台の VPS ホスト上の Docker を、日常的に使える機能を備えた Web UI で管理するという役割と、最も明確に重なります。
以下では各ツールを順に取り上げ、まず何が違うのかを示したうえで、制約も明記します。
Dockge:ファイル優先の Compose 管理
Dockge の売りは、たった 1 つの設計判断に集約されます。compose スタックはデータベースではなく、ディスク上にプレーンな YAML ファイルとして存在するということです。他の設定ファイルと同じように cat でき、vim で編集でき、git commit でき、rsync できます。UI はすでにそこにあるものを見て編集するためのツールにすぎません。
作者は Louis Lam、Uptime Kuma をメンテナンスしているのと同じ人物です。Uptime Kuma は堅実で騒がしさのないメンテナンスに定評があり、Dockge もそのスタイルを受け継いでいるため、これは有用なシグナルです。最新リリースは v1.5.0(2025年3月30日)です。出典は Dockge の GitHub リリースページに掲載されています。v1.4.0 でマルチエージェント対応が初めて追加され、v1.5.0 では破壊的なセキュリティ変更が入りました。ブラウザ内の Console が既定で無効化され、必要な場合は DOCKGE_ENABLE_CONSOLE=true で再度有効にします。同じリリースで Compose も 2.34.0 に更新されました。
OIDC も RBAC も、脆弱性スキャンの内蔵も監査ログもありません。Dockge は安価版の Portainer BE を目指しているわけではないのです。単一ホスト(あるいはマルチエージェントで数台)の compose スタックを管理するための、最も小さくきれいなツールであろうとしています。
はっきり述べておくべき注意点があります。Dockge は必ずしも RAM に優しいとは限りません。2024 年 9 月から 2025 年 12 月にわたる GitHub のディスカッションスレッド には、小規模な構成で 500MB+ の使用量を報告するユーザーの声が残っており、議論は未解決のままです。リソース節約を目的に乗り換えるつもりなら、自分のホストで先に検証してください。
プロのヒント: Portainer より軽いフットプリントを期待して Dockge に乗り換えるのはやめましょう。得られるのは、ディスク上で compose ファイルが見えることと、よりシンプルな UI です。RAM が主な制約なら、決める前に検証してください。
向いている人:1 台のマシンで少数の compose スタックを動かし、YAML がディスク上に見えることを重視し、SSO やスキャンを必要としない個人のホームラボ運用者。

Arcane:無料 OIDC を備えた軽量な Go 製マネージャー
Arcane はコンパイル済みの単一 Go バイナリとして配布され、無料プランに OIDC/SSO を含み、自動再デプロイ付きの GitOps に対応しています。この 3 点の組み合わせが差別化要因です。
最新リリースは v2.4.0(2026 年 7 月 11 日)で、 Arcane の GitHub リリースに掲載されています。Arcane は相当数のリリースとコントリビューターを積み重ねており、成熟度を測るうえで有用なシグナルです。ライセンスは BSD-3-Clause、GitHub のスター数は 2026 年 7 月時点でおよそ 6,500 です。
標準で得られるもの:無料の OIDC/SSO(Portainer が有料化している機能)、リポジトリの変更時に自動再デプロイする GitOps、REST API、クリック操作を好まない人向けの CLI ツール、リモートホスト管理、そして透明性のために開発チームが公開している SBOM。
得られないのは、Dockhand 流のデプロイフローに組み込まれた脆弱性スキャンです。Arcane のアップデートのワークフローも、Dockhand の safe-pull のアプローチと同じではありません。同じ画面からイメージをスキャンし、危険な取得をブロックすることが決め手なら、依然として Dockhand のほうが明確に適しています。
向いている人:無料の SSO と、すっきりしたシングルバイナリのインストールを求める小規模チームや個人運用者。2 人のチームメイトに別々のログインを用意するためだけに Portainer を立ち上げ、OIDC が BE 限定だと気づいた経験があるなら、次に選ぶべきは明らかに Arcane です。
Dockhand:スキャン内蔵のセキュリティ重視マネージャー
Dockhand の目玉機能は、デプロイフローに組み込まれた脆弱性スキャンです。Grype と Trivy がどちらも一級の機能として動作し、さらにスキャンで問題が検出されたイメージの更新を保留する「safe-pull」モードもあります。OIDC/SSO も無料です。この組み合わせは、このリストの他のどのツールにもありません。
同時に、ここで最も若いツールでもあります。作者の Jarek Krochmalski が最初のリリースを出したのは 2025 年 12 月です。 Dockhand の GitHub リポジトリ では、最新リリースとして v1.0.37(2026 年 7 月 11 日)が掲載されています。つまり、セキュリティ機能は本物で開発も速いが、本番運用の実績という点では、ここに挙げた古参の選択肢に比べてまだ短い、ということです。
注意すべきはライセンスです。Dockhand は Business Source License 1.1 のもとで配布され、個人利用、社内利用、非営利団体、教育、評価目的は無料です。OSI 承認のオープンソースではありません。リポジトリには、ライセンスが 2029 年 1 月 1 日に Apache 2.0 へ移行することが明記されています。それまでは商用の再配布と SaaS としての再販はできません。有料の SMB 版・Enterprise 版の詳細は変わる可能性があるため、商用ライセンスが必要な場合は dockhand.pro を確認してください。
得られるもの:Grype と Trivy による脆弱性スキャン、safe-pull による保護、無料の OIDC/SSO、ロールバック付きの自動アップデート、未使用イメージとボリュームの定期クリーンアップ、Hawser という小さなエージェントを介したマルチノード管理、Web ターミナル、ファイルブラウザ、アクティビティログ。基盤となるスタックは Bun + SvelteKit、データベースは既定で SQLite、オプションで PostgreSQL、イメージは攻撃面を減らすため Wolfi ベースです。 XDA Developers の Dockhand 記事 では UI が詳しく紹介されているので、インストール前に様子を知りたい人はどうぞ。
知っておくべき点が 2 つあります。全体としては寛大な無料プランでも、RBAC と LDAP/AD は有料です。また Dockhand は Podman 環境にも対応し、脆弱性スキャンも使えるようになりましたが、Docker のほうが依然として主要かつ成熟した経路です。移行前に、自分の Podman ワークフローで必ず検証してください。
向いている人:Portainer BE を買わずに脆弱性スキャンを標準で使いたい、セキュリティ意識の高いホームラボユーザーや小規模チーム。かつ、OSI 非承認のライセンスで若いプロジェクトを運用することに抵抗がない人。

Komodo:Git 起点のマルチサーバーデプロイ
Komodo の売りは、Git を信頼できる唯一の情報源とすることと、コントロールプレーンと管理対象ホストのきれいな分離です。1 台のマシンで Komodo Core(Web UI、API、スケジューラ)を動かし、管理したい各ホストに Periphery という小さなステートレスのエージェントを配置し、スタック、ビルド、デプロイを Git リポジトリ内でコードとして定義します。
最新リリースは v2.2.0(2026 年 5 月 7 日)で、 Komodo の GitHub リリースで確認できます。バックエンドは Rust で書かれており、これは Komodo のドキュメント にある komodo_client という Rust クレートからも読み取れます。
得意なこと:自動バージョニング付きの Git からのビルドパイプライン、設定したブランチへの push で自動再デプロイされるスタック、リソース単位のきめ細かい権限管理、GitHub または Google を使った OAuth、REST + WebSocket API、リソース監視、そしてサーバー台数の上限なし。コンテナエンジンは Docker に対応し、ドキュメントによれば podman を docker にエイリアスすることで Podman も利用できます。Docker Swarm への対応は v2 で追加されました。
The setup overhead is real. Komodo needs a database (MongoDB, FerretDB, or PostgreSQL). You also have to think about networking between Core and your Periphery agents. None of this is hard if you've done it before, but it's not "docker run and go" the way Dockge is. The reward for that setup work is a deployment workflow that scales across however many VPS instances you want to run.
向いている人:複数の VPS ホストにまたがって Docker を運用し、Git を信頼できる唯一の情報源とし、リソース単位のきめ細かい権限管理と、Kubernetes に依存しないマルチサーバー運用を求める DevOps 担当者やチーム。

あなたのユースケースにはどれが合うか
手短に言います。4 つすべてを試したうえで、もし Slack の DM で構成を説明されたらこう答える、という内容が以下です。
- 個人のホームラボ、単一ホスト、compose スタックをディスク上の YAML として見たい場合: Dockge です。作者は Uptime Kuma のメンテナーでもあり、ファイル優先の設計は安定したホームラボにぴったり合いますし、UI も気に入るはずです。
- 無料の OIDC/SSO がどうしても必要な小規模チーム: Arcane です。シングルバイナリのインストール、成熟したコードベース、BSD ライセンス、GitOps の標準搭載。認証が壁になっていたなら、Portainer CE からより良いものへ移る最も簡単な乗り換え先です。
- Portainer BE に課金せず脆弱性スキャンを使いたい、セキュリティ意識の高いユーザー: Dockhand です。ただし BSL ライセンスとプロジェクトの若さは、承知のうえで選んでください。
- 複数の VPS ホストにまたがるマルチサーバー Docker、Git 起点のワークフロー: Komodo です。データベースが必要な分、確かにセットアップの手間はかかります。そしてホストが 3 台以上になれば、確かにその価値はあります。
- SSO は不要で、チームは小さく、Portainer の UI で問題ない場合: Portainer CE のままで構いません。
接戦について正直に言っておきます。セキュリティ意識の高い個人ユーザーにとって、Arcane と Dockhand の比較は本当に僅差です。Arcane には成熟度とオープンソースライセンスがあり、Dockhand にはスキャン機能があります。どちらを選んでも外れではないと思います。自分がより重視する軸で決めてください。
選ぶツールが決まり、手作業のインストールを省きたいなら、ここで取り上げたうちの 4 つ(Dockge、Arcane、Komodo、そして Portainer 自身)は、 Cloudzy のマーケットプレイスからワンクリックでデプロイでき、いずれも当社の VPS プランの詳細のいずれでも動作します。2 GB / 1 vCPU の VPS は、管理 UI と小規模なコンテナワークロードを動かす出発点として妥当です。マルチスタック構成の場合や、Komodo のデータベースを Core と並べて動かす場合は 4 GB 以上を使ってください。Dockhand はまだマーケットプレイスにありませんが、同じタイプの Linux VPS にインストールできます。 Portainer と Cosmos Cloud の比較記事 (Cloudzy ブログ)では、マーケットプレイスのもう一つの選択肢をさらに詳しく取り上げています。
| ツール | ライセンス | GitHub スター数(概算) | 無料の OIDC/SSO | 脆弱性スキャンの内蔵 | マルチノード | Compose の保存先 | メンテナー体制 |
|---|---|---|---|---|---|---|---|
| Portainer CE | Zlib | 35k+ | なし(BE のみ) | No | あり(エージェント) | DB | 企業(Portainer Inc.) |
| Dockge | MIT | 22.6k+ | No | No | あり(v1.4 以降) | ディスク上のファイル | 個人開発者(Louis Lam) |
| Arcane | BSD-3-Clause | 6.5k+ | あり | No | あり(リモートホスト) | ディスク上のファイル | 活発なコミュニティプロジェクト |
| Dockhand | BSL 1.1 | 5.2k+ | あり | あり(Grype/Trivy) | あり(Hawser エージェント) | ディスク上のファイル | 小規模で開発の速いプロジェクト |
| Komodo | GPL-3.0 | 11.7k+ | あり(OIDC/OAuth) | No | あり(Core + Periphery) | Git + DB | 活発なコミュニティプロジェクト |
結論
万能の Portainer 代替は存在しません。単一ホストでファイル優先の Compose 管理を求めるなら Dockge が最もきれいに収まり、無料の SSO なら Arcane が最も素直で強力な選択肢、脆弱性スキャンの統合では Dockhand が際立ち、複数サーバーにまたがる Git 起点のデプロイのために作られているのが Komodo です。Portainer CE がすでに要件を満たしているなら、そのまま使い続けるのも理にかなった判断です。
実際に取り除きたい制約を軸にツールを選び、本番のワークロードを移行する前に、スタックの複製で必ず検証してください。サーバーをゼロから構築せずにデプロイしたいなら、Cloudzy のマーケットプレイスと Linux VPS プランが、Portainer、Dockge、Arcane、Komodo のいずれにとっても現実的な出発点になります。
よくある質問
Portainer CE と Business Edition の違いは何ですか?
Portainer CE は無料で、Docker 環境、Compose スタック、エージェント経由の複数環境管理を含む、基本的なコンテナ管理をカバーします。Business Edition では、OAuth/SSO、きめ細かい RBAC、AD/LDAP、監査ログなど、企業向けの制御機能が追加されます。Portainer は現在、Business Edition を 3 ノードまで無料で提供しており、それを超える場合の価格は、選択するプランとノード数によって決まります。
Dockge は Portainer を完全に置き換えられますか?
SSO やきめ細かい RBAC を必要とせず、compose スタックを動かす単一の Docker ホストであれば、はい、Dockge は日々の運用をきれいにこなします。ただし Portainer の Kubernetes 対応、きめ細かい RBAC、レジストリ管理といった機能の代わりにはなりません。v1.4 で追加されたマルチエージェント対応は基本的なマルチサーバーの用途をカバーしますが、Portainer のエージェントを完全に置き換えるものではありません。
Dockge をマルチサーバーの Docker 管理に使えますか?
はい。v1.4 以降(v1.5 で改良)、Dockge は複数の Dockge インスタンスを 1 つの UI から管理できます。Portainer のエージェントモデルより軽量ですが、Komodo の Git 起点のサーバー横断ワークフローには及びません。2〜3 台なら問題ありませんが、本格的なマルチサーバー環境には Komodo のほうが適しています。
無料の OIDC/SSO を提供している Portainer の代替ツールはどれですか?
Arcane と Dockhand はどちらも無料プランに OIDC/SSO を含んでいます。Komodo も OIDC に対応しており、プロバイダー経由のログインも選べます。Dockge は OIDC に対応していません。Portainer の外部認証と SSO のオプションは Business Edition の機能です。
2026 年でも Portainer CE を使う価値はありますか?
あります。Portainer CE は現在も活発にメンテナンスされており、LTS ラインでは CVE のパッチも提供され続けています。SSO、きめ細かい RBAC、GitOps による自動アップデートが不要な構成なら、急いで移行する理由はありません。本記事で紹介した代替ツールは、CE の特定の制約にぶつかったユーザーのためのものであり、今の構成で問題なく動いているユーザーのためのものではありません。