Portainerが方針転換：Dockerコンテナの管理に、今から代替ツールを探すべき？

Portainerは、多くのホームラボですっかりおなじみの存在です。NAS、Raspberry Pi、ミニPC、あるいはProxmoxのVMにインストールすれば、5分後にはWebインターフェースからDockerコンテナの起動、停止、更新、監視ができるようになります。

ホームオートメーションでも、とても便利です。Home Assistantはコンテナで快適に動作し、その周りにはMosquitto、Zigbee2MQTT、Node-RED、ESPHome、Frigate、InfluxDB、Grafana、AdGuard Home、Nginx Proxy Managerなどがよく使われています。あっという間に数が増えていきます。

2026年9月11日、Portainerは方針転換を発表しました。バージョン3.0はKubernetesを第一に考えて開発され、Community Editionは2.x系にとどまります。

明日の朝、Portainerをアンインストールすべきでしょうか？いいえ。でも、隣の庭で何が育っているのか見に行くには、ちょうどいいタイミングです。

Portainer 3.0：Kubernetesへ舵を切る

PortainerのCEO、Neil Cresswellがブログ記事で新たな戦略について詳しく説明しました。単なるバージョン番号の変更ではありません。

8月にリリースされたPortainer 2.45 LTSが、2.x系の最終バージョンです。3.x系は、Kubernetesを優先して開発されます。

開発元は、かなり率直に説明しています。DockerとKubernetesの差は大きくなりすぎており、Docker、Podman、Swarm、Kubernetes向けの開発を同じコードベースで並行して続けるのは、もはや現実的ではありません。エンタープライズ顧客は、セキュリティポリシー、可観測性、GitOps、AIワークロードを動かす仕組みなどを求めています。これらはすべて、DockerにはないKubernetes独自の機能（network policies、admission controllers）に依存しています。

このエコシステムを中心に、Portainer-Run、Portainer-IDP、Portainer-Command、Portainer-Operations、Portainer-AiGridなど、複数の製品が開発されています。名前だけでも方向性が伝わってきます。

ミニPCでZigbee2MQTTといくつかのサービスを動かしたいだけなら、当初のニーズからはかなり離れています。

Portainer CEがなくなるわけではない

発表後には、かなり不安をあおる見出しもありました。ここではっきりさせておきましょう。PortainerはDockerを見捨てるわけでも、Community Editionを突然打ち切るわけでもありません。

CEは2.x系にとどまり、セキュリティパッチやバグ修正の提供も続きます。またPortainerは、Docker APIに相当する機能がある3.x系の新機能を、2.x系にもバックポートすると約束しています。2.45 LTSは2027年5月までサポートされます。

現在、Portainer CEでサーバーが問題なく動いているなら、急ぐ必要はありません。

ただし、Portainer CE 3.0はリリースされません。3.x系を無料で使うには、「3 Nodes Free」プログラムを利用する必要があります。つまり、最大3ノードまで無料で使えるBusiness Editionです。Docker、Swarm、Podman環境も引き続き管理できますが、インターフェースでは優先度が下がり、新機能はまずKubernetes向けに提供され、場合によってはKubernetesだけに提供されます。

現時点では、その違いは小さく見えます。2、3年後には、もっとはっきりしているだろうと思います。

ホームオートメーションにどう関係するのか

ホームラボにとって、Kubernetesはたいてい過剰です。

Home Assistant、Mosquitto、Zigbee2MQTT、Node-RED、Frigate、そして監視用のツールが2、3個動く一般的なサーバーを考えてみてください。Docker Composeで十分です。アプリごとにファイルを用意し、データをボリュームに保存して、すべてをバックアップしたり再構築したりするためのコマンドをいくつか使えばいいのです。

管理インターフェースの最新機能を使い続けるためだけにKubernetesクラスターを構築するのは、チューリップを3本植えるのにショベルカーを持ち出すようなものです。

Portainer自身も認めているとおり、3.x系でもDockerはサポートされますが、開発の力点はKubernetesに置かれます。Kubernetesに移行する予定がないなら、こう考えるのも自然でしょう。DockerとDocker Composeを第一に考えたインターフェースはあるのでしょうか？

あります。ここ数カ月で大きく進化したものがいくつもあります。

Arcane：今、最も有力な乗り換え先かもしれない

2026年に1つだけ試すなら、これです。

Arcaneは、現代的なPortainerに期待する機能を備えています。コンテナ、イメージ、ボリューム、ネットワーク、Docker ComposeプロジェクトをWebインターフェースで管理でき、エージェントを使ってリモートマシンも管理できます。

認証にはOIDC、パスキー、二要素認証を利用できます。APIやイメージ更新の管理機能もあり、各イメージに関連するリスクを表示する脆弱性スキャナーも備えています。

開発の動きも速く、2.10から2.14までのバージョンが1カ月足らずでリリースされました。2.14.0は2026年9月26日、この記事を書いている数日前に公開されたばかりです。脆弱性に対する一括操作、刷新されたセキュリティリスク表示、各コンテナのプロセスを表示するタブが追加されました。

インストールは簡単です。Arcane自体がコンテナとして動作し、ホストのDockerソケットにアクセスします。Portainerと同様、ソケットへのアクセスはマシンのroot権限を与えるのと同じだという点を忘れないでください。そのため、十分な対策なしにインターフェースをインターネットに公開するのは避けましょう。

明日、ホームラボでPortainerを置き換えるとしたら、最初にインストールするのはこれです。

Dockge：何よりもシンプルさを重視

