2026 OpenClaw Linux-Cloud-VPS: Mehrprofil-Gateways parallel — Port-Matrix, systemd-Benutzer-Units, OPENCLAW_*-Verzeichnis-Isolation, reproduzierbares Rollout und Konflikt-FAQ

Auf einer kleinen Linux-Cloud-Instanz lassen sich mehr als ein OpenClaw-Gateway-Profil betreiben: Produktions-Bot, Staging-Bridge und persönlicher Versuch — jeweils mit eigenen Tokens, Konfiguration und Listenadresse. Das typische Scheitern ist selten „Linux kann nicht multitasken“, sondern kollidierende Ports, gemeinsame State-Verzeichnisse und systemd-Units, die um denselben Benutzer oder dasselbe Arbeitsverzeichnis ringen. Dieser Beitrag fasst ein reproduzierbares Muster zusammen: Port-Matrix, profilbezogene systemd --user-Units, explizite OPENCLAW_*-Pfad-Isolation und eine kurze FAQ zu Konflikten, die wir 2026 noch regelmäßig sehen.

Warum parallele Profile auf einem Host?

Getrennte VMs kosten Geld und IPv4; getrennte Container teilen sich weiterhin den Kernel-Port-Raum, sofern Sie nicht sauber mappen. Parallele Profile auf einem VPS funktionieren, wenn jedes Profil einen nicht überlappenden Bind-Port, einen eigenen OS-Benutzer oder ein eigenes Home für Dateirechte und ein dokumentiertes Umgebungspräfix hat — damit niemand aus Versehen das falsche Token in die falsche Unit kopiert. „Profil“ ist hier ein Betriebskonzept: prod/stage/dev oder Team A vs. Team B — nicht drei Kopien desselben Default-Konfigurationspfads.

Port-Matrix: Bind-Adressen vor dem Reverse-Proxy

Entscheiden Sie vor der TLS-Aktivierung, ob Loopback oder öffentliche Bindung nötig ist. Viele Teams halten jedes Gateway an 127.0.0.1 und setzen Nginx oder Caddy auf 0.0.0.0:443; parallele Profile unterscheiden sich dann nur durch den Loopback-Port. Müssen Sie HTTP direkt exponieren, erweitern Sie die Matrix um Firewall-Zeilen je Security-Group. Zu Expositionsmustern und dem Abwägen SSH gegen öffentliches HTTPS siehe 2026 OpenClaw Linux-Cloud-VPS: Minimale Angriffsfläche — Firewall-Vorlage, Gateway-Loopback-Bindung und SSH-Tunnel für die Verwaltungsebene, Entscheidungsmatrix gegenüber HTTPS-Reverse-Proxy im öffentlichen Netz und gestufte FAQ.

systemd-Benutzer-Units: linger, Slices, Log-Grenzen

systemd --user-Dienste unter verschiedenen Linux-Benutzern liefern klare journalctl --user -u …-Grenzen, ohne /etc/systemd/system vollzumüllen. Für Konten, die den Logout überleben sollen: loginctl enable-linger. Ordnen Sie jeder Unit WorkingDirectory= und EnvironmentFile= auf ein profilspezifisches Drop-in zu, damit ein daemon-reload nie zwei Profile zusammenmischt. Auf Systemebene gehen auch Template-Units ([email protected]) — Invariante bleibt: ein Graph-Knoten pro Profil, eine Port-Zeile in der Matrix. Für Erstinstallation, curl vs. Docker und typische Umgebungsfehler auf dem VPS lohnt parallel 2026 OpenClaw Linux-Cloud-VPS in der Praxis: curl-Installation vs. Docker, Umgebungschecks und FAQ zu typischen Fehlern.

# /etc/openclaw/prod.env — Modus 640, Besitzer = Dienstbenutzer
OPENCLAW_STATE_DIR=/var/lib/openclaw/prod
OPENCLAW_CONFIG_PATH=/etc/openclaw/prod.yaml
# Gateway-Listen — muss zur Port-Matrix passen
OPENCLAW_GATEWAY_BIND=127.0.0.1:18789

OPENCLAW_*-Verzeichnisse: State isolieren, nicht nur Config

Konfigurationsdateien liegen auf der Hand; Laufzeit-State (Sessions, lokale Caches, heruntergeladene Artefakte) ist die Stelle für stillen Cross-Talk. Setzen Sie OPENCLAW_STATE_DIR (und begleitende Variablen laut Ihrer Distribution) auf disjunkte Pfade pro Profil — etwa /var/lib/openclaw/prod vs. /var/lib/openclaw/stage — und besitzen Sie sie mit dem passenden Dienstbenutzer. Backups und Quotas folgen dann der Blast-Radius-Logik: Staging löschen berührt keine Prod-Tokens auf der Platte.

Checkliste: reproduzierbares Rollout

Port-Matrix und Env-Dateien gehören ins gleiche Repository wie Ansible oder cloud-init. Änderungen mit systemctl --user daemon-reload (oder System-Template-Reload) einspielen, dann Profile in Abhängigkeitsreihenfolge neu starten: zuerst Abhängigkeiten, zuletzt Edge-Listener. Ein Rollback reicht aus vorheriger Env-Revision plus vorherigem Unit-Drop-in. Persistenz unterscheidet sich von macOS launchd; wenn Sie zusätzlich Cloud-Macs betreiben, halten Sie das mentale Modell in der Doku bewusst getrennt.

Smoke-Test nach neuem Profil

Bevor Sie einen neuen Listener ankündigen: dreistufig prüfen, damit Tickets kurz bleiben. Erst mit ss -lntp verifizieren, dass nur die vorgesehenen Sockets offen sind und jede PID zur erwarteten Unit aus systemctl status passt. Zweitens die Loopback-Zeile der Matrix per curl mit explizitem Health- oder Versionspfad testen, nicht nur die Root-URL. Drittens den öffentlichen Hostnamen über den Reverse-Proxy ansprechen und Response-Header mit dem direkten Loopback-Probe vergleichen — Abweichungen bedeuten fast immer Port-Drift am Upstream, nicht TLS.

ss -lntp | grep -E '18789|18790|18791'
curl -svS http://127.0.0.1:18789/health
curl -svS https://prod-gateway.example.com/health

Wenn noch alles „gesund“ wirkt, aber die falsche Automation feuert, diffen Sie die effektive Umgebung der Unit: systemctl show für den Dienstblock, dann Abgleich mit der eingecheckten Env-Datei. Stille Drift durch manuelle Host-Änderungen ist der Hauptgrund, warum Repo und Live-Maschine nach wochenlangem On-Call auseinanderlaufen.

FAQ: Konflikte in parallelen Setups

„Address already in use“ nach Reboot — eine alte Usersitzung hat außerhalb von systemd eine zweite Kopie laufen lassen; mit ss -lntp PIDs zu Units zuordnen. Falscher Bot antwortet in Staging — Token-Pfad doppelt genutzt; Unit-Dateien auf doppelte EnvironmentFile-Einträge prüfen. Ein Profil füllt die VPS-Platte — Quotas oder Log-Rotation pro OPENCLAW_STATE_DIR, nicht global. HTTPS nur für einen Hostnamen — Proxy-Upstream zeigt auf die falsche Loopback-Zeile; Matrix korrigieren, nicht nur ACME.