OpenClaw mit Docker: das Gateway installieren und härten

OpenClaw installiert sich mit einem einzigen Befehl, und genau das ist das Problem: Am 11. Februar 2026 zählte SecurityScorecard in den ersten vierundzwanzig Stunden seiner Erhebung mehr als vierzigtausend im Internet offene Gateways, davon 35,4 % als anfällig für Remote-Code-Ausführung eingestuft. Docker löst nichts von allein, was zählt, ist, was deine Compose-Datei veröffentlicht, was sie dem Container entzieht, und wo die Secrets leben.

Was ist OpenClaw?

OpenClaw ist ein quelloffener persönlicher Assistent unter MIT-Lizenz, früher unter den Namen Clawdbot und dann Moltbot bekannt. Das ist kein Code-Agent im Sinne von Claude Code oder Codex, sondern ein Gateway, ein permanent laufender Prozess, der eine Weboberfläche (die Control UI) und eine WebSocket-API auf Port 18789 bereitstellt, Messaging-Kanäle anbindet (WhatsApp, Telegram, Discord) und im Namen seines Besitzers „Skills“ ausführt.

Das Sprachmodell kommt von woanders: Das offizielle Image bringt Plugins für Anthropic, OpenAI, xAI und Ollama mit, und du lieferst den Schlüssel oder die Adresse des lokalen Servers. Das Gateway ist damit eine Maschine zur Ausführung von Anweisungen, wobei das Modell nur einer seiner Anbieter ist. Das ist es, was seine Netzwerk-Exposition gefährlich macht, weit mehr als das gewählte Modell.

Warum Docker statt einer lokalen Installation?

Die Dokumentation sagt, Docker sei optional, und funktional hat sie recht. Sicherheitstechnisch ist der Unterschied deutlich. Eine lokale Installation gibt dem Gateway dein Benutzerkonto: deinen persönlichen Ordner, deine SSH-Schlüssel, deinen Schlüsselbund, deine Repositorys. Ein Container gibt ihm einen Benutzer ohne Privilegien, drei Volumes und sonst nichts. Das ist dieselbe Überlegung wie bei Code-Agenten, ausgeführt in Claude Code und Codex absichern: Die einzige Grenze, die hält, ist die, die das Betriebssystem durchsetzt.

Der Preis dafür ist real. Die Systemabhängigkeiten, die manche Skills verlangen (ffmpeg, tmux, ein Browser), sind nicht im Image enthalten, und die Dokumentation ist eindeutig: Binärdateien in einen laufenden Container zu installieren ist eine Falle, man muss sie beim Bauen mit OPENCLAW_IMAGE_APT_PACKAGES einbacken.

Welches Image wählen?

Die Docker-Dokumentation von OpenClaw verzeichnet zwei Repositorys. Die offizielle Registry ist ghcr.io/openclaw/openclaw, mit einem Docker-Hub-Spiegel unter openclaw/openclaw. Ein dritter, alpine/openclaw, ist ein inoffizieller Spiegel, den die Dokumentation ausdrücklich zu meiden bittet, weil er weder dem Veröffentlichungskalender noch der Aufbewahrungsrichtlinie des Projekts folgt.

Ich habe beide am 7. September 2026 heruntergeladen, um den Abstand zu prüfen.

docker pull ghcr.io/openclaw/openclaw:latest   # 2 min 30 s
docker pull alpine/openclaw:latest             # 1 min 28 s

docker run --rm ghcr.io/openclaw/openclaw:latest openclaw --version
# OpenClaw 2026.9.2 (3928bad)

docker run --rm alpine/openclaw:latest openclaw --version
# OpenClaw 2026.6.9

docker image inspect ghcr.io/openclaw/openclaw:latest \
  --format '{{index .Config.Labels "org.opencontainers.image.created"}}'
# 2026-09-05T15:21:16.692Z

Der Spiegel alpine/openclaw war eingefroren auf Version 2026.6.9, gebaut am 21. Juni 2026: fast drei Monate Rückstand, Debian-Sicherheitspatches eingeschlossen. Das offizielle Image dagegen trug Version 2026.9.2, gebaut am 5. September, zwei Tage vor meinem Test. Die Wahl ist keine Geschmacksfrage.

