Hermes Agent under Docker: installation and hardening tested

“Hermes agent” and “hermes vs openclaw” come up regularly in French searches, but the name is ambiguous: several projects call themselves Hermes. Only one gets compared to OpenClaw in sources dated 2026. It is identified here, installed and hardened under Docker in an isolated lab, marking at every step what actually ran versus what stays purely documented.

Which Hermes Agent, exactly?

The project these searches are actually after is Hermes Agent, developed by Nous Research and published under the MIT licence in the NousResearch/hermes-agent repo. The repo showed 242,851 stars and 49,953 forks on 7 September 2026, for a repository created on 22 July 2025. Its description fits in one sentence: “the agent that grows with you.” A single agent, one that builds and refines its own skills from experience, the opposite of a platform orchestrating several agents. That difference in philosophy keeps coming up in comparisons published in 2026 against OpenClaw, and confirms it is the project behind “hermes vs openclaw” searches.

Two naming traps to avoid. hermes-webui is a third-party web client not maintained by Nous Research. “HermesHub” refers to a community skills index, separate from the official hub built into the CLI. Both are easy to mistake for the main project in search results. Hermes Agent also joins the list our overview of command-line coding agents compares against each other.

Installing Hermes Agent with Docker

The official image is nousresearch/hermes-agent. The Docker documentation describes an interactive setup wizard followed by launching it as a service:

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

The lab further down skips that interactive assistant: it goes straight to a hardened compose file that reproduces gateway run on a different network and different ports. Port 8642 serves both as the health check and as the OpenAI-API-compatible gateway, port 9119, optional, serves the web dashboard. The volume mounted on /opt/data holds .env, config.yaml, SOUL.md, plus the sessions/, memories/ and skills/ folders. The documentation recommends 1 to 4 GB of memory and 1 to 2 cores depending on usage.

I pinned the latest dated version rather than latest. The GitHub releases show v0.21.0 (tag v2026.8.31, “The Pantheon Release”), published on 31 August 2026, around 5,800 commits and 760 contributors on from the previous version. The pull took 1 min 47 s on this machine for 908 MB compressed (3.93 GB once decompressed, arm64 architecture). The v2026.4.30 image, 8.2 GB, places a genuine internal architecture shift between April and May 2026. That checkpoint still boots on tini, while the August version uses s6-overlay as PID 1, dropping privileges to a hermes user (UID 10000 by default). One curiosity noted in passing: the Docker Hub registry shows the image’s weight went from around 2.5 GB in April to under 900 MB since July 2026.

Hardening the configuration: network, ports, secrets

The official docker-compose.yml declares network_mode: host for both the gateway and the dashboard, convenient, but with no network isolation at all. For the lab, I built a hardened version: a dedicated network, ports published on the loopback only, secrets kept out of the compose file.

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     # provider key, if any, kept outside the repo
    environment:
      - HERMES_UID=501
      - HERMES_GID=20
      - HERMES_DASHBOARD=1
      - HERMES_DASHBOARD_HOST=0.0.0.0
      - API_SERVER_HOST=0.0.0.0   # see below: without this line, /health
    deploy:                       #   stays unreachable even with the port published
      resources:
        limits:
          memory: 1g
          cpus: "1.0"
    command: ["gateway", "run"]

networks:
  hermes_lab:
    driver: bridge

Two settings in the official compose behave differently from what the documentation leads you to expect. The first comes down to the network. Marking internal: true to cut off all outbound Internet access also cuts the published port. In the lab, a request fired from inside the container gets an HTTP 200 on /health. The same request from the host machine, on the published port, receives no response at all. An attempt to reach out to example.com fails on an impossible DNS resolution. The isolation holds, then, but it takes legitimate local use of the port down with it. internal: true is only fit for a lab that is entirely offline. For real use with a remote model provider, the isolation goes through a regular dedicated network and an outbound firewall, not through this setting.

The second is more surprising. Even on the dedicated network with no internal marking, the published port stayed unreachable, TCP connection accepted, empty HTTP response. Digging through the installed code gives the exact explanation:

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")

By default, the gateway only listens on the loopback inside the container, regardless of which Docker network it’s on. Hence the API_SERVER_HOST=0.0.0.0 line in the compose above: it changes nothing about external exposure, since it’s the 127.0.0.1: prefix on the published port that already restricts it. Verified after the fix: curl http://127.0.0.1:8642/health answers 200 from the host, the same request sent to the machine’s local network address (192.168.x.x) gets no response. As for the dashboard, it flatly refuses to start on a non-local interface with no authentication provider configured:

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.

A sound default behaviour, with a side effect visible in the logs. Left as-is, with no authentication configured, the service doesn’t just stay quietly disabled, it fails and then keeps restarting under s6 supervision. Nothing serious, but noisy enough to be worth knowing about. One last point verified: the deploy.resources.limits limit in the compose above does apply outside Swarm mode with Docker Compose v5.1.0. docker inspect confirms Memory=1073741824 and NanoCpus=1000000000 on the running container. Older Compose versions ignored deploy: outside Swarm.

What you see at startup

Once the configuration is fixed, docker compose up -d followed by polling /health every 0.3 seconds gives a startup time of around 18.9 seconds cold (empty data folder) and 16.6 seconds after a simple restart. The gap mostly comes down to an internal warm-up phase, which the logs explicitly name “turn-machinery warm-up” and which opens the front door after 20 seconds even though it keeps running in the background. Inside, ps aux confirms the supervisor stays root but that the hermes gateway run process does run under the unprivileged hermes user. The startup banner shows Hermes Agent v0.21.0 (2026.8.31), Python 3.13.5 and the OpenAI SDK 2.24.0.

