openclaw fleet

openclaw fleet は、セルと呼ばれる完全な OpenClaw インスタンスを管理します。各セルには、独自の Gateway、状態、認証情報、チャネルアカウント、コンテナ、local loopback 専用ホストポートがあります。テナントの信頼境界ごとに 1 つのセルを使用してください。敵対的なマルチテナント境界として 1 つの共有 Gateway を使用しないでください。

Fleet は実験的機能です。このインターフェースが安定するまで、コマンド名、フラグ、出力形式、コンテナプロファイルは、非推奨期間なしでリリース間に変更される可能性があります。

Fleet は Docker と Podman をサポートします。デフォルトイメージは ghcr.io/openclaw/openclaw:latest です。

Fleet は Linux および macOS ホストでテストされています。Windows ホストは現在テストされていません。

クイックスタート

openclaw fleet create acmeopenclaw fleet status acmeopenclaw fleet list

fleet create は、生成された Gateway トークンをセルの URL とともに一度だけ表示します。トークンを直ちに保存してから、各テナントのチャネルアカウントをそのテナントのセル内で設定してください。

テナント ID

テナント ID は次の正規表現に一致する必要があります。

^[a-z0-9](?:[a-z0-9-]{0,38}[a-z0-9])?$

使用できるのは、1〜40 文字の小文字、数字、および途中のハイフンです。ID の先頭と末尾は文字または数字でなければなりません。大文字、アンダースコア、スラッシュ、ドット、空白、および ../acme のようなトラバーサル文字列は拒否されます。

ID はコンテナ名の一部になります: openclaw-cell-<tenant>。

fleet create

セルを作成して起動します。

openclaw fleet create acme

固定ポートに Podman セルを作成し、起動はしません。

openclaw fleet create acme \  --runtime podman \  --port 19125 \  --no-start

--env を繰り返して、テナント固有の環境変数を渡します。

openclaw fleet create acme \  --env TZ=America/Los_Angeles \  --env OPENCLAW_DISABLE_BONJOUR=1

環境変数キーには文字、数字、アンダースコアを使用でき、数字で始めることはできません。Fleet は保護されたランタイム環境ファイルを介して値を渡すため、値は単一行でなければなりません。Fleet は、ストレージとコンテナのレイアウトに記載されている、管理対象のコンテナパス変数および Gateway トークン変数を上書きしようとする操作を拒否します。

作成オプション

自動割り当てでは、19100 以上でレジストリ内の最初の未使用ポートが選択されます。Fleet は、重複するテナント ID、および別のセルにすでに割り当てられている明示的なポートを拒否します。

イメージ参照は、1 つのコンテナランタイム引数として渡されます。イメージが Docker または Podman のオプションとして解釈されないよう、空の参照および - で始まる値は拒否されます。

選択した Docker または Podman エンドポイントはローカルでなければなりません。Fleet は、ポートを予約したりローカル状態を作成したりする前に、リモート Docker コンテキスト、DOCKER_HOST エンドポイント、およびリモート Podman サービスを拒否します。リモートセルホストには別個のストレージおよびエンドポイントの契約が必要であり、この MVP では対応を見送っています。

Fleet が新しいセルを起動すると、create はその Gateway が /healthz に応答するまで最大約 1 分待機します。セルが正常状態にならない場合、Fleet は fleet status、fleet logs、または明示的な削除で確認できるよう、コンテナとレジストリ行をそのまま残します。--no-start はこのヘルスゲートをスキップします。正常状態にならなかった新しいセルの生成済み Gateway トークンは失われません。コンテナ環境内に残り（docker|podman inspect）、そのセルはまだトラフィックを処理していないため、fleet rm --force の後に新しく作成し直す方法も常に安全です。

ダイジェストによる固定

create と upgrade は、--image ghcr.io/openclaw/openclaw@sha256:<digest> のようなダイジェスト固定イメージ参照を受け付けます。Fleet はイメージ参照をそのまま Docker または Podman に渡すため、オペレーターは変動するタグではなく、不変のイメージバイトにセルを固定できます。