Plane den Platz ein: docker image inspect gibt für das offizielle Image 1,10 GB an Inhalt an, aber die Spalte DISK USAGE von docker images unter Docker 29 zählte 4,43 GB, die tatsächlich auf der Festplatte belegt waren.

Die gehärtete Compose-Datei

Die Dokumentation liefert eine vollständige docker-compose.yml, aber sie setzt ein geklontes Repository und ein Installationsskript voraus. Hier die minimale Version, die ich geschrieben und ausgeführt habe, nur mit dem vorgefertigten Image.

name: openclaw-lab

x-openclaw-env: &openclaw-env
  HOME: /home/node
  OPENCLAW_HOME: /home/node
  OPENCLAW_STATE_DIR: /home/node/.openclaw
  OPENCLAW_CONFIG_DIR: /home/node/.openclaw
  OPENCLAW_CONFIG_PATH: /home/node/.openclaw/openclaw.json
  OPENCLAW_WORKSPACE_DIR: /home/node/.openclaw/workspace
  OPENCLAW_GATEWAY_PORT: "18789"
  OPENCLAW_DISABLE_BONJOUR: "1"
  TZ: Europe/Paris

services:
  gateway:
    image: ghcr.io/openclaw/openclaw:2026.9.2
    container_name: openclaw-lab-gateway
    init: true
    restart: unless-stopped
    env_file:
      - path: .env          # das Token lebt hier, nicht im Compose
        required: true
    environment: *openclaw-env
    command: ["node", "openclaw.mjs", "gateway", "--bind", "lan", "--port", "18789"]
    ports:
      - "127.0.0.1:18789:18789"
    volumes:
      - state:/home/node/.openclaw
      - workspace:/home/node/.openclaw/workspace
      - authsecrets:/home/node/.config/openclaw
    networks: [openclaw]
    cap_drop: [ALL]
    security_opt:
      - no-new-privileges:true
    healthcheck:
      test: ["CMD", "node", "dist/docker-healthcheck.js"]
      interval: 30s
      timeout: 5s
      retries: 5
      start_period: 20s

  cli:
    image: ghcr.io/openclaw/openclaw:2026.9.2
    profiles: ["cli"]
    network_mode: "service:gateway"
    init: true
    env_file:
      - path: .env
        required: true
    environment: *openclaw-env
    entrypoint: ["node", "openclaw.mjs"]
    volumes:
      - state:/home/node/.openclaw
      - workspace:/home/node/.openclaw/workspace
      - authsecrets:/home/node/.config/openclaw
    cap_drop: [ALL]
    security_opt:
      - no-new-privileges:true
    depends_on: [gateway]

networks:
  openclaw:
    name: openclaw-lab

volumes:
  state:
  workspace:
  authsecrets:

Sechs Entscheidungen verdienen eine Erklärung.

• Das Präfix 127.0.0.1: in ports: Ohne es veröffentlicht Docker auf allen Schnittstellen der Maschine, einschließlich der des lokalen Netzwerks. Das ist der häufigste Fehler, und er erklärt einen guten Teil der von Scannern gefundenen Gateways.
• --bind lan trotzdem: Im Container würde loopback bedeuten „niemand kann mich erreichen, nicht einmal Docker“. Es ist die Veröffentlichung des Ports auf 127.0.0.1 des Hosts, die die Einschränkung leistet, nicht der interne Bindungsmodus.
• cap_drop: [ALL]: Das offizielle Compose entfernt nur NET_RAW und NET_ADMIN. Alles zu entfernen funktioniert ebenfalls, Überprüfung weiter unten.
• Der Dienst cli hinter einem profiles: Er teilt sich den Netzwerk-Stack des Gateways (network_mode: "service:gateway"), befindet sich also innerhalb der Vertrauensgrenze. Das Profil verhindert, dass ein unaufmerksamer docker compose up ihn dauerhaft laufen lässt.
• Benannte Volumes, keine Bind Mounts: Die Dokumentation besteht darauf, den Zustand als Verzeichnis einzuhängen, niemals als isolierte Datei, sonst droht eine Divergenz zwischen Host und Container nach einem Konfigurations-Schreibvorgang.
• env_file statt environment: Das Token erscheint weder im Compose noch im Git-Repository.

