openclaw fleet
openclaw fleet は、セルと呼ばれる完全な OpenClaw インスタンスを管理します。各セルには、独自の Gateway、状態、認証情報、チャネルアカウント、コンテナ、local loopback 専用ホストポートがあります。テナントの信頼境界ごとに 1 つのセルを使用してください。敵対的なマルチテナント境界として 1 つの共有 Gateway を使用しないでください。
Fleet は実験的機能です。このインターフェースが安定するまで、コマンド名、フラグ、出力形式、コンテナプロファイルは、非推奨期間なしでリリース間に変更される可能性があります。
Fleet は Docker と Podman をサポートします。デフォルトイメージは ghcr.io/openclaw/openclaw:latest です。
Fleet は Linux および macOS ホストでテストされています。Windows ホストは現在テストされていません。
クイックスタート
fleet create は、生成された Gateway トークンをセルの URL とともに一度だけ表示します。トークンを直ちに保存してから、各テナントのチャネルアカウントをそのテナントのセル内で設定してください。
テナント ID
テナント ID は次の正規表現に一致する必要があります。../acme のようなトラバーサル文字列は拒否されます。
ID はコンテナ名の一部になります: openclaw-cell-<tenant>。
fleet create
セルを作成して起動します。
--env を繰り返して、テナント固有の環境変数を渡します。
作成オプション
自動割り当てでは、
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 順に一覧表示します。
Docker または Podman が利用できない場合もレジストリ行は表示されたままで、ライブ状態のみが
unknown になります。
fleet status
1 つのセルを検査します。
ok、failed、または skipped です。/healthz が証明するのは Gateway の稼働状態であり、設定されたすべてのチャネルや Plugin の完全な準備完了状態ではありません。確認可能な使用可能ローカルエンドポイントがない場合、プローブはスキップされます。
fleet logs
セルのコンテナログをターミナルへ直接ストリーミングします。
--follow を終了するには Ctrl-C を押します。オペレーターによる停止はコマンド失敗として扱われません。ログ出力はリダクションフィルターを経由し、ターミナルに到達する前にセルの現在の Gateway トークンが <redacted> に置換されます。
コンテナログは未加工の stdout/stderr ストリームであるため、fleet logs に --json モードはありません。スクリプトでは、--tail で出力範囲を制限し、通常のシェルリダイレクトまたはパイプラインを使用してください。
fleet start、fleet stop、fleet restart
記録されたランタイムを使用して既存のセルを制御します。
fleet upgrade
記録されたイメージを再度取得し、セルのコンテナを置き換えます。
--env で指定された値が維持されます。マウントされた状態はコンテナを置き換えても保持されますが、イメージのデフォルト環境は対象イメージに応じて変わる可能性があります。
置き換えは、公式 compose ファイルが使用するヘルスコントラクトと同様に、セルのループバックポートで Gateway が /healthz に応答した後にのみ確定されます。置き換え後のコンテナが終了する、クラッシュループに陥る、または約 1 分以内に正常状態にならない場合は、そのコンテナを削除して以前のコンテナを復元するため、壊れたイメージによって稼働中のセルが停止することはありません。
Gateway トークンは意図的に fleet レジストリに保存されません。古いコンテナを削除する前に、Fleet はその環境を読み取り、OPENCLAW_GATEWAY_TOKEN を置き換え後のコンテナへ引き継ぎます。トークンが管理下のほかの場所に存在しない場合は、アップグレード前に古いコンテナを手動で削除しないでください。
fleet backup と fleet restore
停止中のセルを 1 つバックアップします。
0600 で作成されるため、認証情報と同様に保管する必要があります。SQLite の状態を整合性のある形で取得するため、実行中のセルはバックアップできません。復元では、--force が指定されていない限り実行中のセルを拒否し、そのテナントの状態のみを置き換え、Gateway トークンをローテーションして、新しいトークンを 1 回だけ表示します。Fleet が一度にバックアップするのは 1 テナントのみです。全テナントのバックアップは別のオペレーター操作です。
どちらのコマンドも、アーカイブまたは展開されるファイルデータを制限する --max-bytes <bytes> を受け付けます。また、どちらにもアーカイブのパスセグメント数に対する固定の 100 万件の上限が適用されるため、メタデータのみのアーカイブ爆弾によるホスト inode の枯渇を防ぎ、受け入れられたすべてのバックアップを復元可能な状態に保ちます。バックアップは --out <path> を受け付け、どちらのコマンドも --json をサポートします。
アーカイブに含まれるのは通常ファイルとディレクトリのみです。バックアップはシンボリックリンクをたどらず、シンボリックリンク、ハードリンク、ソケット、デバイスノードを保存しません。スキップした件数は結果に報告されます。復元では、その他のエントリ種別を含むアーカイブを拒否します。ワークスペースの node_modules など、再作成可能なシンボリックリンクツリーは、復元後にセル内で再インストールする必要があります。
fleet doctor
ランタイムやファイルシステムの状態を変更せずに、すべてのセルまたは 1 つのテナントを監査します。
fleet rm
テナントデータを保持したまま、停止中のセルをランタイムとレジストリから削除します。
--force が必要です。
--purge-data には --force が必要です。再帰的に削除する前に、Fleet は Fleet 所有の 2 つのルートと、テナント単位の 2 つのディレクトリを解決します。各対象は、想定された正確なテナントのリーフであり、そのルートの厳密な内部にあり、かつシンボリックリンクではない必要があります。これらの包含チェックにより、破損したレジストリパスやテナントをまたぐシンボリックリンクによって削除先が別の場所へ変更されることを防ぎます。
想定された正確なテナントディレクトリがすでに存在しない場合でも、パージは再試行できます。これにより、まだ存在するディレクトリに対するパスチェックを緩和することなく、ファイルシステムの部分的な障害後に、後続の呼び出しでクリーンアップを完了できます。
ストレージとコンテナのレイアウト
セルの状態と認証プロファイルの暗号化キーには、アクティブな OpenClaw 状態ディレクトリ配下にある、テナント単位の個別のホストパスを使用します。/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 出力について述べたものであり、ホスト管理者によるアクセスへの耐性を意味するものではありません。