作成結果には、テナント ID、コンテナ名、ホストポート、Gateway トークン、ローカル URL が含まれます。JSON 出力であってもトークンが含まれるため、結果は機密情報を含むものとして扱ってください。

ディスク制限

--disk が制限するのは、コンテナの書き込み可能レイヤーのみです。バインドマウントされたテナントごとの状態ディレクトリと認証ディレクトリは、引き続きホストストレージを使用します。これらのディレクトリにもハードリミットが必要な場合は、ホストファイルシステムのプロジェクトクォータを使用してください。

送信ポリシー

Docker では、ブリッジモードを維持し、DOCKER-USER チェーンなどのホストファイアウォールルールを使用して外向き通信ポリシーを適用してください。

fleet list

セルをテナント ID 順に一覧表示します。

openclaw fleet listopenclaw fleet lsopenclaw fleet list --json

表には次の情報が含まれます。

Docker または Podman が利用できない場合もレジストリ行は表示されたままで、ライブ状態のみが unknown になります。

fleet status

1 つのセルを検査します。

openclaw fleet status acmeopenclaw fleet status acme --json

status は、Fleet レジストリ行、ライブコンテナ検査、および次の URL への短時間のベストエフォートリクエストを組み合わせます。

http://127.0.0.1:<host-port>/healthz

ヘルス結果は ok、failed、または skipped です。/healthz が証明するのは Gateway の稼働状態であり、設定されたすべてのチャネルや Plugin の完全な準備完了状態ではありません。確認可能な使用可能ローカルエンドポイントがない場合、プローブはスキップされます。

fleet logs

セルのコンテナログをターミナルへ直接ストリーミングします。

openclaw fleet logs acmeopenclaw fleet logs acme --followopenclaw fleet logs acme --tail 200openclaw fleet logs acme --since 10m

Fleet はログを読み取る前に、登録済みコンテナの所有権ラベルを検証するため、想定されるセル名を使用する外部コンテナは拒否されます。--follow を終了するには Ctrl-C を押します。オペレーターによる停止はコマンド失敗として扱われません。ログ出力はリダクションフィルターを経由し、ターミナルに到達する前にセルの現在の Gateway トークンが <redacted> に置換されます。

コンテナログは未加工の stdout/stderr ストリームであるため、fleet logs に --json モードはありません。スクリプトでは、--tail で出力範囲を制限し、通常のシェルリダイレクトまたはパイプラインを使用してください。

fleet start、fleet stop、fleet restart

記録されたランタイムを使用して既存のセルを制御します。

openclaw fleet start acmeopenclaw fleet stop acmeopenclaw fleet restart acme

これらのコマンドは、登録されたコンテナ名を対象に動作します。テナントが不明な場合、または記録されたランタイムが操作を実行できない場合は失敗します。

fleet upgrade

記録されたイメージを再度取得し、セルのコンテナを置き換えます。

openclaw fleet upgrade acme

セルを別のイメージへ移行します。

openclaw fleet upgrade acme --image ghcr.io/openclaw/openclaw:<version>

アップグレードでは、対象イメージを取得し、既存のコンテナとセル単位のネットワークを検査してから、コンテナを停止して削除し、再作成して起動します。置き換え後も、同じホストポート、データディレクトリ、セル単位のブリッジネットワーク、ランタイムプロファイル、リソース制限、再起動ポリシー、Fleet が管理する環境、および当初 --env で指定された値が維持されます。マウントされた状態はコンテナを置き換えても保持されますが、イメージのデフォルト環境は対象イメージに応じて変わる可能性があります。

置き換えは、公式 compose ファイルが使用するヘルスコントラクトと同様に、セルのループバックポートで Gateway が /healthz に応答した後にのみ確定されます。置き換え後のコンテナが終了する、クラッシュループに陥る、または約 1 分以内に正常状態にならない場合は、そのコンテナを削除して以前のコンテナを復元するため、壊れたイメージによって稼働中のセルが停止することはありません。

Gateway トークンは意図的に fleet レジストリに保存されません。古いコンテナを削除する前に、Fleet はその環境を読み取り、OPENCLAW_GATEWAY_TOKEN を置き換え後のコンテナへ引き継ぎます。トークンが管理下のほかの場所に存在しない場合は、アップグレード前に古いコンテナを手動で削除しないでください。