Eine Präzisierung zum Port: 18789 war auf meiner Maschine bereits von einem anderen Gateway belegt, ich habe das Labor also auf 127.0.0.1:18889 veröffentlicht. Alle folgenden Messungen beziehen sich auf diesen Port, ersetze ihn bei dir durch 18789, auch in gateway.controlUi.allowedOrigins.

Die Datei .env wird lokal erzeugt und niemals committet.

umask 077
printf 'OPENCLAW_GATEWAY_TOKEN=%s\n' "$(openssl rand -hex 32)" > .env
chmod 600 .env
echo '.env' >> .gitignore

Erster Start: die fehlende Konfiguration

Den Stack einfach so zu starten reicht nicht. Der Container startet, schlägt fehl, startet neu, und beginnt von vorn.

docker compose up -d gateway
docker compose logs gateway | tail -3
# [gateway] loading configuration…
# [gateway] resolving authentication…
# Missing config. Run `openclaw setup` or set gateway.mode=local (or pass --allow-unconfigured).

Mit restart: unless-stopped war Docker bei elf Neustarts angekommen, bevor ich mir die Protokolle ansah, und der Container war als unhealthy markiert. Das Gateway verweigert den Dienst ohne ausdrückliche Konfiguration: Das ist eine gute Voreinstellung, aber man muss es wissen. Die Korrektur erfordert keinen einzigen Anbieterschlüssel.

docker compose stop gateway

docker compose run --rm -T --no-deps --entrypoint node gateway openclaw.mjs \
  config set --batch-json '[
    {"path":"gateway.mode","value":"local"},
    {"path":"gateway.bind","value":"lan"},
    {"path":"gateway.auth.mode","value":"token"},
    {"path":"gateway.controlUi.allowedOrigins","value":["http://127.0.0.1:18789"]}
  ]'
# Updated 4 config paths. Restart the gateway to apply.

docker compose up -d --force-recreate gateway

Das --no-deps --entrypoint node ist nicht dekorativ: Der Dienst cli teilt sich den Netzwerk-Stack des Gateways und funktioniert daher erst, wenn der Container gateway erstellt ist. Um die Konfiguration vor dem ersten Start zu schreiben, muss man über das Image des Gateways selbst gehen.

Das gestoppte Ergebnis: /healthz antwortete mit 200 nach 7,6 Sekunden, und Docker markierte den Container nach 11,9 Sekunden als healthy. Ein Warmstart, mit bereits initialisiertem Zustand, sinkt auf 5,0 Sekunden.

curl -s http://127.0.0.1:18789/healthz   # {"ok":true,"status":"live"}
curl -s http://127.0.0.1:18789/startupz  # {"ok":true,"status":"started"}
curl -s http://127.0.0.1:18789/readyz    # {"ready":true}

Die Start-Protokolle sind gesprächig, und aufschlussreich.

[gateway] ⚠️  Gateway is binding to a non-loopback address. Ensure authentication
          is configured before exposing to public networks.
[gateway] agent model: openai/gpt-5.6-sol (thinking=medium, fast=off)
[gateway] http server listening (13 plugins: anthropic, browser, canvas,
          cua-computer, device-pair, file-transfer, geolocation, linux-node,
          memory-core, ollama, openai, talk-voice, xai; 2.7s)
[gateway] log file: /tmp/openclaw/openclaw-2026-09-07.log
[gateway] remote model catalog updated; restart the Gateway to apply it

Beachte die letzte Zeile: Ohne einen einzigen konfigurierten Schlüssel hat das Gateway im Internet einen Modellkatalog abgerufen. Ein „ruhendes“ Gateway geht trotzdem ins Netz.

Die geschriebene Konfigurationsdatei ist 348 Byte groß und enthält kein Secret: Das Token bleibt in der Umgebungsvariable.

{
  "gateway": {
    "mode": "local",
    "bind": "lan",
    "auth": { "mode": "token" },
    "controlUi": { "allowedOrigins": ["http://127.0.0.1:18789"] }
  },
  "meta": { "lastTouchedVersion": "2026.9.2" }
}

Daneben wog state/openclaw.sqlite bereits 1,5 MB. Dort landen die OAuth-Token, im Klartext: Die Dokumentation verlangt, dieses Verzeichnis und seine Backups wie Zugangsdaten zu behandeln.