Dockgeも、話題に絶えず上がる名前です。

Uptime Kumaの開発者、Louis Lamによるツールで、考え方は異なります。Portainerのすべてを再現しようとはせず、Docker Composeに特化しています。無駄のないインターフェースから、スタックの作成、編集、起動、停止、更新ができます。

特に気に入っているのは、compose.yamlファイルが内部データベースの項目ではなく、ディスク上の本物のファイル（デフォルトでは/opt/stacks内）として保存される点です。好きなエディターで開くことも、昔ながらにターミナルからdocker compose up -dを実行することもできます。

バージョン1.4以降は、ほかのDockgeインスタンスにも接続できるようになり、複数マシンのスタックを同じインターフェースに表示できます。

Raspberry PiやミニPCでホームオートメーション関連のサービスを10個ほど動かすなら、実に使い心地のよいツールです。

難点は、開発ペースです。最新の安定版1.5.0は2025年3月のリリースです。問題なく動作はしますが、何年も使い続けるつもりで新規導入するなら、第一候補にするかは迷うところです。

Komodo：ホームラボに複数のサーバーがある場合に

ホームラボが大きくなってきたなら、Komodoを試す価値があります。

複数のサーバーをデプロイし、管理するために設計されています。GPLv3ライセンスのオープンソースプロジェクトで、接続できるマシンの数に制限はありません。

Docker Composeに対応し、既存のスタックをインポートしたり、Gitリポジトリから設定を取得したりできます。Gitでスタックを定義し、サーバーに自動デプロイして、リポジトリに変更があるたびに再デプロイすることも可能です。昔ながらに、Composeファイルをマシン上に直接置いておきたい場合にも対応しています。

Komodo 2ではDocker Swarmの管理、ローカルアカウント向けの二要素認証（TOTPまたはパスキー）、複数のログイン方法（ローカル、OIDC、GitHubなど）を同じアカウントに紐付ける機能、刷新されたリモートターミナルが追加されました。自動化機能も、以前から充実していました。

具体例を挙げると、ホームオートメーション用のミニPC、Frigateとカメラ用の2台目のサーバー、いくつかのサービスを動かすNAS、そして外部のVPS。Komodoなら、これらを一元管理できます。

もちろん、Dockgeより習得に時間がかかります。その分、はるかに高機能です。

Dockhand：注目の新顔

最後に紹介するのはDockhandです。最初のバージョンは2025年12月に公開され、驚くほどの速さで進化しています。

コンテナ、Composeスタック、複数のDocker環境、Gitリポジトリ、Webhookを管理できます。ボリュームやコンテナ内のファイルを閲覧したり、ネットワーク接続を表示したり、メンテナンス作業をスケジュールしたりすることも可能です。

特に際立っているのはセキュリティ機能で、セルフホスト型ツールでは珍しいものが揃っています。GrypeとTrivyでイメージを分析し、既知の脆弱性を検出できます。また、稼働中のコンテナを置き換える前に、新しいイメージをスキャンすることもできます。自動更新によって、既知の脆弱性だらけのイメージが夜中にインストールされるのを防ぐのに便利です。

バージョン1.0.50は2026年9月30日にリリースされました。

ただし、ライセンスには注意が必要です。DockhandはBusiness Source License 1.1で提供されています。個人利用や社内利用なら無料ですが、GPLやMITのプロジェクトのような意味での自由ソフトウェアではありません。たとえば、ホスト型サービスとして再販することはできません。コードは2029年にApache 2.0ライセンスへ移行します。

では、Portainerをやめるべき？

必ずしもそうではありません。

自宅のDockerサーバーでPortainer CE 2.45を使っていて、すべて問題なく動いているなら、何もかも壊して移行する理由はありません。このブランチは保守され、修正も引き続き提供されます。

ただ、この発表を受けて、長期的にこのツールをどう見るかは変わりました。PortainerはKubernetesとエンタープライズの道を選びました。開発元の立場からすれば、よく理解できます。ただ、技術スペースにミニPCと20個ほどのコンテナを置いている人にとっては、目指す方向が違うだけです。

そういう使い方をしている人に向けて、私の意見をまとめると次のとおりです。

• Arcaneは、現時点で最も現代的なPortainerに近く、活発に開発されています。
• Docker Composeを中心にしたシンプルなインターフェースが欲しく、開発ペースの鈍化が気にならないなら、Dockgeは今でも優れた選択肢です。
• 複数のサーバーを管理する場合や、GitOpsに移行したい場合には、Komodoの真価が発揮されます。
• Dockhandは非常に多機能で、特にセキュリティ面が充実しています。ライセンスが問題なければ、今後も注目したいツールです。

最も慎重な方法は、今すぐ何も移行しないことです。これらのツールのどれかをPortainerと並行してインストールし、数週間試してみましょう。どれも同じDockerデーモンに接続するため、問題なく共存できます。DockgeのFAQにも、はっきりそう書かれています。注意点は1つだけです。PortainerのWebエディターから作成したスタックは、管理できる場所にあるフォルダーではなく、Portainerのデータボリューム内に保存されます。移行する前に、Composeファイルを取り出しておきましょう。

私なら、あなたの立場でもそうします。

何年もの間、「Dockerを管理するインターフェースはどれがいい？」という質問には、ほぼ決まってPortainerという答えが返ってきました。2026年になって、ようやく本当の選択肢が生まれました。ホームラボをいじって楽しむ人にとっては、うれしい知らせです。

皆さんはどう思いますか？