fleet backup と fleet restore

停止中のセルを 1 つバックアップします。

openclaw fleet stop acmeopenclaw fleet backup acme --out ./acme.tgz

そのアーカイブを登録済みのセルへ復元します。

openclaw fleet restore acme --from ./acme.tgz

これらはホストオペレーター権限を必要とするコマンドです。アーカイブにはテナントの状態と認証シークレットが含まれ、モード 0600 で作成されるため、認証情報と同様に保管する必要があります。SQLite の状態を整合性のある形で取得するため、実行中のセルはバックアップできません。復元では、--force が指定されていない限り実行中のセルを拒否し、そのテナントの状態のみを置き換え、Gateway トークンをローテーションして、新しいトークンを 1 回だけ表示します。Fleet が一度にバックアップするのは 1 テナントのみです。全テナントのバックアップは別のオペレーター操作です。

どちらのコマンドも、アーカイブまたは展開されるファイルデータを制限する --max-bytes <bytes> を受け付けます。また、どちらにもアーカイブのパスセグメント数に対する固定の 100 万件の上限が適用されるため、メタデータのみのアーカイブ爆弾によるホスト inode の枯渇を防ぎ、受け入れられたすべてのバックアップを復元可能な状態に保ちます。バックアップは --out <path> を受け付け、どちらのコマンドも --json をサポートします。

アーカイブに含まれるのは通常ファイルとディレクトリのみです。バックアップはシンボリックリンクをたどらず、シンボリックリンク、ハードリンク、ソケット、デバイスノードを保存しません。スキップした件数は結果に報告されます。復元では、その他のエントリ種別を含むアーカイブを拒否します。ワークスペースの node_modules など、再作成可能なシンボリックリンクツリーは、復元後にセル内で再インストールする必要があります。

fleet doctor

ランタイムやファイルシステムの状態を変更せずに、すべてのセルまたは 1 つのテナントを監査します。

openclaw fleet doctoropenclaw fleet doctor acme --json

Doctor は、ランタイムのローカル性、所有権ラベル、ヘルス状態、堅牢化、リソース制限、ループバックポートのバインド、トークンの存在、ネットワークの所有権と外向き通信モード、および非公開状態ディレクトリの権限を確認します。警告には、停止中のセルや所有権の差異が記載されます。いずれかの検査結果が失敗すると、プロセスの終了コードは 0 以外になります。

fleet rm

テナントデータを保持したまま、停止中のセルをランタイムとレジストリから削除します。

openclaw fleet rm acme

実行中のコンテナには --force が必要です。

openclaw fleet rm acme --force

セルデータも完全に削除します。

openclaw fleet rm acme --purge-data --force

Fleet は、専用ブリッジネットワークを削除する前にセルのコンテナを削除します。--purge-data には --force が必要です。再帰的に削除する前に、Fleet は Fleet 所有の 2 つのルートと、テナント単位の 2 つのディレクトリを解決します。各対象は、想定された正確なテナントのリーフであり、そのルートの厳密な内部にあり、かつシンボリックリンクではない必要があります。これらの包含チェックにより、破損したレジストリパスやテナントをまたぐシンボリックリンクによって削除先が別の場所へ変更されることを防ぎます。

想定された正確なテナントディレクトリがすでに存在しない場合でも、パージは再試行できます。これにより、まだ存在するディレクトリに対するパスチェックを緩和することなく、ファイルシステムの部分的な障害後に、後続の呼び出しでクリーンアップを完了できます。

ストレージとコンテナのレイアウト

セルの状態と認証プロファイルの暗号化キーには、アクティブな OpenClaw 状態ディレクトリ配下にある、テナント単位の個別のホストパスを使用します。

<state-dir>/fleet/cells/<tenant>/<state-dir>/fleet/auth-profile-secrets/<tenant>/