Was die Härtung wirklich blockiert

Drei Überprüfungen sind besser als eine Absichtserklärung.

Die Capabilities und der Benutzer

docker compose exec -T gateway sh -lc \
  'grep -E "^Cap(Prm|Eff|Bnd)" /proc/1/status; id; grep NoNewPrivs /proc/self/status'
# CapPrm: 0000000000000000
# CapEff: 0000000000000000
# CapBnd: 0000000000000000
# uid=1000(node) gid=1000(node) groups=1000(node)
# NoNewPrivs: 1

Keine Capability, unprivilegierter Benutzer, Rechteausweitung unmöglich. Das offizielle Image erledigt bereits die halbe Arbeit: Es läuft als node (uid 1000) und startet tini als Prozess 1.

Der auf der Loopback-Schnittstelle veröffentlichte Port schützt nicht vor Docker

Das ist das Ergebnis, das mich am meisten überrascht hat. Der Port ist nur auf 127.0.0.1 veröffentlicht, doch ein beliebiger Container, selbst auf einem anderen Docker-Netzwerk, erreicht das Gateway trotzdem über seine Bridge-Adresse.

GWIP=$(docker inspect -f \
  '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' openclaw-lab-gateway)
echo "$GWIP"   # 172.29.0.2

# vom Standardnetzwerk aus, nicht dem des Labors
docker run --rm alpine:3.22 sh -lc \
  "apk add --no-cache curl >/dev/null; \
   curl -s -o /dev/null -w '%{http_code}\n' http://$GWIP:18789/healthz"
# 200

Das Präfix 127.0.0.1: schließt die Schnittstellen der Maschine, nicht das Netzwerk des Docker-Daemons. Wenn du andere Container auf derselben Maschine betreibst, genügt einer von ihnen, kompromittiert, um mit dem Gateway zu sprechen. Die Abhilfe ist die Authentifizierung des Gateways und, auf einem Linux-Server, Regeln in der Kette DOCKER-USER: Die Härtungsdokumentation von OpenClaw liefert dafür einen vollständigen Satz für UFW, weil die üblichen INPUT-Regeln den von Docker veröffentlichten Datenverkehr nie sehen.

Das interne Netzwerk kostet mehr, als es scheint

Der nächste Reflex ist, das Netzwerk auf internal: true umzustellen. Ich habe gemessen, was das wegnimmt.

# docker-compose.internal.yml
networks:
  openclaw:
    internal: true

Zwei Folgen sind kontraintuitiv. Erstens ignoriert Docker Compose auf einem internen Netzwerk stillschweigend den Abschnitt ports: docker compose ps zeigt 18789/tcp statt 127.0.0.1:18789->18789/tcp, ohne die geringste Warnung, und die Control UI wird unerreichbar. Zweitens löst host.docker.internal weiterhin auf, routet aber nicht mehr: Ein Ollama, das auf der Host-Maschine läuft, ist ebenfalls nicht erreichbar.

Das interne Netzwerk lässt sich also nur für ein Gateway nutzen, das vollständig über docker compose exec gesteuert wird, mit einem Modell, das von einem anderen Container desselben Netzwerks bedient wird. Für alles andere ist die richtige Antwort eine eigene Bridge plus ein SSH-Tunnel: Die Dokumentation von OpenClaw empfiehlt im Übrigen Tailscale Serve statt einer LAN-Verbindung.

Ein Modell verbinden, ohne einen Schlüssel im Compose zu schreiben

Es gibt drei Wege, und keiner verlangt, einen Schlüssel in eine versionierte Datei zu kleben.

1. Ein entfernter Anbieter: Der Schlüssel kommt in .env (ANTHROPIC_API_KEY, OPENAI_API_KEY), gelesen von env_file. Er gelangt nie in openclaw.json.
2. Ein lokales Modell auf der Host-Maschine: In einem Container bezeichnet 127.0.0.1 den Container selbst. Die Dokumentation schreibt für Ollama http://host.docker.internal:11434 vor, und der Host muss über seine Loopback-Schnittstelle hinaus lauschen (OLLAMA_HOST=0.0.0.0:11434 ollama serve).
3. Die Claude-Code-Binärdatei im Container: möglich, aber /home/node muss in einem benannten Volume persistiert werden, sonst löscht die nächste Image-Aktualisierung die Installation und die Authentifizierung.

