openclaw fleet

openclaw fleet verwaltet vollständige OpenClaw-Instanzen, die als Zellen bezeichnet werden. Jede Zelle verfügt über ein eigenes Gateway, einen eigenen Zustand, eigene Anmeldedaten, Kanalkonten, einen Container und einen Host-Port, der ausschließlich über Loopback erreichbar ist. Verwenden Sie für jede Mandanten-Vertrauensgrenze eine eigene Zelle; verwenden Sie kein gemeinsam genutztes Gateway als Grenze zwischen feindlichen Mandanten.

Fleet ist experimentell. Befehlsnamen, Flags, Ausgabeformate und das Containerprofil können sich zwischen Releases ohne Abkündigungsfrist ändern.

Fleet unterstützt Docker und Podman. Das Standard-Image ist ghcr.io/openclaw/openclaw:latest.

Fleet wurde auf Linux- und macOS-Hosts getestet. Windows-Hosts sind derzeit nicht getestet.

Schnellstart

openclaw fleet create acmeopenclaw fleet status acmeopenclaw fleet list

fleet create gibt das generierte Gateway-Token einmal zusammen mit der URL der Zelle aus. Speichern Sie das Token sofort und konfigurieren Sie anschließend die Kanalkonten jedes Mandanten innerhalb der Zelle dieses Mandanten.

Mandanten-IDs

Mandanten-IDs müssen folgendem Muster entsprechen:

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

Dies erlaubt 1 bis 40 Kleinbuchstaben, Ziffern und interne Bindestriche. Eine ID muss mit einem Buchstaben oder einer Ziffer beginnen und enden. Großbuchstaben, Unterstriche, Schrägstriche, Punkte, Leerraum und Traversierungszeichenfolgen wie ../acme werden abgelehnt.

Die ID wird Teil des Containernamens: openclaw-cell-<tenant>.

fleet create

Erstellen und starten Sie eine Zelle:

openclaw fleet create acme

Erstellen Sie eine Podman-Zelle an einem festen Port, ohne sie zu starten:

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

Übergeben Sie mandantenspezifische Umgebungsvariablen, indem Sie --env wiederholen:

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

Umgebungsschlüssel verwenden Buchstaben, Ziffern und Unterstriche und dürfen nicht mit einer Ziffer beginnen. Werte müssen einzeilig sein, da Fleet sie über eine geschützte Laufzeit-Umgebungsdatei übergibt. Fleet lehnt Versuche ab, die unter Speicher- und Containerstruktur aufgeführten verwalteten Variablen für Containerpfade und Gateway-Token zu überschreiben.

Erstellungsoptionen

Bei der automatischen Zuweisung wird der erste nicht verwendete Registry-Port ab 19100 ausgewählt. Fleet lehnt doppelte Mandanten-IDs und explizite Ports ab, die bereits einer anderen Zelle zugewiesen sind.

Image-Referenzen werden als einzelnes Argument an die Container-Laufzeit übergeben. Leere Referenzen und Werte, die mit - beginnen, werden abgelehnt, damit ein Image nicht als Docker- oder Podman-Option interpretiert werden kann.

Der ausgewählte Docker- oder Podman-Endpunkt muss lokal sein. Fleet lehnt entfernte Docker-Kontexte, DOCKER_HOST-Endpunkte und entfernte Podman-Dienste ab, bevor ein Port reserviert oder lokaler Zustand erstellt wird. Entfernte Zellen-Hosts werden nicht unterstützt.

Wenn Fleet eine neue Zelle startet, wartet der Erstellungsbefehl bis zu etwa einer Minute darauf, dass das Gateway auf /healthz antwortet. Wenn die Zelle nicht fehlerfrei wird, lässt Fleet ihren Container und Registry-Eintrag für fleet status, fleet logs oder eine explizite Entfernung unverändert bestehen. --no-start überspringt diese Zustandsprüfung. Das generierte Gateway-Token einer fehlerhaften neuen Zelle geht nicht verloren – es verbleibt in der Containerumgebung (docker|podman inspect). Da die Zelle noch keinen Datenverkehr verarbeitet hat, ist fleet rm --force mit anschließender erneuter Erstellung immer eine sichere Alternative.

