# Parallelbetrieb mit OpenClaw

## Empfehlung

Lass OpenClaw in einem **separaten Compose-Projekt** laufen.

Das Repo hier geht davon aus, dass OpenClaw bereits existiert oder separat gepflegt wird. Dadurch bleiben Updates, Logik und Fehlersuche voneinander getrennt.

## Regeln gegen Konflikte

- andere Host-Ports als Hermes verwenden
- eigenes Volume oder eigener Basisordner fuer OpenClaw
- eigener Compose-Projektname
- wenn moeglich kein gemeinsamer Schreibzugriff auf denselben Host-Pfad
- Shared-Netz nur verwenden, wenn es einen echten Grund gibt
- fuer Internetzugang idealerweise dasselbe Muster verwenden: **eigenes externes Macvlan-Netz auf `br0` oder bewusst dasselbe externe `br0`-Netz mit eigener IP**

## Sichere Defaults

Hermes expose't nur lokal:

- `127.0.0.1:18642/tcp` fuer API/Health
- `127.0.0.1:19119/tcp` fuer Dashboard, falls aktiviert

OpenClaw sollte auf einem **anderen** Host-Port laufen, z. B. `127.0.0.1:18080` oder `127.0.0.1:18081`, je nach Image.

## `br0`-Hinweis

Wenn OpenClaw wie Hermes ueber `br0` ins Netz soll, hast du zwei saubere Optionen:

1. **gleiches externes Docker-Netz** verwenden, mit eigener statischer IP je Container
2. **separates zweites Macvlan-Netz** auf demselben Parent `br0` anlegen

Option 1 ist einfacher. Option 2 ist strenger getrennt.

## Wann das Shared-Netz sinnvoll ist

Nur wenn sich OpenClaw und Hermes wirklich gegenseitig erreichen muessen, z. B. fuer einen lokalen Upstream-Endpoint oder Kontrollpfad. Ansonsten reicht die komplette Trennung.

## Beispiel fuer OpenClaw

Siehe `compose/openclaw.override.example.yaml`.

Das ist bewusst nur eine Vorlage, weil der OpenClaw-Docker-Oekosystem-Stand momentan fragmentiert ist und verschiedene Images unterschiedliche Environment-Variablen erwarten.