A working hermes command is not a hosted agent. To run Hermes Agent around the clock you install it with the official installer or Docker image, move the gateway onto a machine that stays online, supervise the process, persist its state, control remote access, and test recovery. Managed hosting exists if you want those infrastructure duties moved to a provider.
This guide walks that full path. Commands and defaults below were rechecked against the official Hermes documentation on 2 August 2026. Hermes moves fast, so treat the official docs as canonical if anything here drifts.
Here is the finish line before you start. Hermes is continuously hosted when the machine stays available, the gateway comes back after a crash or reboot, its state survives restarts, remote access is controlled, and you can detect and recover from failure. Notice what is not on that list: running the installer once.
Installation gets Hermes ready. Everything after it is operations.
The eight steps between install and always on
Most install guides stop at the first box. The operating model is the whole chain:
Each step depends on the ones before it. A backup you have never restored is a hope, not a recovery path.
Keep this sequence in mind. Every section below maps to one or two of these steps, and the acceptance checklist near the end turns them into a test you can actually run.
Choose one of four deployment paths
You have four realistic places to run a persistent Hermes gateway. None is universally best.
Path | Best for | You operate | Main limitation |
|---|---|---|---|
Local desktop or laptop | Learning and interactive use | Device uptime and app lifecycle | Sleep, shutdown and network changes interrupt availability |
Native install on a VPS | Full root control | OS, process manager, network, updates, backups | Highest recurring operator burden |
Official Docker image on a VPS | Reproducible packaging and a supervised container | Host, Docker daemon, volumes, ports, backups | Container restart is not host recovery |
Managed isolated VM | Persistent deployment without host operations | Models, channels, credentials, permissions, external actions | Recurring fee and less low-level control |
Responsibility moves as you go from local to managed. Models, channels and permissions remain yours on every path.
The rest of this guide works for any of the four. Where a step only applies to self-managed paths, I say so.
Step one: install Hermes the official way
Install intent is real, so here is the short version. Do not copy old blog commands; use the current official path.
On Linux, macOS, WSL2 or Android Termux, the command-line installer is:
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
On native Windows, the installer runs in PowerShell. On macOS and Windows you can also use the Hermes Desktop app. Git is the main prerequisite; the installer handles Python, Node and the rest, and it can set up browser automation unless you pass --skip-browser.
After installation, run hermes setup to configure your model provider and channels, then hermes doctor. Doctor tells you exactly what is missing and how to fix it. When it runs clean, your install is verified.
That is where most tutorials end. It is also where hosting begins.
Step two: decide where the gateway lives
The gateway is the always-on process that connects Hermes to your messaging platforms and API. It can only be as available as the machine under it.
A laptop is a valid place to learn. It is not a host. Sleep closes your sessions, shutdown kills the gateway, and a network change can drop the machine off the internet without telling you.
A home server can work if you deliberately manage power, internet, remote access and backups. Most people underestimate the "deliberately" part. A residential connection changes address, a power cut does not send a warning, and the disk in a five-year-old mini PC has its own plans.
A VPS or cloud VM gives you an always-on machine with a public address. In exchange you now own the provider account, the OS, SSH, the firewall, storage and billing. That trade is the subject of the rest of this guide.
A managed VM moves the named infrastructure tasks to a provider. What exactly moves, and what stays with you, gets its own section near the end.
Step three: keep the gateway supervised
A process you started by hand stays up until the first time it doesn't. Supervision means something restarts the gateway when it crashes and after the machine reboots.
Before supervision comes connection. Run hermes gateway setup to link your messaging platforms, and confirm the gateway actually answers a message end to end. A supervised process that was never wired to a channel is uptime without a purpose.
On a native install, you own the supervision itself. The official docs cover the gateway lifecycle, and a common pattern is a systemd service that starts hermes gateway run on boot and restarts it on failure. Treat that as a tested example rather than an official requirement, and verify two things yourself: the gateway returns after you kill the process, and it returns after a full machine reboot. Test the reboot. A service that only survives a process kill has not proven the boot path.
The official Docker image gives you more of this out of the box. The documented pattern runs the container detached with a restart policy:
docker run -d --name hermes --restart unless-stopped -v ~/.hermes:/opt/data nousresearch/hermes-agent gateway run
Inside the image, s6-overlay supervises the gateway and restarts it within a couple of seconds if the process crashes, without losing the container.
Understand the boundary. s6-overlay recovers a crashed process inside a live container. Docker's restart policy recovers a stopped container while the daemon is healthy. Neither one boots a dead host, repairs a corrupted disk, or pays an expired provider invoice.
Step four: persist the state that matters
Hermes keeps its mutable state in one directory, HERMES_HOME. That directory holds your configuration and credentials, sessions and memories, skills and profiles, logs, cron definitions, and the files your agent creates in its workspace. Lose it and you have a fresh install with your agent's name on it.
The Docker image mounts this state at /opt/data, which is why the -v ~/.hermes:/opt/data volume flag matters. With the mount, state survives container replacement. Without it, every docker run starts over.
Now the part people get wrong: a mounted volume is not a backup. A volume protects you from container replacement. It does nothing about accidental deletion, filesystem corruption, ransomware inside the machine, or a provider losing the disk. Those need copies that live off the machine, plus a restore you have actually tested. The backup and restore guide covers that boundary in detail.
Step five: expose access safely
Before you open any port, decide whether you need to. If you talk to Hermes through Telegram, Discord or another messaging channel, the gateway makes outbound connections and you may not need any public ingress at all.
When you do need remote access, know the defaults. The Hermes API server binds to 127.0.0.1 by default and requires an API key as a bearer token. It exposes /health as a cheap liveness probe and /health/detailed as an authenticated readiness check for monitoring. The optional dashboard has its own port and basic-auth or OAuth options, and the official docs say it is not suitable for direct public-internet exposure.
The docs are blunt about this for a reason: opening a port on an internet-facing machine is a security risk. Hermes can run terminal commands, so its API boundary is high impact. Prefer loopback plus an SSH tunnel or VPN. A tunnel gives you the dashboard and API on your own machine with no public listener at all, which removes the entire class of "did I configure the proxy auth correctly" questions. If you must use a reverse proxy, put authentication in front of it and keep CORS narrow. Never bind an unauthenticated gateway API to a public interface.
Step six: size the machine for the tools you enable
The official Docker guidance gives you a floor, not a promise: minimum 1 CPU core, 1 GB RAM and a 500 MB data volume; recommended 2 cores, 2 to 4 GB RAM and 2+ GB of volume that grows with sessions and skills. If you skip browser tools, 1 GB is workable. With browser automation active, allocate at least 2 GB.
Treat these as upstream image guidelines. Your real footprint depends on how many sessions run in parallel, what the agent stores, whether you use browser tools, and whether you run local inference. Watch actual usage for a week before you commit to a plan size anywhere.
One clarification to avoid confusion: those are upstream minimums for running Hermes yourself. Managed providers set their own floors. Mantlecore's current Hermes plans, for example, start at 2 vCPU and 4 GB RAM. Different layers, different numbers.
Step seven: run the acceptance checklist
This is the test that separates "installed" from "hosted." Run every item. Do not call the deployment persistent until all eleven pass.
hermes doctorruns clean.- The gateway starts on boot or under a supervisor.
- Your configured messaging channel or API completes one real request.
- Restarting the Hermes process preserves state.
- Rebooting the machine restores gateway availability.
- Credentials are scoped and absent from logs and public config.
- A health or readiness check is monitored.
- Disk usage and resource pressure have alerts or a review routine.
- Your update method and rollback path are written down.
- A backup exists off the machine and you have restored from it once.
- External actions are governed separately, because no restore can unsend a message or undo a payment.
Item 11 deserves a second read. Snapshots and backups recover machine state. They cannot reverse things your agent already did in the world. Keep permissions tight independent of your recovery story.
What a self-managed VPS really costs
The server invoice is the small part. The recurring work is the real price:
- provider billing and capacity review
- OS and package updates
- SSH and firewall policy
- Docker or process-manager maintenance
- TLS and reverse proxy upkeep where required
- monitoring and alert response
- backup storage and restore tests
- Hermes upgrades and compatibility checks
None of these is hard. All of them are forever. The failure that matters will not arrive during your Saturday maintenance window. It arrives when you are busy with something else, and the cost is the interruption plus the diagnosis plus the fix.
The honest comparison is not $6 VPS versus managed fee. It is whether you want this list to be your job.
What managed hosting removes, and what it does not
Here is the current split from the live Mantlecore Hermes page, rechecked on 2 August 2026. It is the only source for product claims in this article.
Area | Mantlecore handles | You control |
|---|---|---|
Deployment | Provisioning the VM and the Hermes environment on it | Which agent and which plan you deploy |
Isolation | One virtual machine per agent, each with its own guest kernel | What the agent is allowed to reach |
HTTPS | Certificates and TLS for the agent endpoint | Which channels and integrations you connect |
Storage | Persistent VM storage across stop, start and restart | The files and agent data created in the workspace |
Backups | One off-site backup per day, retained 7 days on Starter and 30 days on larger plans | When to restore, and any recovery needed outside the VM |
Snapshots | Automatic snapshot before any version change | Your own manual snapshots, 1 on Starter and 3 or 5 on larger plans |
Updates | Verified versions, pre-update snapshot, automatic rollback if the post-update health check fails | When to apply an update |
Three boundaries matter more than the list. Mantlecore operates the host; you still choose the model, the channels, the credentials and the permissions. A backup captures the machine, not the consequences of actions the agent already took. And managed hosting is a responsibility transfer, not a guarantee of uninterrupted service. Plans start at $19 per month with a seven-day trial.
So which path is yours?
Answer three questions:
- Do you want root control enough to own the host lifecycle?
- Do you need the agent reachable when your personal device is off?
- Have you built and tested supervision, safe access, monitoring, backup and restore?
Stay local while you are learning. Take a self-managed VPS when server operations are acceptable and control genuinely matters to you. Choose managed hosting when you want the agent online without the surrounding host lifecycle becoming your second job.
If you are still weighing frameworks rather than hosts, read the Hermes Agent vs OpenClaw comparison first. If you are deciding between containers and VMs at the architecture level, the Docker vs VM breakdown goes deeper on isolation boundaries.
Self-hosting Hermes is a legitimate choice, and this guide gives you everything you need to do it properly. If you read the checklist and the recurring-work list and decided you would rather spend that time on what your agent does, compare Mantlecore's managed Hermes hosting against the checklist above. One VM per agent, snapshots before every update, daily off-site backups. The host is our job. The agent is yours.