最初のディレクトリは /home/node/.openclaw にマウントされます。2 番目のディレクトリは、公式 Docker セットアップの暗号化キーマウントと同様に、/home/node/.config/openclaw にマウントされます。そのため、暗号化キーが通常の状態マウント配下に公開されたり、セル状態ディレクトリのみをバックアップまたは共有した際に含まれたりすることはありません。どちらのディレクトリも通常の削除とアップグレードでは保持されます。fleet rm --purge-data --force は、個別の包含チェック後に両方を削除します。

初回起動前に、Fleet はセル設定を gateway.mode=local、トークン認証、LAN コンテナバインド、および割り当てられたホストポート用の Control UI オリジンで初期化します。トークン値はその設定には書き込まれず、コンテナ環境内に保持されます。

Fleet は、次の環境値を使用して公式イメージのコンテナパスを固定します。

公式イメージのデフォルトは、UID 1000 の非 root node ユーザーです。Fleet は、非公開の 0700 バインドマウントを誰でもアクセス可能にすることなく、書き込み可能な状態に保ちます。rootful Docker は、呼び出し元の非 root UID と GID でセルを実行します。rootless Docker はコンテナ UID 0 を使用し、これはデーモンのユーザー名前空間内で、呼び出し元の非特権ホストユーザーにマッピングされます。Podman は、呼び出し元の UID と GID で keep-id を使用します。Fleet 自体が root として rootful ランタイムに接続する場合は、イメージのユーザーを維持し、初期マウントファイルを UID/GID 1000 に割り当てます。

SELinux ホストでは、Docker と Podman のマウントに非公開の :Z 再ラベルが適用されます。セルデータを復元または移動する場合は、有効なコンテナユーザーがバインドマウントされたパスへ書き込める状態を維持してください。このプロファイルは rootless 環境に適していますが、ホスト上で Docker または Podman があらかじめ rootless 操作用に設定されている必要があります。Fleet が rootful デーモンを rootless デーモンへ変換することはありません。

セキュリティプロファイル

Fleet はすべてのセルに次のプロファイルを適用します。

Fleet は /var/run/docker.sock をマウントせず、--privileged やホストネットワークを使用せず、ケーパビリティも追加しません。セル単位のブリッジはセル間の分離境界ですが、外向きファイアウォールではありません。セルにはプロバイダーとチャネルに必要なネットワーク外向き通信が維持されます。デプロイ環境に適したプロキシ、SSH トンネル、または tailnet 設定をループバックポートの前段に配置してください。http://127.0.0.1:<port> に直接アクセスできるのは Fleet ホストからのみです。

このプロファイルはテナントのコンテナを分離しますが、Fleet オペレーター、コンテナランタイム管理者、または侵害されたホストからテナントを保護するものではありません。完全な信頼モデルと、より強力な分離オプションについては、マルチテナントホスティングを参照してください。

トークンの取り扱い

デフォルトでは、fleet create は暗号学的にランダムな 32 文字の 16 進数 Gateway トークンを生成し、作成結果に 1 回だけ表示します。承認されたシークレットマネージャーに保存し、作成時の出力がログに記録されないようにしてください。

--gateway-token はカスタムトークンをローカルプロセスの引数に含めます。この引数はシェル履歴に残ったり、プロセス一覧に表示されたりする可能性があります。既存のシークレット管理ワークフローで指定値が必要な場合を除き、生成されたトークンを使用してください。

トークンと --env で渡されたすべての値は、コンテナ環境内に存在します。Fleet はこれらを短時間だけ存在するモード 0600 の環境ファイルに書き込み、そのファイルのパスのみを Docker または Podman に渡し、ランタイムコマンドの完了後に削除します。openclaw fleet create --gateway-token ... または --env KEY=VALUE に明示的に入力した値は、外側の openclaw プロセス引数やシェル履歴に引き続き表示される可能性があります。

コンテナの環境値は、信頼されたホストオペレーターから隠されるわけではありません。Docker または Podman の管理者は、コンテナの検査によってそれらを読み取れます。Fleet の「1 回だけ表示」という注記は通常の CLI 出力について述べたものであり、ホスト管理者によるアクセスへの耐性を意味するものではありません。

関連項目

• マルチテナントホスティング
• Docker
• Podman
• Gateway のセキュリティ