Hermes Agent Hosting Guide

Direct answer

Run Hermes Agent on your own machine unless you need it available when that machine is off. Uptime is the deciding requirement: scheduled tasks, messaging gateways, and remote access all need a host that stays on, and that is what moves you to a server you manage or a service someone else manages. Nothing here ranks vendors.

Checked against Hermes Agent v0.20.5 on August 25, 2026. Re-check when documented resource guidance, container deployment behaviour, or update procedure changes in a release.

Choose where to run Hermes Agent

Answer in order and stop at the first rule that matches.

Rule 1
If you only use the agent while you are at your machine, interactively
Then run it locally on that machine
Because there is no uptime requirement to pay for, and local files are directly reachable
You accept nothing runs while the machine is asleep or off
Rule 2
If you want isolation from your host but still work interactively
Then run it locally in a container
Because the container boundary limits filesystem and process reach without adding a server
You accept updates mean replacing an image, and mounted paths must be deliberate
Rule 3
If scheduled tasks or a messaging gateway must respond while you are away
Then run it on a server you manage
Because unattended work needs a host that stays on, with its own network identity
You accept you own patching, backups, monitoring, exposure, and incident response
Rule 4
If you need continuous availability but cannot own server operations
Then evaluate a managed option against the criteria further down this page
Because the operating burden has to sit somewhere, and someone else can carry it
You accept less control, a recurring fee, and a provider you must verify yourself
Rule 5
If none of the above is clearly true
Then stay local
Because an always-on deployment adds cost and attack surface you have not yet justified
You accept you will migrate later, which is straightforward because state is one directory

Applied Hermes decision guidance, informed by Nous Research deployment and security documentation, checked 25 August 2026 against v0.20.5.

Local machine versus VPS versus managed hosting

Deployment environments compared on operating attributesUptime = whether the agent runs when you are not present. Operator control = how much of the stack you can change. Maintenance = who performs updates, backups, and monitoring. Exposure = what is reachable from outside by default.

Environment	Uptime	Operator control	Maintenance	Exposure
Local machine	Only while the machine is on	Full	You, occasionally	Nothing, unless you publish a port
Local container	Only while the machine is on	Full	You, plus image replacement	Nothing, unless you publish a port
Server you manage	Continuous	Full	You: patching, backups, monitoring, rotation	Whatever you publish, on a public network
Managed service	Continuous, per the provider's terms	Limited to what the provider exposes	Provider, to the extent their scope says so	Provider-defined; verify before trusting

Source: Nous Research Platform Support, Docker, and Security documentation, checked 25 August 2026. Applied Hermes has verified no managed Hermes Agent offer and names no vendor.

Hosting requirements by workload

Size from documented guidance, not from optimism. The container documentation gives 2–4 GB of memory (1 GB minimum), 2 CPU cores (1 minimum), and 2 GB or more of disk, with browser automation needing at least 2 GB on its own.

Sizing by workloadEach row states the minimum shape that makes the workload work, not a recommendation to buy more.

Workload	Memory	CPU	Disk	Also needs
Interactive chat and file work	1–2 GB	1–2 cores	2 GB+	Nothing beyond the runtime
Scheduled tasks	2 GB	2 cores	2 GB+ growing with sessions and logs	A host that stays on
Browser automation	4 GB	2 cores	2 GB+	Extra shared memory in a container
Messaging gateway	2 GB	2 cores	2 GB+	A user allowlist before it is reachable
Local model inference	Determined by the model, not by Hermes Agent	Determined by the model	Model weights	At least 64,000 tokens of context configured

Source: Nous Research Docker guide and Quickstart, checked 25 August 2026. Local inference sizing depends entirely on the model you choose.

Reference deployment architecture

A hosted deployment has five parts and three boundaries worth naming explicitly.

Parts

The runtime — the Hermes Agent process, from a host install or a container.
The state directory — one directory holding configuration, credentials, sessions, memories, skills, cron jobs, and logs. Mounted at /opt/data in the container.
The model provider — remote, or a local inference server on the same network.
Optional inbound surfaces — the messaging gateway, the OpenAI-compatible API server on port 8642, and the browser dashboard on port 9119.
Operator access — how you reach the box, which should not be the same path as any published service.

Boundaries

Host boundary. Whatever the terminal backend can reach. A container backend narrows this; local does not.
Network boundary. Everything you publish. The default is nothing.
Data boundary. Prompt content and tool output leaving for a model provider.

Keep operator access on SSH, keep services on loopback, and tunnel rather than publish wherever you can.

Use Docker or host installation

Both work on a server; the difference is lifecycle.

Host install supports hermes update in place, which makes routine upgrades a single command.
Container install is reproducible and disposable, keeps state on a mounted volume, and updates by pulling a new image and recreating the container — hermes update is explicitly not supported there.

Choose the container path if you value reproducibility and isolation; choose the host install if in-place updates matter more. Full container setup — image, volume, secrets, ports, verification, and rollback — is owned by the Docker deployment path.

Follow the Docker deployment path

Secure network, dashboard, and credentials

The minimum for anything that stays on:

Publish no port you do not need. Prefer an SSH tunnel to a loopback bind.
API server key set. It is documented as required for every deployment, including loopback, because that endpoint exposes the full toolset including terminal commands.
Dashboard behind an authentication provider on any non-loopback bind.
Gateway allowlists explicit. With none configured, all users are denied — do not replace that with an allow-all flag.
Do not run the gateway as root, and keep ~/.hermes/.env at 0600.
Consider a container terminal backend so agent execution is not the same boundary as the host.

The threat model behind each control, and how to verify it is in force, is the hosting security baseline.

Apply the hosting security baseline

Backups, persistence, updates, and monitoring

Persistence. One directory holds everything. On a container deployment it is the mounted volume; back that up and you have the deployment.
Backups. hermes backup produces an archive including credentials — store it as you would a password vault export. Test a restore at least once.
Updates. Host installs take a pre-update state snapshot by default and support rollback to a previous commit or tag. Container installs roll back by recreating from an earlier image.
Monitoring. Watch the log directory, the gateway status, and disk usage — sessions and logs grow.
One gateway per data directory. Two gateway processes against the same state is a documented way to corrupt it.

Evaluate a provider without vendor hype

Applied Hermes publishes no provider ranking, no shortlist, and no affiliate links, so evaluate against requirements you can check yourself:

Specification against the sizing above, at the price they actually charge on renewal, not on promotion.
Region and data residency, if that constrains you.
What you are responsible for versus what they operate. Get it in writing.
Backup and restore mechanics, including whether you can export state without their tooling.
Exit path. Can you take the state directory and run it elsewhere? If not, that is the real cost.
Incident and status history, not marketing uptime figures.

Any provider that cannot answer the responsibility question plainly has answered it.

Deployment sequence

1. Size the host

Use the workload table above.

2. Install by your chosen method

Host install for in-place updates, container for reproducibility.

3. Configure before exposing

Provider, approval mode, terminal backend, toolsets — all with nothing published.

4. Verify locally on the host

Run a bounded task over SSH before anything is reachable from outside.

5. Add exactly one inbound surface

Gateway, API server, or dashboard — one at a time, each with authentication.

6. Turn on backups and monitoring

Then test a restore before you depend on it.

When hosting is unnecessary

Do not host if all of these are true: you use the agent interactively, you have no scheduled work, no chat platform needs to reach it, and your files live on the machine you are sitting at. In that case a server adds a monthly bill, an attack surface, and a maintenance duty in exchange for nothing you use.

If cost is the deciding factor rather than capability, work the components first — the total operating cost page separates what hosting actually adds from what model usage was going to cost you anyway.