Hermes Agent unter Docker: Installation und Härtung getestet

„Hermes agent“ und „hermes vs openclaw“ tauchen regelmäßig in französischen Suchanfragen auf, aber der Name ist mehrdeutig: Mehrere Projekte heißen Hermes. Nur eines wird in den auf 2026 datierten Quellen mit OpenClaw verglichen. Es wird hier identifiziert, installiert und unter Docker in einem isolierten Labor gehärtet, wobei bei jedem Schritt unterschieden wird, was tatsächlich gelaufen ist und was nur dokumentiert bleibt.

Welcher Hermes Agent, genau?

Das von diesen Suchanfragen gemeinte Projekt ist Hermes Agent, entwickelt von Nous Research und unter MIT-Lizenz im Repository NousResearch/hermes-agent veröffentlicht. Das Repository zeigte am 7. September 2026 242.851 Sterne und 49.953 Forks, bei einer Erstellung am 22. Juli 2025. Seine Beschreibung passt in einen Satz: „the agent that grows with you“. Ein einzelner Agent, der seine eigenen Fähigkeiten aus der Erfahrung heraus erschafft und verfeinert, im Gegensatz zu einer Plattform, die mehrere Agenten orchestriert. Dieser philosophische Gegensatz kehrt in den 2026 veröffentlichten Vergleichen mit OpenClaw wieder und bestätigt, dass hinter den Anfragen „hermes vs openclaw“ genau dieses Projekt steht.

Zwei Namensfallen sind zu vermeiden. hermes-webui ist ein Drittanbieter-Web-Client, der nicht von Nous Research gepflegt wird. „HermesHub“ bezeichnet einen Community-Index für Fähigkeiten, getrennt vom offiziellen, ins CLI integrierten Hub. Beide lassen sich in Suchergebnissen leicht mit dem Hauptprojekt verwechseln. Hermes Agent reiht sich außerdem in die Liste ein, die unser Überblick über Kommandozeilen-Code-Agenten miteinander vergleicht.

Hermes Agent mit Docker installieren

Das offizielle Image ist nousresearch/hermes-agent. Die Docker-Dokumentation beschreibt einen interaktiven Konfigurationsassistenten und anschließend einen Start als Dienst:

mkdir -p ~/.hermes
docker run -it --rm -v ~/.hermes:/opt/data nousresearch/hermes-agent setup

docker run -d --name hermes --restart unless-stopped \
  -v ~/.hermes:/opt/data -p 8642:8642 \
  nousresearch/hermes-agent gateway run

Das Labor weiter unten übernimmt diesen interaktiven Assistenten nicht: Es geht direkt über ein gehärtetes Compose, das gateway run auf einem anderen Netzwerk und mit anderen Ports nachbildet. Port 8642 dient sowohl als Gesundheitscheck als auch als OpenAI-API-kompatible Passerelle, Port 9119, optional, dient dem Web-Dashboard. Das auf /opt/data eingehängte Volume enthält .env, config.yaml, SOUL.md, sowie die Ordner sessions/, memories/ und skills/. Die Dokumentation empfiehlt je nach Nutzung 1 bis 4 GB Speicher und 1 bis 2 Kerne.

Ich habe die letzte datierte Version festgenagelt statt latest. Die GitHub-Releases zeigen die v0.21.0 (Tag v2026.8.31, „The Pantheon Release“), veröffentlicht am 31. August 2026, rund 5.800 Commits und 760 Mitwirkende nach der vorherigen Version. Der Zug dauerte auf dieser Maschine 1 Min. 47 s für 908 MB komprimiert (3,93 GB nach dem Entpacken, arm64-Architektur). Das Image v2026.4.30, 8,2 GB, verortet einen echten internen Architekturwechsel zwischen April und Mai 2026. Dieser Prüfpunkt startet noch mit tini, während die August-Version s6-overlay als PID 1 verwendet, mit Abgabe der Privilegien an einen Benutzer hermes (UID 10000 standardmäßig). Nebenbei bemerkte Kuriosität: Die Docker-Hub-Registry zeigt, dass das Gewicht des Images von rund 2,5 GB im April auf weniger als 900 MB seit Juli 2026 gesunken ist.

Die Konfiguration härten: Netzwerk, Ports, Secrets

Die offizielle docker-compose.yml deklariert network_mode: host sowohl für das Gateway als auch für das Dashboard, praktisch, aber ohne jegliche Netzwerkisolation. Für das Labor habe ich eine gehärtete Version gebaut: eigenes Netzwerk, Ports nur auf der Loopback-Schnittstelle veröffentlicht, Secrets außerhalb der Compose-Datei.

