Docker

Es gibt drei aufeinander aufbauende Images — ein generisches Runtime-Image und zwei darauf aufsetzende Images:

Image	Dockerfile	Inhalt
`agent-runtime`	`Dockerfile`	Generisches OpenClaw-Runtime-Image mit Werkzeugkasten (OpenClaw, Bun, Node, `gh`, Claude Code, Codex, `pc`, Python, `uv`), der `pc-runtime`-CLI und dem Engine-Plugin. Enthält nur Agent `main` — bewusst keine weiteren Agenten.
`agents`	`Dockerfile.agents`	Setzt auf das Runtime-Image auf, ergänzt `az` (Azure DevOps) und die kompilierte `coding-agent`-Binary; bringt die Coding-Agenten und den zyklischen Support-Agent mit.
`demo-agents`	`Dockerfile.demo`	Setzt auf das Runtime-Image auf und ergänzt die minimalen Diagnose-Agenten `demo-orchestrator` und `demo-worker` (ohne GitHub/Azure/Engine).

Die Gateway startet mit --allow-unconfigured, kommt also auch ohne vorhandene Konfiguration hoch.

Agenten werden beim Container-Start registriert

Das Basis-Dockerfile backt keine Agenten ein (nur main). Die abgeleiteten Images (Dockerfile.agents / Dockerfile.demo) registrieren ihre Agenten zwar zur Build-Zeit via install.mjs — diese Registrierung liegt aber unter ~/.openclaw und wird zur Laufzeit von einem gemounteten Volume/PVC überlagert.

Deshalb registriert das docker-entrypoint.sh die Agenten bei jedem Container-Start neu (gegen das gemountete ~/.openclaw, idempotent) und startet danach die Gateway. Die Build-Zeit-Registrierung dient nur Cache, Validierung und Volume-Seeding.

Volume überlagert Build-Zeit-Registrierung. Ein frisches Docker-Named-Volume wird beim ersten Mount aus dem Image geseedet — die Registrierung überlebt. Ein leeres Kubernetes-PVC wird dagegen nicht geseedet und überdeckt ~/.openclaw vollständig. Ohne Start-Registrierung existierte im Pod nur Agent main. In k8s erledigt das ein initContainer — siehe Kubernetes / k3s.

Lokale Compose-Wege

Jedes Agenten-Image hat sein eigenes Compose mit eigenem Gateway-Port, damit die Stacks parallel laufen können:

Compose-Datei	Agenten	Gateway-Port
`docker-compose.yml`	nur `main`	`18789`
`docker-compose.agents.yml`	Coding-Agenten	`18791`
`docker-compose.support.yml`	Support-Agent (baut das `agents`-Image, registriert per `PC_INSTALL_AGENTS=support-agent` nur den Support-Agenten)	`18790`
`docker-compose.demo.yml`	Demo-Agenten (Diagnose)	—


docker network create pc-shared   # einmalig: gemeinsames Netz
 
# Runtime (nur main):
docker compose up -d
 
# Coding-Agenten:
docker compose -f docker-compose.agents.yml up -d
 
# Support-Agent:
docker compose -f docker-compose.support.yml up -d
 
# Demo-Agenten (Diagnose):
docker compose -f docker-compose.demo.yml up -d

Der schnellste Einstieg in die Runtime führt über Agent Runtime.

Veröffentlichte Images

Beim Pushen eines v*-Tags baut der Publish-Workflow die Images als Multi-Arch (amd64 + arm64, jeweils auf nativem Runner) und veröffentlicht sie nach GitHub (GHCR): ghcr.io/processcube-io/agent-runtime, ghcr.io/processcube-io/agents und ghcr.io/processcube-io/demo-agents (jedes agents-Image durchläuft dabei einen Container-Smoke-Test). Parallel dazu wird das npm-Paket @processcube-io/agents publiziert.