Hermes Agent in Docker vs a VM: What You Still Have to Operate

Running Hermes Agent in Docker is a good self-hosting choice if you already operate Linux and want control of the machine. Docker packages Hermes, keeps its data separate from the image, and gives you a repeatable update path.

It does not operate the host for you.

You still own the kernel, Docker daemon, network exposure, disk, monitoring, backups, and proof that Hermes returns after a reboot or failed update. A managed VM moves some of that work to a provider, but it does not make the agent's tools, credentials, or external actions safe by default.

Choose the deployment by the responsibilities you want to keep, not by which install command is shorter.

Docker solves packaging. The machine around the container still needs an operator.

"Docker" means two different things in Hermes

Hermes supports two Docker architectures. They solve different problems.

First, you can run Hermes itself inside the official Docker image. The gateway, skills, sessions, memory, configuration, and tools all run from that containerised installation.

Second, you can run Hermes on the host and configure Docker only as its terminal backend. In that design, the agent process stays on the host while terminal and code tool calls execute inside a persistent Docker container.

The first choice packages Hermes. The second choice constrains where command execution happens. You can use either one without the other, or run Hermes in Docker and still decide how its tool execution should be bounded.

That distinction matters because "I put the agent in Docker" does not tell you:

• where Hermes itself runs;
• where terminal commands run;
• which filesystem paths are mounted;
• which process controls the Docker daemon;
• whether the host is shared with other workloads;
• who patches and recovers the machine.

Running Hermes in Docker and using Docker for terminal execution are separate decisions. A VM adds a guest-kernel boundary around the machine.

What the official Hermes Docker setup gives you

The official image has a sensible split between application code and mutable state.

/opt/hermes is the installed application tree. In the published image it is root-owned and read-only to the runtime hermes user. Configuration, API keys, sessions, memories, skills, profiles, logs, plugins, and other user-managed files belong under /opt/data.

You persist that state by mounting a host directory:

```yaml
services:
hermes:
image: nousresearch/hermes-agent:latest
restart: unless-stopped
command: gateway run
volumes:

• • ~/.hermes:/opt/data
    ```

This is the important part of the official Compose pattern, not a complete deployment file. Use the current Hermes Docker guide for the full configuration and current dashboard, API, authentication, and networking requirements.

The image also supervises the gateway and optional dashboard with s6-overlay. If a supervised gateway process crashes, s6 restarts it. The restart: unless-stopped policy covers the outer container when the Docker daemon or host restarts.

Those are useful controls. They are also narrow controls.

A restart policy cannot help when the disk fills, the host is unreachable, Docker fails to start, an exposed service is misconfigured, or your only backup lives on the machine you just lost.

Persistence is not a backup

A bind mount keeps /opt/data when you recreate the container. That protects you from one common mistake: deleting the container and discovering that all useful state lived inside its writable layer.

It does not create a second copy of the data.

If the host disk fails, the mounted directory can fail with it. If an update writes a bad migration into persisted state, recreating the old container may not be enough. If a credential or file was deleted before your backup ran, the bind mount preserves the deletion perfectly.

Treat the data mount as the live source of truth. Give it a separate backup and a tested restore path.

Resource limits still need a workload decision

The official Docker guide lists 1 GB of memory, one CPU core, and 500 MB of data-volume disk as minimums. It recommends 2 to 4 GB of memory, two CPU cores, and at least 2 GB of data-volume space. Browser automation needs more memory than a text-only gateway.

These are upstream deployment guidelines, not a guarantee for every toolset. A Hermes profile that drives Chromium, installs packages, keeps long sessions, and runs scheduled work will not behave like a minimal chat gateway.

Set limits, then watch actual memory, disk, and restart behaviour. Do not size a persistent agent once and forget it.

What you still operate after Docker starts

A successful docker compose up -d proves that the container started. It does not prove that you have an operable service.

For a Hermes deployment that should stay online, you still need answers to these questions:

1. Who patches the host OS and kernel?
2. Who upgrades Docker and verifies the daemon returns?
3. Which ports are public, and how are TLS and authentication handled?
4. Where is /opt/data, how quickly is it growing, and what happens when the disk is full?
5. How do you know the gateway stopped responding?
6. What starts after a full machine reboot?
7. How do you roll back a Hermes image or configuration change?
8. Where are backups stored, how long are they retained, and when was one last restored?
9. Which credentials can the agent reach?
10. Which external actions require approval or idempotency protection?

The official Hermes documentation warns against opening ports on an internet-facing machine unless you understand the risk. Current dashboard builds also require an authentication provider for a non-loopback bind and fail closed when one is missing.

Do not turn a private service into a public one because a Compose example contains a ports block. Expose only the surface you need. Put the rest behind an SSH tunnel, VPN, authenticated reverse proxy, or private network appropriate to your setup.

For an unattended gateway, also review Hermes's tool-loop guardrails. The official documentation says tool_loop_guardrails.hard_stop_enabled defaults to false. An interactive warning is different from a circuit breaker when nobody is watching.

Container boundary versus VM boundary

A conventional Docker container uses Linux namespaces, cgroups, capability controls, and other kernel features to isolate processes and resources. Docker's own Engine security documentation describes both the protections and the daemon attack surface.

The host kernel is still the shared kernel beneath conventional containers on that machine.

A virtual machine has its own guest kernel and a virtual machine boundary between the guest and the host. When each agent gets its own VM, agent workloads do not share a guest kernel with one another.