services:
  hermes:
    image: nousresearch/hermes-agent:v2026.8.31
    container_name: hermes-lab
    networks:
      - hermes_lab
    ports:
      - "127.0.0.1:8642:8642"
      - "127.0.0.1:9119:9119"
    volumes:
      - ./data:/opt/data
    env_file:
      - ./secrets/hermes.env     # eventueller Anbieterschlüssel, außerhalb des Repositorys
    environment:
      - HERMES_UID=501
      - HERMES_GID=20
      - HERMES_DASHBOARD=1
      - HERMES_DASHBOARD_HOST=0.0.0.0
      - API_SERVER_HOST=0.0.0.0   # siehe weiter unten: ohne diese Zeile bleibt /health
    deploy:                       #   trotz veröffentlichtem Port unerreichbar
      resources:
        limits:
          memory: 1g
          cpus: "1.0"
    command: ["gateway", "run"]

networks:
  hermes_lab:
    driver: bridge

Zwei Einstellungen des offiziellen Compose verhalten sich anders, als die Dokumentation erwarten lässt. Der erste betrifft das Netzwerk. Es als internal: true zu markieren, um jeden Internetausgang zu kappen, kappt auch den veröffentlichten Port. Im Labor erhält eine vom Inneren des Containers gestartete Anfrage ein HTTP 200 auf /health. Dieselbe Anfrage von der Host-Maschine, über den veröffentlichten Port, erhält keine Antwort. Ein Ausgangsversuch zu example.com scheitert an einer unmöglichen DNS-Auflösung. Die Isolation hält also, doch sie reißt die legitime lokale Nutzung des Ports mit sich. internal: true eignet sich nur für ein vollständig offline betriebenes Labor. Für einen echten Einsatz mit einem entfernten Modellanbieter läuft die Isolation über ein klassisches eigenes Netzwerk und eine ausgehende Firewall, nicht über diese Einstellung.

Der zweite überrascht mehr. Selbst auf dem eigenen, nicht als internal markierten Netzwerk blieb der veröffentlichte Port unerreichbar, TCP-Verbindung akzeptiert, leere HTTP-Antwort. Eine Suche im installierten Code liefert die genaue Erklärung:

docker exec hermes-lab grep -r API_SERVER_HOST /opt/hermes/hermes_cli/security_audit_startup.py

host = extra.get("host") or os.environ.get("API_SERVER_HOST", "127.0.0.1")

Standardmäßig lauscht das Gateway nur auf der Loopback-Schnittstelle innerhalb des Containers, unabhängig vom gewählten Docker-Netzwerk. Daher die Zeile API_SERVER_HOST=0.0.0.0 im obigen Compose: Sie ändert nichts an der externen Exposition, da bereits das Präfix 127.0.0.1: des veröffentlichten Ports sie einschränkt. Nach der Korrektur geprüft: curl http://127.0.0.1:8642/health antwortet vom Host aus mit 200, dieselbe Anfrage an die lokale Netzwerkadresse der Maschine (192.168.x.x) erhält keine Antwort. Was das Dashboard betrifft, weigert es sich schlicht, auf einer nicht lokalen Schnittstelle zu starten, ohne konfigurierten Authentifizierungsanbieter:

Refusing to bind dashboard to 0.0.0.0 — the auth gate engages on non-loopback
binds (0.0.0.0), but no auth providers are registered.
There is no unauthenticated public-dashboard option.

Ein von Haus aus gesundes Verhalten, mit einem in den Protokollen sichtbaren Nebeneffekt. So belassen, ohne konfigurierte Authentifizierung, bleibt der Dienst nicht einfach deaktiviert, er schlägt fehl und startet dann unter der Aufsicht von s6 in einer Schleife neu. Nichts Schwerwiegendes, aber laut genug, um es wert zu sein, gewusst zu werden. Letzter geprüfter Punkt: Das Limit deploy.resources.limits des obigen Compose greift tatsächlich auch außerhalb des Swarm-Modus mit Docker Compose v5.1.0. docker inspect bestätigt Memory=1073741824 und NanoCpus=1000000000 am gestarteten Container. Ältere Compose-Versionen ignorierten deploy: außerhalb von Swarm.

Was man beim Start beobachtet

Sobald die Konfiguration korrigiert ist, ergeben docker compose up -d und anschließend eine Abfrage von /health alle 0,3 Sekunden eine Startzeit von rund 18,9 Sekunden bei kaltem Start (leerer Datenordner) und 16,6 Sekunden nach einem einfachen Neustart. Der Unterschied liegt vor allem an einer internen Aufwärmphase, die die Protokolle ausdrücklich „turn-machinery warm-up“ nennen und die den Eingang nach 20 Sekunden öffnet, auch wenn sie im Hintergrund weiterläuft. Im Inneren bestätigt ps aux, dass der Supervisor root bleibt, dass aber der Prozess hermes gateway run tatsächlich unter dem unprivilegierten Benutzer hermes läuft. Das Start-Banner zeigt Hermes Agent v0.21.0 (2026.8.31), Python 3.13.5 und das OpenAI-SDK 2.24.0.

