Mehrere Gateways

Mehrere Gateways zu betreiben ist ein bisschen wie ein Feuerwehrtreppenhaus. An den meisten Tagen denkst du nicht daran. An dem Tag, an dem der Hauptweg voller Rauch ist, bist du sehr froh, dass es da ist.

Genau darum geht es hier. Nicht um Architektur-Theater. Nicht um schicke Diagramme. Sondern um kontrollierte Isolation, wenn ein einzelnes OpenClaw-Gateway nicht mehr genug ist.

Die aktuellen offiziellen Docs sagen es ziemlich direkt: Die meisten Leute sollten ein Gateway pro Maschine betreiben. Ein einzelnes Gateway kann bereits mehrere Channels und Agenten tragen. Aufgeteilt wird nur dann, wenn du bewusst Redundanz, stärkere Trennung oder einen Rescue-Bot willst, der noch funktioniert, wenn der Hauptpfad kaputt ist.

Wann mehrere Gateways sinnvoll sind

Nutze ein zweites Gateway mit Absicht, nicht aus Versehen. Die stärksten Gründe sind:

• Rescue-Bot: ein Fallback-Operatorpfad, der weiterlebt, wenn das Haupt-Gateway oder die Haupt-Bot-Konfiguration bricht
• Betriebliche Isolation: getrennte Workspaces, State-Verzeichnisse und Profile für unterschiedliche Teams oder Rollen
• Channel-Trennung: ein Gateway für kundennahen Traffic, ein anderes für interne Ops
• Mandanten-Trennung: wenn geteilter State unübersichtlich oder riskant würde

Wenn dein eigentlicher Grund nur lautet, "ich habe zwei Bots", dann stopp kurz. Ein Gateway kann das oft schon allein.

Das Rescue-Bot-Setup ist der beste Standard

Die OpenClaw-Dokumentation empfiehlt für die meisten Multi-Gateway-Setups ein simples Muster: Haupt-Gateway auf dem Default-Profil lassen, dann ein separates Rescue-Profil mit eigenem Telegram-Bot und anderem Basis-Port anlegen.

Genau hier stolpern viele. Ein Rescue-Bot ist nur dann nützlich, wenn er wirklich unabhängig ist. Wenn er dasselbe Profil, dasselbe State-Verzeichnis, denselben Token und dieselben Ports teilt, ist er kein Rettungsweg. Er ist nur dieselbe Treppe mit anderer Farbe.

In der Praxis bekommt das Rescue-Gateway sein eigenes:

• Profil und Config-Datei
• State-Verzeichnis
• Workspace-Root
• Basis-Port und abgeleitete Browser-Ports
• Telegram-Bot-Identität

Was pro Gateway einzigartig bleiben muss

Das ist die nicht verhandelbare Liste. Jede Gateway-Instanz braucht eigene Werte für:

• OPENCLAW_CONFIG_PATH
• OPENCLAW_STATE_DIR
• agents.defaults.workspace
• gateway.port oder den Port aus --port
• abgeleitete Browser-Control- und CDP-Ports

Wenn du davon etwas teilst, fangen die merkwürdigen Effekte an. Config-Rennen. Port-Kollisionen. Eine Instanz, die in den Browser-State der anderen tritt. Macht keinen Spaß.

Warum Port-Abstand wichtig ist

Die aktuellen OpenClaw-Dokumente empfehlen mindestens 20 Ports Abstand zwischen den Basis-Ports. Das wirkt erst pedantisch, bis du daran denkst, dass das Gateway weitere Browser- und CDP-Ports aus dem Basis-Port ableitet.

Stell dir den Basis-Port als ersten Dominostein einer kurzen Reihe vor. Wenn du zwei Reihen zu dicht nebeneinander aufbaust, hast du keine zwei Systeme. Du hast einen gemeinsamen Unfall.

Beispiel-Layout

Ein sauberes Zwei-Gateway-Layout könnte so aussehen:

# Haupt-Gateway
openclaw setup
openclaw gateway --port 18789

# Rescue-Gateway
openclaw --profile rescue onboard
openclaw --profile rescue gateway install --port 19789