Anheften per Digest

Die Befehle zum Erstellen und Aktualisieren akzeptieren per Digest angeheftete Image-Referenzen wie --image ghcr.io/openclaw/openclaw@sha256:<digest>. Fleet übergibt die Image-Referenz unverändert an Docker oder Podman, sodass ein Betreiber eine Zelle auf unveränderlichen Image-Bytes statt auf einem veränderlichen Tag halten kann.

Das Erstellungsergebnis enthält die Mandanten-ID, den Containernamen, den Host-Port, das Gateway-Token und die lokale URL. Behandeln Sie das Ergebnis selbst bei einer JSON-Ausgabe als geheimnishaltig, da es das Token enthält.

Datenträgerlimits

--disk begrenzt ausschließlich die beschreibbare Container-Schicht. Die per Bind-Mount eingebundenen mandantenspezifischen Zustands- und Authentifizierungsverzeichnisse verbleiben im Host-Speicher; verwenden Sie Projektkontingente des Host-Dateisystems, wenn auch für diese Verzeichnisse ein festes Limit erforderlich ist.

Richtlinie für ausgehenden Datenverkehr

Behalten Sie für Docker den Bridge-Modus bei und setzen Sie die Richtlinie für ausgehenden Datenverkehr mit Host-Firewallregeln wie der DOCKER-USER-Kette durch.

fleet list

Listen Sie Zellen nach Mandanten-ID sortiert auf:

openclaw fleet listopenclaw fleet lsopenclaw fleet list --json

Die Tabelle enthält:

Registry-Einträge bleiben sichtbar, wenn Docker oder Podman nicht verfügbar ist; lediglich der aktuelle Zustand wird zu unknown.

fleet status

Prüfen Sie eine Zelle:

openclaw fleet status acmeopenclaw fleet status acme --json

Der Status kombiniert den Fleet-Registry-Eintrag, die aktuelle Containerinspektion und eine kurze Best-Effort-Anfrage an:

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

Das Zustandsergebnis lautet ok, failed oder skipped. /healthz weist die Erreichbarkeit des Gateways nach, nicht die vollständige Betriebsbereitschaft jedes konfigurierten Kanals oder Plugins. Die Prüfung wird übersprungen, wenn kein verwendbarer lokaler Endpunkt verfügbar ist.

fleet logs

Streamen Sie die Containerprotokolle einer Zelle direkt an das Terminal:

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

Fleet überprüft die Eigentumslabels des registrierten Containers, bevor Protokolle gelesen werden, und verweigert daher einen fremden Container, der den erwarteten Zellennamen verwendet. Der Stream ist an die ID des geprüften Containers gebunden, sodass eine gleichzeitige Ersetzung ihn nicht auf eine neuere Generation umleiten kann. Drücken Sie Ctrl-C, um --follow zu beenden, ohne den Abbruch durch den Betreiber als Befehlsfehler zu behandeln. Die Protokollausgabe wird durch einen Schwärzungsfilter geleitet, der das aktuelle Gateway-Token der Zelle durch <redacted> ersetzt, bevor etwas das Terminal erreicht.

fleet logs verfügt über keinen --json-Modus, da Containerprotokolle ein unverarbeiteter stdout/stderr-Stream sind. Begrenzen Sie für Skripte die Ausgabe mit --tail und verwenden Sie die gewöhnliche Shell-Umleitung oder Pipelines.

fleet start, fleet stop und fleet restart

Steuern Sie eine vorhandene Zelle mit ihrer aufgezeichneten Runtime:

openclaw fleet start acmeopenclaw fleet stop acmeopenclaw fleet restart acme

Diese Befehle wirken auf den registrierten Containernamen. Sie schlagen fehl, wenn der Mandant unbekannt ist oder die aufgezeichnete Runtime den Vorgang nicht ausführen kann.

