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 サービスを拒否します。リモートのセルホストはサポートされていません。
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 トークンをローテーションして、新しいトークンを一度だけ出力します。Fleet が一度にバックアップするのは 1 テナントのみです。全テナントのバックアップは、別途オペレーターが実行する操作です。
復元には既存の停止済みコンテナが必要です。検査されたそのランタイムプロファイルから、置き換え後の制限、ユーザーマッピング、環境の出所、イメージが提供されるためです。登録済みコンテナが Fleet 以外から削除されている場合は、まず --purge-data を付けずに fleet rm <tenant> --force を実行し、目的のイメージと --no-start を使用してセルを再作成してから、復元を再試行してください。最初の削除では、テナントの両方のデータディレクトリがそのまま保持されます。
どちらのコマンドも、アーカイブまたは展開されるファイルデータを制限するために --max-bytes <bytes> を受け付けます。また、メタデータのみのアーカイブ爆弾がホストの inode を枯渇させず、受け入れられたすべてのバックアップを復元可能に保つため、アーカイブパスセグメントに対して同じ固定の 100 万件の上限を適用します。バックアップは --out <path> を受け付け、どちらのコマンドも --json をサポートします。
アーカイブに含まれるのは通常ファイルとディレクトリのみです。バックアップでは、シンボリックリンク、ハードリンク、ソケット、デバイスノードをたどることも保存することもありません。スキップされた件数は結果に報告されます。復元では、それ以外のエントリ種別を含むアーカイブを拒否します。ワークスペースの node_modules など、再作成可能なシンボリックリンクツリーは、復元後にセル内で再インストールする必要があります。
fleet doctor
ランタイムやファイルシステムの状態を変更せずに、すべてのセルまたは 1 つのテナントを監査します。
fleet rm
テナントデータを保持したまま、停止中のセルをランタイムとレジストリから削除します。
--force が必要です。
--purge-data には --force が必要です。再帰的に削除する前に、Fleet は Fleet が所有する両方のルートと、テナントごとの両方のディレクトリを解決します。各対象は、想定された正確なテナント末端ディレクトリであり、そのルートの厳密な内側にあり、シンボリックリンクではない必要があります。これらの包含チェックにより、破損したレジストリパスやテナントをまたぐシンボリックリンクによって削除先がほかの場所へ変更されるのを防ぎます。
想定された正確なテナントディレクトリがすでに存在しない場合でも、パージは再試行できます。これにより、まだ存在するディレクトリに対するパスチェックを緩和することなく、ファイルシステムの部分的な障害後に、後続の呼び出しでクリーンアップを完了できます。
ストレージとコンテナのレイアウト
セルの状態と認証プロファイルの暗号化キーは、アクティブな OpenClaw 状態ディレクトリ配下にある、テナントごとの個別のホストパスを使用します。/home/node/.openclaw にマウントされます。2 番目のディレクトリは /home/node/.config/openclaw にマウントされ、公式 Docker セットアップの暗号化キーマウントと一致します。そのため、暗号化キーは通常の状態マウント配下に公開されず、セル状態ディレクトリのみをバックアップまたは共有する場合にも含まれません。どちらのディレクトリも通常の削除とアップグレード後に維持されます。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 トークンを生成し、作成結果に一度だけ出力します。承認済みのシークレットマネージャーに保存し、作成時の出力をログへ記録しないでください。
--gateway-token は、カスタムトークンをローカルプロセスの引数に配置します。この引数はシェル履歴に残る、またはプロセス一覧に表示される可能性があります。既存のシークレット管理ワークフローで指定値が必要な場合を除き、生成されたトークンを使用してください。
トークンと --env で渡されたすべての値は、コンテナ環境に保持されます。Fleet は、それらを短期間だけ存在するモード 0600 の環境ファイルへ書き込み、そのファイルのパスのみを Docker または Podman に渡し、ランタイムコマンドの完了後に削除します。openclaw fleet create --gateway-token ... または --env KEY=VALUE に明示的に入力された値は、外側の openclaw プロセス引数やシェル履歴には引き続き表示される可能性があります。
コンテナ環境の値は、信頼されたホストオペレーターから隠されるものではありません。Docker または Podman の管理者は、コンテナの検査によってそれらを読み取れます。Fleet の「shown once」という注記は通常の CLI 出力について説明するものであり、ホスト管理者によるアクセスへの耐性を示すものではありません。