Die genauen Onboarding-Prompts können je nach Setup etwas variieren, aber das Muster bleibt gleich: anderes Profil, anderer Bot, anderer Portbereich.

Manuelle Trennung über Umgebungsvariablen

Wenn du lieber explizit über Umgebungsvariablen trennst, kannst du Instanzen auch direkt über Config-Pfad und State-Verzeichnis auseinanderziehen:

OPENCLAW_CONFIG_PATH=~/.openclaw/main.json OPENCLAW_STATE_DIR=~/.openclaw-main openclaw gateway --port 18789

OPENCLAW_CONFIG_PATH=~/.openclaw/rescue.json OPENCLAW_STATE_DIR=~/.openclaw-rescue openclaw gateway --port 19789

So ist die Isolation auf einen Blick sichtbar. Und Fehler springen eher ins Auge, wenn du in drei Monaten zurückkommst und dich fragst, was dein früheres Ich sich dabei gedacht hat.

Wie dir der Gateway-Lock hilft

OpenClaw hat einen Gateway-Lock-Mechanismus, der verhindert, dass zwei Instanzen auf derselben Maschine um denselben Basis-Port kämpfen. Beim Start prüft OpenClaw Lock-Zustand und Port-Listener und bricht klar ab, wenn bereits ein anderer Prozess die Kontrolle hat.

Das ist gut so. Wenn du jemals einen Lock- oder EADDRINUSE-Konflikt siehst, warnt dich das System, bevor stiller Schaden entsteht.

Nützliche Checks nach der Einrichtung

Wenn das zweite Gateway steht, prüfe die Trennung statt sie einfach zu glauben:

openclaw gateway status --deep
openclaw --profile rescue gateway status --deep
openclaw --profile rescue gateway probe
openclaw status
openclaw --profile rescue status

Laut aktueller Doku ist es normal, dass der Probe-Output vor mehreren erreichbaren Gateways warnt, wenn genau das deine Absicht war. Die eigentliche Frage ist nicht, ob OpenClaw beide bemerkt. Die eigentliche Frage ist, ob beide sauber isoliert sind.

Häufige Fehler

1. Zu früh aufteilen

Manche Betreiber springen zu Multi-Gateway-Layouts, bevor ein sauberes Single-Gateway-Setup stabil läuft. Das ist wie ein zweites Cockpit in ein Flugzeug mit losen Schrauben einzubauen. Erst die Grundlagen stabilisieren.

2. Dieselbe Bot-Identität wiederverwenden

Ein Rescue-Gateway sollte nicht vom selben Telegram-Bot abhängen wie das Haupt-Gateway. Wenn der Hauptpfad kaputt ist, kann sonst auch dein Rettungsweg ausfallen.

3. Workspace-Trennung vergessen

Getrennte Ports reichen nicht. Wenn beide Gateways auf denselben Workspace und denselben State zeigen, ist die Isolation am Ende mehr Deko als Schutz.

4. Browser- oder CDP-Werte doppelt festpinnen

Die Doku nennt das nicht ohne Grund einen klassischen Fußschuss. Wenn du bei zwei Instanzen identische Browser-Control- oder CDP-Werte manuell pinnt, kannst du Konflikte erzeugen, obwohl die Haupt-Ports verschieden sind.

Ein Gateway oder mehrere?

Nutze ein Gateway, wenn du Einfachheit, gemeinsame Kontrolle und weniger bewegliche Teile willst. Nutze mehrere Gateways, wenn du bewusst Fehlerisolation, getrennte Operator-Pfade oder saubere Mandanten-Grenzen brauchst.

Wenn du unsicher bist, bleib bei einem Gateway. Einfache Setups scheitern auf einfachere Weise.

Zusammenfassung

Mehrere Gateways sind nicht der normale OpenClaw-Weg. Sie sind der fortgeschrittene Weg für Leute, die genau wissen, welches Problem sie lösen wollen.

Wenn dieses Problem real ist, ist die Antwort ziemlich klar: alles Wichtige isolieren, Ports mit Abstand wählen, der Rettungsspur eine eigene Identität geben und das Ergebnis mit Status-Checks verifizieren, bevor du ihm vertraust.