Arcaneは2026年6月7日、v2.0.0リリースで完全なロールベースアクセス制御を出荷しました。設定したスケジュールで既知の脆弱性に対するイメージスキャンも行います。Brandon Leeが2025年12月29日にArcaneのファーストインプレッション記事を公開した時点では、どちらも存在しませんでした。RBACリリースの5か月あまり前のことです。
このギャップが、いま時点のあらゆるArcane Dockerレビューの厄介な部分です。ツールはすでにv2.10.2に達しており、2026年9月5日にリリースされました。v2.9.0から2週間も経っていません。v2.10.0リリースでは後述するGitOpsのクローン漏れが修正され、実行中コンテナ向けの実験的なConvert to Composeワークフローが追加されました。数日前に書かれた機能一覧ですら、別の製品を説明していることになります。
要約
v2.10.2のArcaneは、条件の合う運用者にとって実用に足るPortainerの代替です。完全なRBAC、OIDCシングルサインオン、Trivyによる脆弱性スキャン、GitOpsによる再デプロイを、無料かつノード数の上限なしで提供します。Portainerは3ノードを超えるとこのロール階層をBusiness Editionに留めています。 5 段階で 4。 足を引っ張っているのは実績の短さであって、能力ではありません。
- Portainerの3ノード目を超え、誰が何に触れられるかを絞るロールが必要になったら乗り換えどきです。 6つの組み込みロール、カスタムロール、環境ごとの割り当て、OIDCグループクレームのマッピングが、無料かつ従量課金なしで手に入ります。
- 脆弱性スキャンは標準搭載です。 Arcaneはオープンソースのイメージスキャナ「Trivy」をcronスケジュールで実行し、結果をイメージごとに保存します。
- Portainer Business Editionは3ノードまで無料で、機能制限はありません。 その範囲内ならRBACもSSOもすでに使えるため、Arcaneの「無料でアクセス制御」という主張はかなり弱くなります。
- Portainerスタックの直接インポートは依然として存在しません。 v2.10.0では実行中のコンテナを実験的にComposeプロジェクトへ変換でき、手作業は一部減ります。それでも生成されたYAMLの確認と切り替えの計画は必要です。元のコンテナが動いている間は、名前や公開ポートが衝突するからです。まずボリュームをバックアップしてください。
- 本番前に
ENCRYPTION_KEYを固め、APP_URLを正しく設定してください。ENCRYPTION_KEYには依然として開発用のデフォルト値が入っており、パスキーによるサインインはAPP_URLがユーザーが実際にアクセスするHTTPSホスト名を指すまで機能しません。JWT_SECRETは現行のインストールドキュメントによると、もう使われていません。 - v2.8.0とv2.9.0で報告されたGitOpsのディスク枯渇バグはv2.10.0で修正済みです。 この修正は、残ったGitクローンの一時ディレクトリをマネージャーホストに溜め込むのではなく、削除するようにしたものです。
- LDAPは依然としてありません。 ID連携はOIDCのみです。
この評価の作り方： これは証拠に基づくレビューであり、実機テストではありません。スポンサーなし、報酬なし、製品提供なし、メンテナーとの接触なし。機能に関する主張はすべてArcaneの現行ドキュメントとリリースノートで確認し、信頼性に関する主張はすべてプロジェクトの公開トラッカーにある日付付きのIssue、または自身の環境について書いている実名の運用者に辿れます。この記事を書くためにArcaneを動かした人はいないので、それが判断の限界になる部分（インターフェースの使い心地、継続的な負荷への耐性）については、推測せずにその旨を明記しています。
ArcaneがPortainerにはない形で無料提供しているものは？
主に1つ、完全なロールベースアクセス制御です。Portainer CEには基本的なユーザー管理しかなく、ロール階層はBusiness Editionの機能です。Arcaneはこれをノード数を問わず無料で提供し、Trivyスキャン、GitOps再デプロイ、Swarm対応、パスキーサインイン、リモートエージェント、v2.9.0で追加されたS3バックアップも揃えています。
RBACはじっくり見る価値のある部分です。「RBACがある」という言葉は、まったく異なる中身を指すことがあるからです。 Arcaneのアクセス制御ドキュメント には、変更不可の組み込みロールが6つ記載されています：Admin、Editor、No-Shell Editor、Deployer、Monitor、Viewer。どれでもカスタムロールに複製して権限を個別にチェックでき、権限は <resource>:<action> という形式に従います。例えば containers:startです。割り当てはグローバルまたは環境単位で、1人のユーザーが複数を同時に持てます。ドキュメントには次の例が直接示されています： 本番ではEditor、ステージングではViewer.
SSO展開で重要なのは、ロール割り当てをIDプロバイダー側から駆動できる点です。「ログインのたびにArcaneはユーザーのグループクレームを読み取り、OIDC由来の割り当てを再同期する」とあり、複数のマッピング済みグループに属するユーザーはその和集合を得ます。これはPortainer CEには一度もなかった権限モデルです。
脆弱性スキャンが2つ目の要素です。 Arcaneのスキャンドキュメント には「スキャンはオプトインで、cronスケジュールで実行され、結果はイメージごとに保存される」とあり、結果はUIに表示されます。デフォルトは毎日深夜0時で、 trivyIgnoreUnfixed を使うと修正版が存在する脆弱性に結果を絞れます。Trivyはバージョン固定のツールイメージに同梱されるため、スキャナの更新を自分で追う必要はありません。
次に対抗要素です。これは大きい。 Portainer自身のCE対BEページ には、Business Editionは「3ノードまで永久無料。トライアル期間なし。クレジットカード不要。機能制限なし」と書かれています。これはBEのフルセットです：独自のロール階層を持つRBAC、OIDC、Syslogエクスポート付きの監査ログ、高度なGitOps。 Take 3の条件 では、3ノード以下に留まる限り、1年ライセンスが毎年無料で更新されます。
つまり無料枠の損得がArcane有利に傾くのは4ノード目からです。それ以下では有料の壁は存在しません。1〜2ノードでもArcaneには利点があります。ライセンスキー不要、更新を覚えておく必要なし、フォークできるプロジェクトであること。ただしそれは「RBACは有料」という主張とは別物です。
ArcaneはPortainerの座を本気で狙う4つのツールのうちの1つで、他の3つは別の軸で分かれます。
いまのArcaneはどれくらい信頼できるか？
v2.9.0時点の見え方よりは良いものの、まだ若いプロジェクトです。Arcaneのバグ履歴は問題を直し続ける活発なプロジェクトのそれで、v2.8.0とv2.9.0で報告された深刻なGitOpsディスク枯渇バグは2026年8月31日のv2.10.0で修正されました。
ある運用者が2026年8月26日に報告したのは、 GitOps同期がクローンディレクトリを漏らす: "gitops-<N> クローンディレクトリが1日およそ1,000個（約9GB/日）のペースで溜まり、一度も掃除されずに最終的にディスクを埋め尽くす" という内容でした。6日間でおよそ6,467ディレクトリ、40GBに達しています。ディスクが満杯になるとマネージャーはSQLiteデータベースに書き込めなくなり再起動ループに入り、再起動回数は389回に達し、エッジエージェントの接続とAPI呼び出しも巻き込んで落ちました。このIssueはすでにクローズされ、v2.10.0には残ったGitクローン一時ディレクトリを掃除する修正が入っています。
まだv2.8.0またはv2.9.0を使っている場合： 頻繁なGitOps同期に頼る前にアップグレードしてください。クローン漏れの修正はv2.10.0で入ります。
それ以前の履歴はもっと心強いものです。 2.0から2.0.1への更新後のハング は解決済みです。 「Update Projects」がすべてのコンテナに作用する というバグ（選択したプロジェクトのコンテナだけでなくホスト上の全コンテナに影響）は、修正PR #2289のマージによってクローズされました。 イメージのポーリングが静かに動かなくなる問題 はv1.13.2で発生し、v1.14.0で修正されました。3つのバグに3つの修正です。
オープンなIssueの生の件数 は、このペースでリリースするプロジェクトについてはそれ単体ではほとんど何も語りません。誰もIssueを立てないプロジェクトが、それゆえに信頼できるわけではありません。
私の見立ては変わらず、これは能力の問題ではなく実績期間の問題です。速いリリースがあったからこそRBACとスキャンの穴が埋まり、同じ理由でv2.10.0はv2.9.0から1週間足らずで深刻なGitOps不具合を直す羽目になりました。新しいコードこそがリスクの所在で、それを採用するかは選択です。
Portainerからの移行には実際どれだけコストがかかるか？
ざっくり言えば、ダウンタイムの時間枠と多少の手作業による後片付けです。ArcaneにはまだPortainerスタックの直接インポートはありませんが、v2.10.0では実行中コンテナ向けの実験的なConvert to Composeアクションが追加されました。元のコンテナを動かしたままComposeファイルを生成するので、YAMLを組み直す作業の一部が省けます。それでもバインドマウント、ネットワーク、環境変数の値、そして切り替えそのものの確認は必要です。元のコンテナを止めるまで名前や公開ポートが衝突しうるため、これはダウンタイムゼロの移行ボタンではありません。
v2.10.0以前、プロジェクトのフォーラムは完全手動の道筋を映していました。5台のサーバーに80以上のコンテナを持つ運用者が、 ライブ移行は可能かと質問しました 。Web公開中のサービスを先に落とさずに、という意味です。すでにやり遂げた人の返答はこうでした。「既存のコンテナ（つまりPortainerのスタック）を削除してArcaneで一から作り直す以外に選択肢はありません。」その人の手順は、正常停止、バックアップ、削除、データのコピー、再作成と再デプロイでした。
実務的には、何かに触る前にボリュームをバックアップし、動かしているスタック数と移動するデータ量の両方に応じたメンテナンス枠を確保することです。コンテナの再作成はたいてい速い部分で、大きなボリュームのコピーと依存サービスを正しい順序で戻す作業が時間枠を押し広げることがあります。計画時の用語メモをひとつ：Portainerがスタックと呼ぶものを、Arcaneはプロジェクトと呼びます。
時間コストはホームラボ規模でも現れます。Moises Aguirreは2026年2月28日、 ホームラボをPortainerから移すことについて書き、それを「まる週末ぶんの作業（そして自分の悪魔と向き合うこと）」と表現しました。悪魔とは自身の管理のゆるみで、動かしているすべてのコンテナを棚卸しし、以前は「クリックして作っただけ」のサービスのためにYAMLを書く必要がありました。これは一般則ではなく彼の体験ですが、同じ形は他でも起こります。
Composeファイルを持ち込む前に押さえておきたい点がひとつあります。 v2.7.0のリリースノート では、変数解決の情報源が4つに絞られました： .env.globalにあるグローバル変数、プロジェクト自身の .env ファイル、composeファイル内に書かれたデフォルト値、そしてArcaneの環境から来るタイムゾーンとロケールです。意図された効果は、Arcane経由でデプロイしたプロジェクトが、プロジェクトディレクトリで docker compose up を実行したときと同じ方法で変数を解決することです。より正しい挙動ではあります。しかし同時に、マネージャー自身のコンテナ環境から暗黙に値を引き継いでいたものは、今後は別の値か、あるいは空に解決されることになり、しかも何の警告も出しません。
これらはどれも製品の欠陥ではありません。計画に組み込めるほど予測可能な一回限りのコストであり、移行に求めたいのはまさにそれです。
root権限、NVMe、AMD EPYCのパワーを備えたLinux VPSで開発を。
Linuxプランを見る本番前に固めておくべきものは？
暗号化キーが1つ、公開URL、そしてTLSです。Arcaneは初回起動時にデフォルトの管理者アカウントを作り、初回サインイン時にパスワード変更を強制します。妥当なデフォルトです。本番前に正しくしておくべき設定が2つあります。1つ目は ENCRYPTION_KEY、2つ目は APP_URL.
環境変数リファレンス にはいまも ENCRYPTION_KEY がデフォルト値 arcane-dev-key-32-characters!!!付きで載っていますが、インストールドキュメントは一意な32バイトの値を用意するよう求めています。本番前に変更してください。もうひとつ変わった点があります。インストールドキュメントは現在、 JWT_SECRET はもう使われていないと述べています。Arcaneはセッション署名キーを自前で生成するので、 JWT_SECRET を設定したままにしても起動時に警告が出るだけです。環境から削除してください。 インストールドキュメント には、 ENCRYPTION_KEY は「32バイト長でなければならない（生のバイト列、base64、または16進）」と明記されています。
バージョン管理の衛生もそのチェックリストに入ります。Arcaneは2026年に複数のセキュリティアドバイザリを公開しており、2026年7月29日公開の重要度「高」のアドバイザリでは、v2.5.0より前のリリースが影響を受けるとされ、委譲された users:update 権限で管理者のパスワードをリセットできてしまう問題が記載されています。修正済みリリースはv2.6.0とされているのでv2.10.0は影響を受けませんが、本番環境を古いタグに放置しない具体的な理由になります。
APP_URL のデフォルトは http://localhost:3552で、こちらには衛生面を超えた機能上の影響があります。パスキーによるサインインとパスキーMFAはどちらもWebAuthnで動作しており、 Arcaneのパスキードキュメント は明確です。「ブラウザはセキュアコンテキストでしかWebAuthn APIを公開しないため、パスキーにはHTTPS（または localhost）が必要です。」Relying Party IDは APP_URLから導出され、パスキーはそのホスト名に紐づきます。 APP_URL にホスト名が含まれていない場合、パスキーサービスは初期化されません。素のHTTPではArcaneはパスキーの操作UIを完全に隠します。IPアドレスとポートだけでデプロイすると、v2の目玉である認証機能がそこにありません。ドキュメントは端的にこう述べています。「誰かがパスキーを登録する前に、 APP_URL をユーザーが実際にアクセスするHTTPSのURLに設定してください。」
何を開放するかはリモートエージェントが決めます。 Arcaneの環境ドキュメント によれば、ダイレクトモードでは「ManagerがTCP 3553でAgentに接続する」ため、そのポートはリモートホスト側で受信可能でなければなりません。エッジモードでは「AgentがManagerへ外向きに接続する」ので、受信ポートはまったく不要です。
それ以上については、知ったかぶりをするより出典を示すほうがよいでしょう。Arcaneは ソケットプロキシのセットアップガイド を公開しており、その前提はソケットを直接マウントすると「ArcaneにDockerへの完全なアクセスを与える」ことになり、プロキシなら必要なAPI呼び出しだけに絞れる、というものです。これは Dockerソケットを隔離する価値 がどこであれ生まれるのと同じ露出であり、ここでもやる価値があります。私はこれらのドキュメントをデプロイする側の目線で読んでおり、トークン方式を監査しているわけではありません。
Arcaneにまだできないことは？
Arcaneの現行ドキュメントに照らして、まだ残る穴が2つあります。LDAPがないこと、そしてコンテナ自身のファイルシステムを見る汎用ブラウザがないことです。v2以前にあった他の穴はいくつも埋まりました。
LDAPがありません。 Arcaneのシングルサインオンドキュメント はOIDCだけを扱っており、そこにもアクセス制御ページにもLDAPやActive Directoryへの言及は一切ありません。 PortainerのBusiness Editionは対照的に「Active Directory、LDAP、およびOIDC互換のIDプロバイダー」と統合できます。組織が前段にOIDCレイヤーのないディレクトリで認証しているなら、これは回避策のない完全な行き止まりです。
コンテナ内部の汎用ファイルブラウザがありません。 Arcaneのコンテナビューは設定、マウント、ログ、Composeソースを表示しますが、コンテナ自身のファイルシステムを見るブラウザはありません。ただし現在はDockerボリューム内のファイルを閲覧・編集できるVolume Workspaceがあるため、残る穴は以前の「ファイルブラウザなし」という説明より狭くなっています。
これらの訂正は明言しておく価値があります。「RBACなし、脆弱性スキャンなし」というArcaneの説明はもはや成り立たないからです。RBACは 2026年6月7日のv2.0.0で導入され、Trivyスキャンはドキュメント化されスケジュール実行されています。アクティビティのログも進化しました。 Arcaneのアクティビティドキュメント には、プル、ビルド、ライフサイクル操作、スキャン、プルーンを網羅するActivity Centerと、重大度、種類、タイムスタンプ、そしてArcaneが特定できる範囲で各操作を行ったユーザーを記録するイベントログが記載されています。PortainerのBusinessティアのようにSyslogへエクスポートできるかどうかは、ドキュメントからは判断できません。
リリースの速さで補えないのが年季です。Arcaneのリポジトリは2025年4月に作られました。Portainerの背後には長年蓄積されたStack Overflowの回答、サードパーティのガイド、各種連携があり、夜11時に妙な問題に突き当たったときに感じるのはその差です。
誰がArcaneに乗り換えるべきで、誰がそうでないか？
Portainerで3ノードを超えていて、ライセンスの話抜きにgitで追跡するComposeとスコープ付きのマルチユーザーアクセスが欲しいなら、Arcaneに乗り換えてください。3ノード以下ならそのままで。ホストの数を数えれば、どんな機能一覧よりも速く結論が出ます。
Arcaneが明確に「はい」となる3つのプロファイル：
- Portainerの3ノード上限を超えていて、スコープ付きアクセスが必要な運用者。 3ノードを超えるとこれらの機能はPortainerでは有料、Arcaneでは無料です。ロールも十分に細かく、ある環境ではDeployer、他のすべてではViewerといった付与ができます。
- Composeファイルを唯一の正とする運用をしたい運用者。 移行の動機がスタック定義がリポジトリではなくデータベースに置かれている点にあるなら、それは好みではなく構造的な適合です。移行の週末はほとんど、すでに動かしているものを書き出す作業に費やされます。どのみち負っていた作業です。
- NAT配下を含む複数ホストを統合したい運用者。 エッジモードのエージェントはリモート側に受信ポートを必要とせず、SwarmクラスタはManagerノードから管理でき、リモート環境に費用はかかりません。
そうでない2つのプロファイル：
- 3ノード以下のすべての人。 その規模ではBusiness Editionがフル機能で無料なので、乗り換えは、すでに持っている機能を得るためにダウンタイムと週末を費やすことになります。Portainerの代替としてArcaneは有能ですが、それは移行の理由にはなりません。
- LDAPが必要な人、またはスタックを止められない人。 ディレクトリ認証は使えず、移行には依然として計画的な切り替えが必要です。どちらにも気の利いた回避策はありません。
この評価には条件が1つ付きます。GitOpsによる再デプロイが移行の主目的なら、v2.10.0以降を使ってください。v2.8.0とv2.9.0で報告されたディスク枯渇バグはそこで修正されています。
よくある質問
Arcaneは無料ですか？
はい。ArcaneはBSD-3-Clauseライセンスで無料です。有料プランもエンタープライズ版もなく、ノード数による機能制限もありません。ロールベースアクセス制御、OIDCシングルサインオン、脆弱性スキャン、リモート環境、GitOps再デプロイはすべて含まれています。唯一のコストは動かすマシンだけです。
Arcaneに必要なRAMはどれくらいですか？
プロジェクトは最低要件を公開していません。ArcaneのインストールドキュメントにはRAMやCPUの下限がなく、対応ハードウェアはx86サーバーからRaspberry Piクラスのボードまで及びます。 自身の移行を記録したある運用者 は、管理コンテナが「約150MBのRAM（Portainer）から約67MB（Arcane）」に減ったと報告しています。サイジングを決めるのは管理対象のコンテナであって、Arcaneではありません。
Arcaneは複数ホストに対応していますか？
はい、リモート環境エージェント経由で対応しています。エッジモードではエージェントがManagerへ外向きに接続するため受信ポートが不要で、NATやファイアウォールの背後にあるホストもカバーできます。ダイレクトモードでは逆にManager側から接続します。 Docker Swarmに対応しており 、Managerノードでは完全な制御、ワーカーノードでは読み取り専用ビューが使えます。
Arcaneを本番で動かしても安全ですか？
何を有効にするか次第です。初回サインイン時にデフォルトの管理者パスワードを変更し、 ENCRYPTION_KEYのデフォルト値を置き換え、ArcaneをTLSの背後に置き、正しい APP_URLを設定してください。パスキーの動作にはそれが必要です。 JWT_SECRET はもう使われておらず、v2.8.0とv2.9.0で報告されたGitOpsのクローン漏れもそこで修正されているため、本番環境はv2.10.0以降から始めるべきです。
ArcaneはDockgeやDockhandと比べてどうですか？
Dockgeはより小さくCompose専用で、スタックエディタだけが欲しいならこちらが適しています。Dockhandはイメージのセキュリティスキャンに重心を置いています。Arcaneは3つの中で最も守備範囲が広く、RBACを無料で提供する唯一のツールです。DockhandのRBACはEnterpriseティア限定です。
ディスカッション
コメント
ログインしてディスカッションに参加してください。