Sich mit einem Modell verbinden

Die beim ersten Start erzeugte Datei .env listet, vollständig auskommentiert, rund dreißig Anbieter (Fireworks, OpenRouter, NovitaAI, Gemini, z.ai, Kimi, MiniMax, OpenCode Zen…) und ebenso viele Werkzeugschlüssel (Firecrawl, Exa, Browserbase), keiner davon ist aktiv. „Ollama“ erscheint dort nur in der Form OLLAMA_API_KEY, dem kostenpflichtigen Cloud-Dienst von Ollama, und kein Eintrag zielt auf eine lokale Instanz. Die eingebaute Diagnose bestätigt den neutralen Zustand der Installation:

docker exec hermes-lab hermes doctor

✓ No active security advisories
✓ No suspicious MCP stdio commands
✓ Version files consistent (0.21.0)
◆ API Connectivity
  ⚠ OpenRouter API (not configured)
◆ Memory Provider
  ✓ Built-in memory active (no external provider configured — this is fine)

Einziger Wert, der nach dem Test in .env vorhanden ist: ein API_SERVER_KEY, automatisch vom Container erzeugt, um sein eigenes lokales Gateway zu schützen. Er erscheint nie im Klartext in den Protokollen, niemand hat ihn eingegeben, und er hat keinen Bezug zu einem Konto bei einem Modellanbieter.

Die Fähigkeiten, und wie man eine vor der Installation prüft

Die Fähigkeiten („Skills“) leben in /opt/data/skills/ und folgen dem offenen Standard Agent Skills, der in unserem Leitfaden zum SKILL.md beschrieben wird. hermes skills list zählte in diesem Labor 53 aktivierte integrierte Fähigkeiten, keine vom Hub installiert. Die Installation erfolgt über eine Registry: hermes skills install official/security/1password oder hermes skills install openai/skills/k8s, zum Beispiel. Bevor man irgendetwas installiert, ersparen zwei Befehle blindes Vertrauen:

hermes skills inspect openai/skills/k8s   # Metadaten, Quell-Repository, Audit bereits verfügbar
hermes skills audit                       # scannt alle vom Hub installierten Skills erneut

Der eingebaute Scanner stuft jedes Ergebnis in drei Stufen ein: dangerous blockiert die Installation, warn/caution lässt sich mit --force umgehen, advisory bleibt rein informativ. Laut der offiziellen Dokumentation fasste der Hub am 26. August 2026 90.700 Fähigkeiten auf 11 Registries zusammen, nicht zu verwechseln mit „HermesHub“, dem oben erwähnten Community-Index eines Drittanbieters.

MCP: Werkzeuge anbinden, oder Hermes als Server freigeben

hermes mcp catalog, im Labor ausgeführt, zeigt einen bereits langen Katalog einsatzbereiter Server (Airtable, Atlassian, Cloudflare, ClickUp, Buildkite…). hermes mcp list bestätigte, dass keiner konfiguriert war, wie bei einer neuen Installation zu erwarten. Das Hinzufügen erfolgt mit einer bekannten Voreinstellung oder einem manuellen Eintrag:

hermes mcp add codex --preset codex
hermes mcp add filesystem --command npx --args "-y @modelcontextprotocol/server-filesystem /projet"

In die andere Richtung gibt hermes mcp serve eine Hermes-Sitzung als MCP-Server für einen externen Client frei, Claude Code zum Beispiel, indem man dessen Konfiguration auf den Befehl hermes mcp serve verweist. Sicherheitstechnisch präzisiert die Dokumentation drei Dinge. Entfernte OAuth-Token werden mit Berechtigungen 0600 zwischengespeichert. Die Erneuerung läuft über PKCE. Bei Servern in stdio werden nur die ausdrücklich deklarierten Umgebungsvariablen, plus eine minimale Basis, an den Unterprozess übergeben. Das begrenzt Secret-Lecks zu einem schlecht auditierten MCP-Server eines Drittanbieters begrenzt, ein Risiko, das bereits in unserem Artikel über Code-Agenten, Sandbox und Berechtigungen dokumentiert ist.

Hermes Agent gegen OpenClaw: ein ehrlicher Vergleich