Connecting to a model

The .env file generated on first start lists, entirely commented out, around thirty providers (Fireworks, OpenRouter, NovitaAI, Gemini, z.ai, Kimi, MiniMax, OpenCode Zen…) and as many tool keys (Firecrawl, Exa, Browserbase), none of them active. “Ollama” only appears there as OLLAMA_API_KEY, Ollama’s paid cloud service, and no entry targets a local instance. The built-in diagnostic confirms the install’s neutral state:

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)

The only value present in .env by the end of the test: an API_SERVER_KEY automatically generated by the container, to protect its own local gateway. It never appears in the clear in the logs, nobody entered it, and it has no relation to any account with a model provider.

Skills, and how to check one before installing it

Skills live in /opt/data/skills/ and follow the open Agent Skills standard detailed in our guide to SKILL.md. hermes skills list counted 53 built-in skills active in this lab, none installed from the hub. Installing goes through a registry: hermes skills install official/security/1password or hermes skills install openai/skills/k8s, for instance. Before installing anything, two commands save you from having to trust blindly:

hermes skills inspect openai/skills/k8s   # metadata, source repo, audit already available
hermes skills audit                       # rescans every skill installed from the hub

The built-in scanner sorts every result into three levels: dangerous blocks the install, warn/caution can be overridden with --force, advisory stays purely informative. According to the official documentation, the hub aggregated 90,700 skills spread across 11 registries as of 26 August 2026, not to be confused with “HermesHub,” the third-party community index mentioned earlier.

MCP: wiring up tools, or exposing Hermes as a server

hermes mcp catalog, run in the lab, shows an already long catalogue of ready-to-use servers (Airtable, Atlassian, Cloudflare, ClickUp, Buildkite…). hermes mcp list confirmed none were configured, as expected on a fresh install. Adding one works either through a known preset or a manual entry:

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

The other way round, hermes mcp serve exposes a Hermes session as an MCP server to an external client, Claude Code, for instance, by pointing its configuration at the hermes mcp serve command. On the security side, the documentation states three things. Remote OAuth tokens are cached with 0600 permissions. Renewal goes through PKCE. For stdio servers, only explicitly declared environment variables, plus a minimal base set, get passed to the subprocess. Enough to limit secret leaks to a poorly audited third-party MCP server, a risk already covered in our article on coding agents, sandboxes and permissions.

Hermes Agent versus OpenClaw: an honest comparison

Both projects are open source, install under Docker, and support skills and MCP, it’s their philosophy that diverges. OpenClaw structures a gateway that routes and supervises several agents, connectors and channels. Hermes Agent bets on a single agent that accumulates its own skills over time. Our article on OpenClaw’s hardened install covers the same exercise on the OpenClaw side, the two read as mirror images of each other.

On security, a Cloud Security Alliance research note dated 4 May 2026 counts, over the same period, nine CVEs for OpenClaw including one critical one rated 9.9, against two for Hermes Agent’s core. CVE-2026-7396 covers a path traversal in the WeCom adapter (CVSS 4.0), CVE-2026-7397 a symlink following in the file tools (CVSS 4.8), both on version 0.8.0 and fixed as of 0.9.0. A third listed CVE affects not the agent itself but hermes-webui, the third-party client already flagged above. The repo’s GitHub Security Advisories page, for its part, lists no advisory published as of 7 September 2026: these CVEs were filed through external channels, not by Nous Research itself. No census of exposed Hermes instances comparable to the verified figure for OpenClaw (42,900 instances, 93% with no authentication, SecurityScorecard 2026) has been published to date, which doesn’t prove they don’t exist.

One dated incident shows why network isolation and the absence of an automatic mode matter just as much as which project you pick. The Hacker News documented, on 24 July 2026, a case where an attacker who already had initial access to the Thai Ministry of Finance’s network installed Hermes Agent on a rented server, then switched on its “YOLO” mode, which skips confirmations before risky commands. The agent then explored the network unsupervised, found Hadoop services on default credentials, and deployed an implant. A point the source itself stresses: Hermes didn’t cause the intrusion, it automated the next phase of it. The dedicated network, the loopback ports and the absence of any entered key in this lab are meant to prevent exactly that phase.

What to remember

• The “Hermes Agent” compared to OpenClaw in 2026 is Nous Research’s (NousResearch/hermes-agent, MIT licence), not hermes-webui or “HermesHub,” two similarly named third-party projects.
• Latest dated version tested: v0.21.0 (tag v2026.8.31, 31 August 2026), installed via Docker in 1 min 47 s (908 MB compressed, 3.93 GB decompressed).
• A network marked internal: true also cuts the published port, not just outbound Internet access. By default, the gateway only listens on its own loopback (API_SERVER_HOST=127.0.0.1), which you have to fix explicitly even behind a port already restricted to 127.0.0.1 on the host side.
• The dashboard refuses to expose itself outside the loopback with no authentication configured. A sound default, but left that way it fails and loops instead of simply staying inactive.
• Startup measured at around 17 to 19 seconds until a genuinely positive /health, with no key or credential entered from start to finish.
• Over the same period, the Cloud Security Alliance counts two minor CVEs for Hermes Agent’s core against nine for OpenClaw, including one critical one. The gap should be read with caution: no equivalent exposure census has been published for Hermes.