Während dieses Tests wurde kein Schlüssel eingegeben, und das ollama-Plugin wird vom Gateway durchaus geladen. Der Weg zum lokalen Modell lässt sich auch ohne Schlüssel prüfen: Mit einem auf Port 11434 des Hosts veröffentlichten Ollama antwortet http://host.docker.internal:11434/v1 aus einem Container des Bridge-Netzwerks mit 200 und im OpenAI-Format. Genau diese Adresse verlangt die Dokumentation, und genau deshalb würde 127.0.0.1 nicht funktionieren: In einem Container meint es den Container.

Das Image aktualisieren, ohne den Zustand zu zerstören

Die beweglichen Tags (latest, main, extended-stable) werden jede Woche aus derselben Quelle neu gebaut, um die Sicherheitspatches des Basissystems zwischen zwei OpenClaw-Versionen nachzuziehen. Jeder Neubau veröffentlicht außerdem ein unveränderliches, datiertes Tag nach dem Muster 2026.8.1-r20260820: Genau dieses solltest du festnageln, wenn ein Deployment keinem beweglichen Tag folgen soll.

Beim Imagewechsel wendet das Gateway seine Migrationen beim Start an. Gelingt ihr das nicht, beendet sie sich mit einem Fehler, statt sich für gesund zu erklären, und mit einer Neustart-Richtlinie siehst du eine Schleife. Die dokumentierte Abhilfe ist, dasselbe Image einmal mit openclaw doctor --fix auf denselben Volumes laufen zu lassen und dann normal neu zu starten.

docker compose pull
docker run --rm -v openclaw-lab_state:/home/node/.openclaw \
  ghcr.io/openclaw/openclaw:2026.9.2 openclaw doctor --fix
docker compose up -d gateway

Seine Skills auf ClawHub auswählen

Das Image liefert 53 einsatzbereite Skills: 51 im Basispaket, 2 als Extra. Das ist schon viel, und es reicht für die meisten Anwendungsfälle. Der Rest kommt von ClawHub, der öffentlichen Registry, dort beginnen die Schwierigkeiten. Das Format ist dasselbe SKILL.md wie im Leitfaden zu Agent Skills beschrieben: ein YAML-Frontmatter, ein Markdown-Hauptteil, Begleitdateien.

Die Dokumentation zu den Skills nimmt kein Blatt vor den Mund: Sie verlangt, jeden fremden Skill wie nicht vertrauenswürdigen Code zu behandeln und ihn vor der Aktivierung zu lesen. Die Zahlen geben ihr recht. Eine am 1. März 2026 veröffentlichte Erhebung schreibt Antiy CERT 1.184 bestätigte bösartige Skills auf ClawHub zu, also rund ein Paket von fünf auf dem Höhepunkt der Kampagne.

skills verify fragt die Registry ab, ohne etwas zu installieren, und das ist willkommen. Sein Gesamturteil dagegen verdient es, aufgeklappt zu werden. Hier, was es für einen populären Docker-Skill zum Testzeitpunkt zurückgibt.

docker compose run --rm -T cli skills verify @ivangdavila/docker

# decision            : pass
# security.status     : clean
# security.verdict    : benign      (confidence: high)
# signature.status    : unsigned
# provenance.source   : unavailable
# signals.staticScan  : suspicious  -> suspicious.exposed_secret_literal
# signals.skillSpector: suspicious
# signals.virusTotal  : clean
# artifact.files      : 16 Dateien, darunter SKILL.md (24.283 Byte)

Zwei der drei Signale sagen „verdächtig“, das Paket ist nicht signiert, seine GitHub-Herkunft ist nicht registriert, und das aggregierte Urteil bleibt „harmlos, hohe Zuversicht“. Die lesbare Zusammenfassung spricht von einem lokalen Assistenten ohne erkannte Exfiltration, und nicht dieser Skill steht hier zur Debatte. Merke dir die Kluft zwischen den Signalen und der Schlussfolgerung: Ein grüner Score ist keine Lektüre.

