Hermes Agent Guide
Hermes Agent Hosting: Judge the Options Against What It Needs
Most hosting advice starts from the options. This starts from the requirement, because the Hermes gateway has one property that decides the whole question: it is built on the assumption that something will restart it. Once you take that seriously, several popular answers fall away.
What the gateway needs
The long-running process is hermes gateway run. It holds platform connections, keeps state, and stays reachable. To do that continuously it needs four things:
- A machine that is awake and unlocked at the hours you expect answers.
- A supported Python interpreter — the installer provisions one rather than using the system copy.
- A supervisor that restarts the process when it exits.
- Reachable networking for the channels and providers you use.
Note what is absent: heavy CPU and RAM. Inference happens at your model provider, so the gateway is mostly waiting on network calls. Sizing is rarely the interesting question unless you are running models locally, which is a different problem entirely.
Why supervision is the deciding factor
Hermes runs an in-process liveness watchdog, on by default, that hard-exits when its event loop wedges so that a supervisor can restart it. That is a deliberate design: self-diagnosis plus a handoff. The full reasoning is in Hermes Agent in tmux.
The consequence for hosting is direct. Any environment that does not restart an exited process converts a recovery mechanism into a silent outage. That single test eliminates more hosting choices than performance ever will.
The one-question test: if the gateway exits right now, what brings it back? If the answer is "me, when I notice", you do not have a deployment.
The options, judged against that
| Option | Restarts on failure | Survives reboot | Honest verdict |
|---|---|---|---|
| Terminal session | No | No | Development only |
| tmux / screen | No | No | Survives disconnect, nothing else |
| Laptop with systemd | Yes | Not unattended if encrypted | Good for dev, not a deployment |
| VPS with systemd | Yes | Yes | The standard self-hosted answer |
| Container with restart policy | Yes | Yes | Good where you want isolation |
| Managed hosting | Yes | Yes | No server to operate |
The self-hosted path
A small VPS plus the official installer covers most cases, and the installer does the supervision work for you: where systemctl exists it offers to install a systemd service for the gateway. Accept that offer. The VPS guide covers the wider setup, and DigitalOcean is one worked example.
Prefer Docker when you want the Python environment isolated from the host — a reasonable instinct on a rolling-release distro, or on any machine you share with other services.
What self-hosting actually costs
Not the server bill, which is small. The ongoing work is the part people underestimate:
- Operating system and dependency updates.
- Noticing when the agent stops answering, which nothing tells you by default.
- Rotating credentials and keeping them off disk backups.
- Reconnecting channels after a provider-side change.
- Restoring state if the machine is lost.
None is hard. Together they are a standing commitment, and that is the honest comparison against managed hosting — not the monthly price.
How to decide
- Learning or building: your own machine, and do not confuse it with a deployment.
- You want control and enjoy operations: a VPS with the installer's systemd service.
- You need isolation or reproducibility: a container with a restart policy.
- You want the agent, not the server: managed hosting.
The same decision for the other framework is covered in OpenClaw hosting.
Hermes Agent hosting FAQ
What does Hermes Agent actually need from a host?
Less than people expect in resources, more than people expect in supervision. It is a Python process that stays online, so it needs a machine that is always awake and unlocked, a supported Python (the installer provisions one), and something that restarts it on failure. Raw CPU and memory are rarely the constraint.
Can I just run it on my laptop?
For development, yes. As a deployment, no — a laptop suspends when closed, changes networks, and on an encrypted disk will not come back unattended after a reboot. Each of those is an outage for an agent expected to answer at any hour.
Do I need to set up systemd myself?
Usually not. Where systemctl is available the official installer offers to install a systemd service for the gateway, and only falls back to a plain background process when systemd is absent. Accept it — declining leaves the gateway unsupervised for no benefit.
How much server do I need?
A small VPS is normally enough, because inference happens at your model provider rather than on your box. The exception is running models locally, which changes the requirement entirely — that is a GPU question, not a hosting one.