fleet upgrade

Rufen Sie das aufgezeichnete Image erneut ab und ersetzen Sie den Zellencontainer:

openclaw fleet upgrade acme

Verschieben Sie die Zelle auf ein anderes Image:

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

Beim Upgrade wird das Ziel-Image abgerufen, der vorhandene Container und das zellenspezifische Netzwerk werden untersucht, der Container wird angehalten und entfernt und anschließend neu erstellt und gestartet. Der Ersatz behält denselben Host-Port, dieselben Datenverzeichnisse, dasselbe zellenspezifische Bridge-Netzwerk, dasselbe Runtime-Profil, dieselben Ressourcenlimits, dieselbe Neustartrichtlinie, dieselbe von Fleet verwaltete Umgebung und dieselben ursprünglich mit --env angegebenen Werte bei. Eingebundener Zustand bleibt beim Ersetzen des Containers erhalten; die standardmäßige Image-Umgebung kann sich mit dem Ziel-Image ändern.

Der Ersatz wird erst übernommen, nachdem sein Gateway auf dem Loopback-Port der Zelle auf /healthz antwortet, entsprechend dem Health-Vertrag der offiziellen Compose-Datei. Ein Ersatz, der beendet wird, in einer Absturzschleife läuft oder nicht innerhalb von etwa einer Minute fehlerfrei wird, wird entfernt und der vorherige Container wird wiederhergestellt, sodass ein fehlerhaftes Image keine funktionierende Zelle außer Betrieb setzt.

Das Gateway-Token wird absichtlich nicht in der Fleet-Registry gespeichert. Vor dem Entfernen des alten Containers liest Fleet dessen Umgebung und übernimmt OPENCLAW_GATEWAY_TOKEN in den Ersatz. Entfernen Sie den alten Container vor einem Upgrade nicht manuell, wenn das Token an keiner anderen von Ihnen kontrollierten Stelle vorhanden ist.

fleet backup und fleet restore

Sichern Sie eine angehaltene Zelle:

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

Stellen Sie dieses Archiv in der registrierten Zelle wieder her:

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

Dies sind Befehle mit Host-Operator-Berechtigungen. Archive enthalten Mandantenzustand und Authentifizierungsgeheimnisse, werden mit dem Modus 0600 erstellt und müssen wie Anmeldedaten aufbewahrt werden. Die Sicherung lehnt eine laufende Zelle ab, damit der SQLite-Zustand konsistent erfasst wird. Die Wiederherstellung lehnt eine laufende Zelle ab, sofern nicht --force angegeben wird, ersetzt nur den Zustand dieses Mandanten, rotiert das Gateway-Token und gibt das neue Token einmal aus. Fleet sichert jeweils einen Mandanten; die Sicherung aller Mandanten ist eine separate Operatoraktion.

Für die Wiederherstellung ist ein vorhandener angehaltener Container erforderlich, da sein untersuchtes Runtime-Profil die Ersatzlimits, die Benutzerzuordnung, die Herkunft der Umgebung und das Image bereitstellt. Wenn der registrierte Container außerhalb von Fleet entfernt wurde, führen Sie zunächst fleet rm <tenant> --force ohne --purge-data aus, erstellen Sie die Zelle mit dem vorgesehenen Image und --no-start neu und versuchen Sie die Wiederherstellung anschließend erneut. Bei der ersten Entfernung bleiben beide Mandantendatenverzeichnisse erhalten.

Beide Befehle akzeptieren --max-bytes <bytes>, um die Größe archivierter oder extrahierter Dateidaten zu begrenzen, und beide wenden dasselbe feste Budget von einer Million Archivpfadsegmenten an, damit reine Metadaten-Archivbomben die Host-Inodes nicht erschöpfen können und jede akzeptierte Sicherung wiederherstellbar bleibt. Die Sicherung akzeptiert --out <path>, und beide Befehle unterstützen --json.