Die Regel, die ich mir merke, hat drei Punkte: das SKILL.md vor der Installation lesen (skills info gibt den genauen Pfad der Datei an), jeden Skill ablehnen, der ohne funktionale Notwendigkeit ins Netz geht, und die 53 mit dem Image gelieferten Skills bevorzugen, solange sie ausreichen. Das Feld security.installPolicy der Konfiguration erlaubt es, diese Leitplanke durchzusetzen, statt auf Disziplin zu setzen.

MCP-Server hinzufügen

Das Gateway verwaltet seine MCP-Server in mcp.servers, mit einer vollständigen Befehlspalette: add (das den Server prüft, bevor es ihn registriert), probe, doctor, status, tools, um die freigegebenen Werkzeuge zu filtern, und login / logout für OAuth-Server.

docker compose run --rm -T cli mcp doctor     # statische Konfigurationsfehler
docker compose run --rm -T cli mcp status     # Transporte, ohne sich zu verbinden
docker compose run --rm -T cli mcp probe      # echte Verbindung, listet die Fähigkeiten auf
docker compose run --rm -T cli mcp tools      # Include/Exclude-Filter pro Server

Zwei Reflexe sind es wert, beibehalten zu werden. mcp tools existiert, nutze es. Ein MCP-Server gibt oft dreißig Werkzeuge frei, wenn du nur drei willst, und jedes zusätzliche Werkzeug ist eine Beschreibung, die das Modell als Anweisung liest. Und ein MCP-Server über STDIO läuft im Container des Gateways, also mit dessen Volumes und Umgebungsvariablen. Die Forschungsnotiz der Cloud Security Alliance vom 4. Mai 2026 empfiehlt genau das Gegenteil: einen eigenen Container pro Server, ohne Zugriff auf die Zugangsdaten des Hosts. Das Thema wird ausführlich in einen MCP-Server in PHP erstellen behandelt.

OpenClaw, Claude Code oder Hermes Agent?

Die drei spielen nicht am selben Ort, und sie zu verwechseln führt zu falschen Entscheidungen.

Claude Code lauscht auf nichts: Schließe das Terminal, die Angriffsfläche verschwindet. OpenClaw lauscht permanent, von Konstruktion her, weil genau das von ihm verlangt wird: eine Telegram-Nachricht um drei Uhr morgens zu beantworten. Hermes Agent, auf dieselbe Weise in einem eigenen Artikel installiert, besetzt eine dritte Position: ein Agent, der von vornherein dafür gedacht ist, im Container zu laufen. Der Überblick über Kommandozeilen-Agenten ordnet die anderen ein, und OpenCode deckt den Fall des Open-Source-Code-Agenten ab.

Alles löschen

Ein Labor wird abgebaut. docker compose down allein lässt die Volumes zurück, mit der SQLite-Datenbank und ihren Token.

docker compose down --volumes --remove-orphans
docker rmi ghcr.io/openclaw/openclaw:2026.9.2 alpine/openclaw:latest
rm -f .env

# Kontrolle: nichts darf übrig bleiben
docker ps -a --format '{{.Names}}' | grep -i claw
docker volume ls --format '{{.Name}}' | grep -i claw
docker images --format '{{.Repository}}' | grep -i claw
docker network ls --format '{{.Name}}' | grep -i claw

Was du dir merken solltest

• Nimm ghcr.io/openclaw/openclaw: Der Spiegel alpine/openclaw hatte am Testtag drei Monate Rückstand (2026.6.9 gegenüber 2026.9.2).
• Das Gateway verweigert den Start ohne Konfiguration und gerät in eine Neustart-Schleife: Schreibe gateway.mode=local vor dem ersten up.
• Auf 127.0.0.1 zu veröffentlichen schließt die Schnittstellen der Maschine, nicht das Docker-Netzwerk: Ein benachbarter Container erreichte das Gateway mit HTTP 200.
• internal: true entfernt stillschweigend den veröffentlichten Port und den Zugriff auf host.docker.internal: nur für Gateways, die über exec gesteuert werden.
• Das Token lebt in .env, niemals im Compose. state/openclaw.sqlite enthält OAuth-Token im Klartext und wird wie ein Secret behandelt.
• Auf ClawHub kann ein Urteil „clean“ zwei Signale „suspect“, ein unsigniertes Paket und eine unbekannte Herkunft überdecken. Lies das SKILL.md.