Beide Projekte sind quelloffen, installieren sich unter Docker und unterstützen Skills und MCP, es ist ihre Philosophie, die auseinandergeht. OpenClaw strukturiert ein Gateway, das mehrere Agenten, Konnektoren und Kanäle routet und überwacht. Hermes Agent setzt auf einen einzelnen Agenten, der seine eigenen Fähigkeiten im Lauf der Nutzung anhäuft. Unser Artikel über die gehärtete Installation von OpenClaw behandelt dieselbe Übung auf der OpenClaw-Seite, beide lesen sich wie ein Spiegelbild.

Zur Sicherheit verzeichnet eine Forschungsnotiz der Cloud Security Alliance vom 4. Mai 2026 im selben Zeitraum neun CVEs für OpenClaw, darunter eine kritische mit Bewertung 9,9, gegenüber zwei für den Kern von Hermes Agent. CVE-2026-7396 betrifft einen Path Traversal im WeCom-Adapter (CVSS 4,0), CVE-2026-7397 eine Symlink-Verfolgung in den Datei-Werkzeugen (CVSS 4,8), beide auf Version 0.8.0 und bereits mit 0.9.0 behoben. Eine dritte gelistete CVE betrifft nicht den Agenten, sondern hermes-webui, den bereits oben erwähnten Drittanbieter-Client. Die GitHub-Security-Advisories-Seite des Repositorys verweist ihrerseits auf keinen zum 7. September 2026 veröffentlichten Hinweis: Diese CVEs wurden über externe Kanäle eingereicht, nicht von Nous Research selbst. Bis heute wurde keine Erhebung exponierter Hermes-Instanzen veröffentlicht, die mit der für OpenClaw verifizierten Zahl vergleichbar wäre (42.900 Instanzen, 93 % ohne Authentifizierung, SecurityScorecard 2026), was ihr Fehlen nicht beweist.

Ein datierter Vorfall veranschaulicht, warum die Netzwerkabschottung und das Fehlen eines automatischen Modus genauso zählen wie die Wahl des Projekts. The Hacker News hat am 24. Juli 2026 dokumentiert, einen Fall, bei dem ein Angreifer, der bereits über einen ersten Zugang zum Netzwerk des thailändischen Finanzministeriums verfügte, Hermes Agent auf einem gemieteten Server installierte und anschließend dessen „YOLO“-Modus aktivierte, der die Bestätigungen vor riskanten Befehlen überspringt. Der Agent erkundete daraufhin das Netzwerk ohne Aufsicht, fand Hadoop-Dienste mit Standard-Zugangsdaten und setzte ein Implantat ein. Ein von der Quelle selbst hervorgehobener Punkt: Hermes hat den Einbruch nicht verursacht, er hat dessen nächste Phase automatisiert. Das eigene Netzwerk, die Ports auf der Loopback-Schnittstelle und das Fehlen eines eingegebenen Schlüssels in diesem Labor sollen genau diese Phase verhindern.

Was du dir merken solltest

• Der „Hermes Agent“, der 2026 mit OpenClaw verglichen wird, ist der von Nous Research (NousResearch/hermes-agent, MIT-Lizenz), nicht hermes-webui oder „HermesHub“, zwei Drittanbieter-Projekte mit ähnlichem Namen.
• Letzte getestete datierte Version: v0.21.0 (Tag v2026.8.31, 31. August 2026), installiert über Docker in 1 Min. 47 s (908 MB komprimiert, 3,93 GB entpackt).
• Ein als internal: true markiertes Netzwerk kappt auch den veröffentlichten Port, nicht nur den Internetzugang. Standardmäßig lauscht das Gateway nur auf seiner eigenen Loopback-Schnittstelle (API_SERVER_HOST=127.0.0.1), ausdrücklich zu korrigieren, selbst hinter einem bereits auf 127.0.0.1 beschränkten Port auf der Host-Seite.
• Das Dashboard weigert sich, sich außerhalb der Loopback-Schnittstelle ohne konfigurierte Authentifizierung zu exponieren. Von Haus aus gesund, doch so belassen läuft es in eine Fehlerschleife, statt einfach inaktiv zu bleiben.
• Gemessener Start bei rund 17 bis 19 Sekunden bis zu einem tatsächlich positiven /health, ohne jeglichen Schlüssel oder Zugangsdaten von Anfang bis Ende.
• Im selben Zeitraum verzeichnet die Cloud Security Alliance zwei kleinere CVEs für den Kern von Hermes Agent gegenüber neun für OpenClaw, davon eine kritische. Der Unterschied ist mit Vorsicht zu lesen: für Hermes wurde keine vergleichbare Erhebung zur Exposition veröffentlicht.