Archive enthalten ausschließlich reguläre Dateien und Verzeichnisse. Die Sicherung folgt oder speichert niemals symbolische Links, Hardlinks, Sockets oder Geräteknoten; die Anzahl übersprungener Elemente wird im Ergebnis angegeben. Die Wiederherstellung lehnt Archive ab, die andere Eintragstypen enthalten. Wiederherstellbare symbolische Linkbäume wie Workspace-node_modules müssen nach einer Wiederherstellung innerhalb der Zelle neu installiert werden.

fleet doctor

Prüfen Sie alle Zellen oder einen Mandanten, ohne den Runtime- oder Dateisystemzustand zu ändern:

openclaw fleet doctoropenclaw fleet doctor acme --json

Doctor prüft Runtime-Lokalität, Eigentumskennzeichnungen, Integrität, Härtung, Ressourcenlimits, Loopback-Portbindung, Vorhandensein des Tokens, Netzwerkeigentum und Egress-Modus sowie die Berechtigungen privater Zustandsverzeichnisse. Warnungen beschreiben angehaltene Zellen oder Unterschiede bei den Eigentumsverhältnissen; jeder fehlgeschlagene Befund setzt einen von null verschiedenen Prozess-Exit-Code.

fleet rm

Entfernen Sie eine angehaltene Zelle aus der Runtime und der Registry, wobei die Mandantendaten erhalten bleiben:

openclaw fleet rm acme

Ein laufender Container erfordert --force:

openclaw fleet rm acme --force

Entfernen Sie auch die Zellendaten dauerhaft:

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

Fleet entfernt den Zellencontainer, bevor das zugehörige dedizierte Bridge-Netzwerk entfernt wird. --purge-data erfordert --force. Vor dem rekursiven Löschen löst Fleet sowohl die beiden Fleet-eigenen Stammverzeichnisse als auch die beiden mandantenspezifischen Verzeichnisse auf. Jedes Ziel muss genau das erwartete Mandantenblatt sein, sich strikt innerhalb seines Stammverzeichnisses befinden und darf kein symbolischer Link sein. Diese Begrenzungsprüfungen verhindern, dass ein beschädigter Registry-Pfad oder ein mandantenübergreifender symbolischer Link das Löschen an eine andere Stelle umleitet.

Die Bereinigung kann erneut versucht werden, wenn ein exakt erwartetes Mandantenverzeichnis bereits fehlt. Dadurch kann ein späterer Aufruf die Bereinigung nach einem teilweisen Dateisystemfehler abschließen, ohne die Pfadprüfungen für noch vorhandene Verzeichnisse zu lockern.

Speicher- und Containerlayout

Zellenzustand und Verschlüsselungsschlüssel für Authentifizierungsprofile verwenden separate mandantenspezifische Host-Pfade unter dem aktiven OpenClaw-Zustandsverzeichnis:

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

Das erste Verzeichnis wird unter /home/node/.openclaw eingebunden. Das zweite wird unter /home/node/.config/openclaw eingebunden, entsprechend der Einbindung des Verschlüsselungsschlüssels in der offiziellen Docker-Konfiguration. Der Verschlüsselungsschlüssel wird daher weder unterhalb der normalen Zustandseinbindung offengelegt noch eingeschlossen, wenn nur das Zellzustandsverzeichnis gesichert oder freigegeben wird. Beide Verzeichnisse bleiben bei normaler Entfernung und bei Upgrades erhalten; fleet rm --purge-data --force löscht beide nach separaten Begrenzungsprüfungen.

Vor dem ersten Start initialisiert Fleet die Zellenkonfiguration mit gateway.mode=local, Token-Authentifizierung, der LAN-Containerbindung und Control-UI-Ursprüngen für den zugewiesenen Host-Port. Der Tokenwert wird nicht in diese Konfiguration geschrieben, sondern verbleibt in der Containerumgebung.

Fleet legt die Containerpfade des offiziellen Images mit diesen Umgebungswerten fest:

Das offizielle Image verwendet standardmäßig den Nicht-Root-Benutzer node mit UID 1000. Fleet hält die privaten 0700-Bind-Mounts beschreibbar, ohne sie für alle zugänglich zu machen. Rootful Docker führt die Zelle mit der UID und GID des aufrufenden Nicht-Root-Benutzers aus; Rootless Docker verwendet Container-UID 0, die innerhalb des Benutzernamensraums des Daemons dem aufrufenden, nicht privilegierten Host-Benutzer zugeordnet wird. Podman verwendet keep-id mit der aufrufenden UID und GID. Wenn Fleet selbst als Root mit einer Rootful-Runtime ausgeführt wird, behält es den Image-Benutzer bei und weist die anfänglichen Mount-Dateien UID/GID 1000 zu.

Auf SELinux-Hosts erhalten Docker- und Podman-Mounts eine private :Z-Neukennzeichnung. Wenn Sie Zellendaten wiederherstellen oder verschieben, müssen die per Bind-Mount eingebundenen Pfade für den effektiven Containerbenutzer beschreibbar bleiben. Das Profil ist für Rootless-Betrieb geeignet, Docker oder Podman muss jedoch bereits auf dem Host für Rootless-Betrieb konfiguriert sein; Fleet wandelt einen Rootful-Daemon nicht in einen Rootless-Daemon um.

Sicherheitsprofil

Fleet wendet auf jede Zelle das folgende Profil an:

Fleet bindet niemals /var/run/docker.sock ein, verwendet weder --privileged noch Host-Netzwerkbetrieb und fügt keine Fähigkeiten hinzu. Die zellenspezifische Bridge ist eine Trennungsgrenze zwischen Zellen, keine ausgehende Firewall: Zellen behalten den für Provider und Kanäle erforderlichen Netzwerk-Egress. Schalten Sie dem Loopback-Port einen Proxy, SSH-Tunnel oder eine Tailnet-Konfiguration vor, die Ihrer Bereitstellung entspricht. http://127.0.0.1:<port> ist nur vom Fleet-Host direkt erreichbar.

Dieses Profil trennt Mandantencontainer, schützt Mandanten jedoch nicht vor dem Fleet-Operator, dem Administrator der Container-Runtime oder einem kompromittierten Host. Das vollständige Vertrauensmodell und stärkere Isolierungsoptionen finden Sie unter Mehrmandanten-Hosting.

Token-Handhabung

Standardmäßig generiert fleet create ein kryptografisch zufälliges hexadezimales Gateway-Token mit 32 Zeichen und gibt es einmal im Erstellungsergebnis aus. Speichern Sie es in Ihrem zugelassenen Geheimnismanager und vermeiden Sie, die Erstellungsausgabe in Protokollen zu erfassen.

--gateway-token fügt ein benutzerdefiniertes Token in die Argumente des lokalen Prozesses ein, die möglicherweise im Shell-Verlauf erhalten bleiben oder in Prozesslisten sichtbar sind. Verwenden Sie vorzugsweise das generierte Token, sofern nicht ein vorhandener Workflow zur Geheimnisverwaltung einen angegebenen Wert erfordert.

Das Token und jeder mit --env übergebene Wert befinden sich in der Containerumgebung. Fleet schreibt sie in eine kurzlebige Umgebungsdatei mit dem Modus 0600, übergibt nur den Pfad dieser Datei an Docker oder Podman und entfernt sie, nachdem der Runtime-Befehl abgeschlossen ist. Werte, die ausdrücklich in openclaw fleet create --gateway-token ... oder --env KEY=VALUE eingegeben werden, können weiterhin in den äußeren openclaw-Prozessargumenten und im Shell-Verlauf sichtbar sein.

Container-Umgebungswerte sind vor dem vertrauenswürdigen Host-Betreiber nicht verborgen: Docker- oder Podman-Administratoren können sie über die Container-Inspektion auslesen. Der Hinweis „shown once“ von Fleet beschreibt die normale CLI-Ausgabe, nicht den Schutz vor einem Host-Administrator.

Verwandte Themen

• Mandantenfähiges Hosting
• Docker
• Podman
• Gateway-Sicherheit