Is local execution ever acceptable?
Yes, for narrow, trusted experiments in non-sensitive directories. It is not the right default for unattended or production-like workflows.
Execution boundary decision
Use local execution only for trusted, narrow experiments. Use Docker or another sandboxed backend when Hermes will run commands, touch private repositories, handle messaging, or operate unattended.
Agent Guide is an independent editorial resource. It is not affiliated with, endorsed by, or sponsored by Nous Research, Hermes Agent, or Hermes/Hermes brand owners. Product names and marks belong to their respective owners.
The local-vs-Docker decision is the core Hermes Agent safety decision. Local execution is convenient because commands run as your user. That also means local files and credentials can be reachable if your workflow is too broad.
Docker improves the boundary by putting command execution in a container or running Hermes itself in a container. The boundary still depends on mounted directories, forwarded environment variables, ports, gateway allowlists, and whether the workflow can run unattended.
| Path | Best for | Avoid when | Main risk |
|---|---|---|---|
| Local host | Learning, trusted one-off tasks, narrow test folders | The agent can touch private repos, broad files, or production keys | Commands run with your user permissions. |
| Docker terminal backend | Command execution with a clearer sandbox boundary | You forward broad env vars or mount sensitive folders | Container can still see forwarded secrets and mounted files. |
| Hermes in Docker | Repeatable service, gateway, VPS, isolated data directory | You expose ports broadly or skip backups | Persistent /opt/data contains sensitive agent state. |
| SSH/remote host | Separate machine boundary | Remote host has broad production access | Keys and remote filesystem scope become the risk. |
| Failure | Why it happens | Fix |
|---|---|---|
| Agent reads too many files | Started in a broad local directory | Use a narrow workspace or Docker mount. |
| Secret available in container | Env var forwarded manually or by skill | Remove forwarding, rotate the key if exposed, and narrow skill requirements. |
| Gateway accepts unknown users | Allow-all setting or missing allowlist | Configure platform/user allowlists before external use. |
| Rollback is unclear | Persistent data directory not backed up | Back up Hermes data before upgrades, migrations, and new skills. |
| Approvals skipped unexpectedly | YOLO or container boundary behavior misunderstood | Review approval mode and backend-specific security behavior. |
Use local execution only for trusted, narrow experiments. Use Docker or another sandboxed backend when Hermes will run commands, touch private repositories, handle messaging, or operate unattended.
This page is part of Agent Guide's independent Hermes Agent cluster. It is source-backed and labelled when first-hand execution has not been run.
| Source | Used for | Last checked | Confidence |
|---|---|---|---|
| Hermes Agent security guide | Approval modes, gateway authorization, Docker terminal backend hardening, and credential cautions. | 2026-06-02 | high |
| Hermes Agent Docker guide | Docker run modes, mounted data directory, gateway operation, ports, and production cautions. | 2026-06-02 | high |
| Hermes Agent configuration guide | Provider, model, backend, and environment configuration patterns. | 2026-06-02 | high |
Known caveats: Security behavior can change. Verify current official security and Docker docs before relying on this page for production governance.
Yes, for narrow, trusted experiments in non-sensitive directories. It is not the right default for unattended or production-like workflows.
No. Docker changes the execution boundary, but operators still need review, mounts, env forwarding, gateway allowlists, and rollback discipline.
Operator checklist
Receive the smoke-test order for install path, sandbox boundary, provider setup, source review, and production checks.