COMPOSE_PROJECT_NAME · getrennte Daten-Volumes und Porttabelle · env_file und Container-env abgleichen
Wer auf demselben VPS zwei OpenClaw-Stacks parallel betreibt, stößt typischerweise auf belegte Ports, kollidierende Standard-Netzwerke und Volumennamen sowie darauf, dass der API-Key auf dem Host sichtbar ist, im Container aber env leer bleibt. Dieser Text ordnet COMPOSE_PROJECT_NAME, Datenverzeichnisse und eine Porttabelle in einer Gegenüberstellung Ein-Instanz-Baseline vs. minimale Mehr-Instanz-Differenzmenge, erklärt die Injektion über env_file und environment und liefert eine sechsstufige Abhakliste plus Bedingungen fürs Zurückrollen auf eine Instanz. Ergänzend lesbar mit dem Docker-Compose-Produktionsbaseline-Artikel und dem Exit-137- und Einstiegs-Troubleshooting.
Eine Kopie von docker-compose.yml mit geänderten Ports ist noch keine Isolation: der Standard-Projektname lässt Netzwerk und anonyme Volumes weiter kollidieren; export auf dem Host landet nicht automatisch im Container; ein Reverse-Proxy-Upstream kann noch auf die alte Container-IP zeigen. Wenn diese Signale auftauchen, die Checkliste abarbeiten statt weitere Container zu stapeln.
Nur Ports geändert, nicht COMPOSE_PROJECT_NAME: Standard-Bridge und internes DNS können weiterhin Container des anderen Stacks auflösen.
Datenverzeichnis per Symlink oder Mount überlappt: zwei ~/.openclaw- oder Workspace-Pfade teilen dasselbe Präfix auf der Platte, Upgrade-Skripte überschreiben sich.
API-Key nur im Shell-Profil: der Kindprozess von docker compose up sieht nicht den von Compose erwarteten env_file-Pfad.
Healthcheck zu kurz: die zweite Instanz startet kälter langsamer, der Orchestrator startet neu und konkurriert mit der ersten um Locks.
Reverse-Proxy zeigt noch auf 127.0.0.1 und alten Port: wenn zwei Gateways wechseln, routet der Edge weiterhin zu einer gestoppten Instanz. Ausrichtung im Artikel zu Reverse Proxy und TLS.
Die folgenden Felder sind die häufigste minimale Differenzmenge für zwei Stacks auf einem Host. Für einen kurzen Test-Stack sind mindestens Projektname, Datenverzeichnis, Host-Ports und env_file-Pfad erledigt, bevor Automatisierung Sinn macht. Ressourcengrenzen und Log-Rotation bleiben an die Produktionsbaseline gebunden.
| Feld | Ein-Instanz-Baseline | Mehr Instanzen: Pflicht-Trennung | Typische Stolperstelle |
|---|---|---|---|
COMPOSE_PROJECT_NAME | Standard aus Verzeichnisname | pro Stack ein kurzer eindeutiger Name (z. B. oc_a / oc_b) | nur Ordner umbenannt, Projektname gleich, anonyme Volumes wiederverwendet |
| Datenpfad / Volume-Bind | ein Host-Pfad | /srv/openclaw-a und /srv/openclaw-b strikt getrennt | Unterpfad-Symlink zeigt auf dieselbe übergeordnete Ebene |
| Host-Ports | eine Gruppe 3000:3000 | auf verschiedene Host-Ports mappen und in der Porttabelle dokumentieren | zweiter Stack startet nicht, systemd startet trotzdem im Flattern |
| Umgebungs-Injektion | eine .env | pro Stack z. B. .env.oc-a und in Compose explizit env_file | Host-export liegt außerhalb des Compose-Auswertungsbereichs |
| Healthcheck | eine start_period | bei langsamerem Kaltstart start_period und retries erhöhen | beide Stacks starten gleichzeitig neu, CPU-Spitzen |
Projektname und Datenverzeichnis vor der Port-Tabelle fixieren; umgekehrt schreibt das erste Upgrade-Skript beide Zustände in dasselbe Präfix.
Die Schritte setzen voraus, dass der offizielle oder euer Team-Compose-Fragment auf einem Host bereits läuft; Ziel ist, dass gerenderte Konfiguration und Laufzeit-env des zweiten Stacks auditierbar nebeneinander liegen.
Projektname und Verzeichnis setzen: COMPOSE_PROJECT_NAME exportieren, separates Datenverzeichnis anlegen und auf verschachtelte Symlinks prüfen.
Porttabelle fixieren: freie Host-Ports für Gateway, Control UI und Zusatzkanäle zuweisen und im Runbook eintragen.
env_file splitten: pro Stack ein Geheimnis-Pfad, keine gemeinsame .env; mit docker compose --project-directory das Arbeitsverzeichnis festlegen.
Render-Check: docker compose -f ... config ausführen und networks, volumes und ports beider Stacks auf doppelt benannte Mounts prüfen.
Laufzeit prüfen: per docker compose exec im Container die Zielvariablen ausgeben und mit maskierten Terminalausgaben auf dem Host abgleichen.
Health und Logs: laut Baseline-Artikel start_period und json-file-Limits setzen, damit beide Stacks die Platte nicht gleichzeitig füllen.
export COMPOSE_PROJECT_NAME=oc_b docker compose --env-file ./.env.oc-b -f docker-compose.yml config > /tmp/oc-b.rendered.yml docker compose --env-file ./.env.oc-b -f docker-compose.yml up -d docker compose --env-file ./.env.oc-b exec -T openclaw-gateway sh -lc 'env | grep -E "ANTHROPIC|OPENAI" | sed "s/=.*/=***MASK***/"'
Hinweis: der Unterbefehl config wertet nur die Zusammenführung aus und startet keine Container; gerenderte Diff speichern, dann up, zum Vergleich mit dem ersten Stack.
Die Liste ist Startpunkt für Bereitschaft und Postmortems; echte Schwellenwerte müssen aus eurem Compose und Host-Monitoring kommen und sind kein externes SLA. Bei „trifft manchmal die falsche Instanz“ mindestens gerenderte Konfiguration beider Stacks, inspect-Netzsegmente und einen Snapshot des Proxy-Upstreams sichern.
up des zweiten Stacks ss -lntp oder Äquivalent ausführen und Ausgabe ans Ticket hängen.json-file schreiben, werden Inodes und Bandbreite oft vor der CPU zum Engpass; Rhythmus siehe Baseline-Artikel.| Symptom | Zuerst prüfen | Befehl oder Beleg |
|---|---|---|
| Kein API-Key im Container | env_file-Pfad, Compose-Arbeitsverzeichnis | docker compose config und exec-env vergleichen |
| Healthcheck-Flattern | start_period, CPU steal | Host-dmesg, cgroup-Zahlen und Container-Log-Zeitleiste |
| Traffic bei falscher Instanz | Proxy-Upstream, alte Container | docker ps -a und Upstream-Datei vor und nach Reload diffen |
Achtung: dieselbe .env-Pfad überschreiben, während der erste Stack läuft, verwürfelt die Key-Rotation beider Stacks; immer zuerst kopieren, dann die Referenz umstellen.
Zwei produktionsnahe OpenClaw-Instanzen auf einem kleinen RAM-VPS scheitern oft an Platte und Logs, nicht an Rechenleistung; ohne getrennte Datenverzeichnisse und Porttabelle wird Troubleshooting zu „welches Gateway hat die Verbindung“. Compose nur von Hand zu ändern, ohne gerendertes Diff zu archivieren, macht späteres Upgrade blind dafür, wer welche Umgebungsvariable geändert hat.
Teams, die einen stabilen Host, planbare Bandbreite und klar getrennte Arbeitsverzeichnisse brauchen, setzen OpenClaw oft sinnvoller auf buchbare Cloud-Mac- oder VPS-Angebote um; wenn Mehr-Instanz-Experimente und Produktion dieselbe Betriebsgeschichte teilen sollen, bietet sich VpsMesh Mac Mini Cloud-Miete typischerweise an: Rollen lassen sich splitten, Pfade sind nachvollziehbar, Compose-Differenzen und Queueing-Strategie bleiben abnahmefähig.
Wer personenbezogene Inhalte in Logs oder Volumes der beiden Stacks verarbeitet, sollte Zweck und Speicherdauer dokumentieren: Art. 5 Abs. 1 lit. a und c DSGVO verlangen Rechtsgrundlage sowie Datenminimierung und begrenzte Speicherung, sodass getrennte Verzeichnisse und Retention nicht nur technisch, sondern auch nachweisbar bleiben.
Mit der Tabelle aus dem Fließtext anonyme Volumes, Standard-Netzwerknamen, Host-Ports und env_file gegen den ersten Stack prüfen; häufig bleibt nur der Ordnername geändert, der Projektname nicht. Mehr zu Healthcheck und Restart im Compose-Produktionsbaseline-Artikel.
Oft lädt Compose die falsche env_file, das Arbeitsverzeichnis weicht ab oder Variablen stehen nur in der Build-Phase; die sechs Schritte mit docker compose config und exec abgleichen. Für den Einstieg den Umgebungsvariablen-Abschnitt im Exit-137-Troubleshooting nutzen.
Zuerst den zweiten Stack mit docker compose down stoppen und Ports freigeben, dann beide Datenverzeichnisse sichern; Volumes nicht löschen, bevor die Konfiguration exportiert ist. Preise auf der Preisseite, Bestellung über Bestellen, Anbindung im Hilfezentrum.