That is a stronger tenancy boundary for the machine. It is not a complete agent safety model.

A VM cannot decide whether Hermes should have access to your email account. It cannot tell whether a GitHub token is too broad. It cannot unsend a message, reverse a payment, or remove a write that already reached an external database.

You still need scoped credentials, restricted tools, network controls, approval for high-impact actions, and idempotency or reconciliation where retries can create duplicate effects.

The responsibility matrix

The useful question is not "Does it use Docker?" It is "Who wakes up when the surrounding machine stops working?"

"Managed" should name the work that moved. If a provider cannot state the boundary, assume you still own it.

The managed column describes Mantlecore's current Hermes responsibility split, not every hosting provider. Check another provider's documentation before assuming the same boundary.

Mantlecore currently provisions one VM per agent, operates the host, issues HTTPS, keeps VM storage persistent, takes one off-site backup per day, and snapshots the VM before an approved version change. You still choose the model, connect channels, control credentials and permissions, and decide when to restore or update.

What each recovery control can and cannot do

Recovery gets muddled because volumes, snapshots, and backups are often discussed as if they were interchangeable.

Snapshots and backups also have consistency limits. A machine snapshot can capture every byte and still catch a writable service mid-transaction. Mantlecore documents its current snapshots as crash-consistent, not universally application-consistent. The broader backup and restore guide explains the distinction and gives a restore test checklist.

The practical rule is simple: a successful backup job is not proof of recovery. Restore it somewhere safe and verify that Hermes starts, the expected workspace exists, required services respond, and one familiar tool task completes.

Choose Docker when you want control

Run Hermes in Docker on a machine you operate when:

• Linux, networking, and container operations are already routine for you;
• you want root access and complete control over images, sidecars, storage, and network policy;
• you need packages or services that a managed platform does not expose;
• you already have monitoring, off-machine backups, and restore testing;
• operating the host is part of the project, not an unwanted second project.

Docker is also a good local evaluation path. You can learn how Hermes stores state, connect a model, test a channel, and decide which tools it should have before committing to a permanent server.

If you move that container to a VPS, write down the recurring work before calling the move complete. Patching, firewall rules, TLS, disk alerts, backup retention, and reboot testing are now production tasks even if only one person uses the agent.

Choose a managed isolated VM when you want the agent, not the host

A managed VM is the better fit when:

• Hermes needs to stay online without depending on your laptop;
• you want a separate guest-kernel boundary for the agent;
• you do not want to patch the host or operate Docker around the runtime;
• you want named backup, snapshot, update, and recovery responsibilities;
• you accept a recurring fee and less low-level control in exchange for moving that work.

Do not buy the word "managed." Buy a documented responsibility split.

Ask whether the provider manages only initial installation or also host patching, TLS, persistent storage, monitoring, backups, restore execution, and updates. Ask what is captured, where backups live, how long they are retained, and what a restore does not reverse.

A self-hosting acceptance test

Before you trust a self-hosted Hermes Agent Docker deployment, verify the whole operating path:

1. Reboot the machine and confirm Docker and Hermes return without manual intervention.
2. Open an existing session or workspace file after the reboot.
3. Confirm the mounted /opt/data directory is the one you intend to protect.
4. Check that secrets and data directories have appropriate ownership and permissions.
5. Verify only the intended ports are reachable from outside the machine.
6. Trigger a gateway failure and confirm supervision restarts it.
7. Fill a test filesystem or enforce a low disk threshold and confirm an alert reaches you.
8. Back up the data or machine to independent storage.
9. Restore that backup and complete a small tool-using Hermes task.
10. Review model keys, channel tokens, tool permissions, and high-impact external actions separately from the machine controls.

If you can pass that list and want root control, self-hosting is a sound choice.

If the list describes work you do not want, compare Mantlecore's managed Hermes Agent deployment against the responsibility matrix above. Plans currently start at $19 per month with one isolated VM per agent, persistent storage, HTTPS, daily off-site backups, and a customer-controlled update path.

Either way, make the boundary explicit before the agent becomes useful enough that rebuilding it hurts.

Frequently asked questions

Can Hermes Agent run in Docker?

Yes. Nous Research publishes an official Docker image and Compose guidance. Mutable Hermes state lives under /opt/data, which you mount from the host so it survives container recreation.

Is running Hermes in Docker the same as using Docker as its terminal backend?

No. Running Hermes in Docker puts the agent runtime inside the container. The Docker terminal backend can instead keep Hermes on the host while executing terminal and code tool calls inside a persistent Docker container.

Does a Docker volume back up Hermes Agent?

No. A mounted volume persists data outside the container's writable layer. You still need an independent backup and a tested restore process for host or disk loss.

Is a VM safer than Docker for an AI agent?

A VM gives the workload its own guest kernel rather than sharing the host kernel with conventional containers. That changes the machine isolation boundary. It does not control model prompts, tool permissions, credentials, network access, or irreversible external actions.

Should I run Hermes on my laptop, a VPS, or managed hosting?

Use your laptop for evaluation or work that can stop when the laptop stops. Use a self-managed VPS when you want an always-on machine and are willing to operate it. Use managed hosting when you want the provider to own a documented part of the host, persistence, backup, update, and recovery path.

How much memory does Hermes need in Docker?

The current official guide lists 1 GB as the minimum and recommends 2 to 4 GB. Browser automation needs more memory, and sessions, skills, logs, and installed tools also increase storage needs over time.