Hermes Agent hosting: a $5 VPS is enough

What Hermes Agent is

Hermes Agent is a self-hosted AI agent from Nous Research, released in February 2026. You run it on your own server, and it keeps a persistent memory of your projects, writes its own reusable skills as it works, and reaches you through chat apps like Telegram and Discord. It is model-agnostic, so you point it at whatever language model you prefer, and it is light enough to run on a $5 VPS, in Docker, or over SSH. That split, where the model runs elsewhere and the loop, the tools, and the memory run on your box, is what makes Hermes an agent harness rather than a model, and it is the reason a small server is enough.

Like any agent, its value comes from acting on your behalf, and that is also why you set it up with care. An agent that remembers, learns, and runs tasks is a standing process with real reach into your server. This guide installs it the safe way, and the hardening here is the same you would apply to running OpenClaw safely.

The one-command install, and why to read it first

Hermes installs with a single command:

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

That is convenient, and it is also a pattern worth respecting. Piping a script straight from the internet into a shell runs whatever that script contains, as the user who runs it. Before you run it on a real server, download it first, read it, and run it as a dedicated user rather than root:

curl -fsSL https://hermes-agent.nousresearch.com/install.sh -o hermes-install.sh
less hermes-install.sh

This is not about distrusting Hermes in particular. It is the habit that keeps any curl | bash install from quietly becoming the weakest link in your setup.

Give it an unprivileged user

Run Hermes as its own system account, never as root, so a bug or a bad instruction cannot reach the rest of the machine. Create a user with no login shell:

sudo useradd --system --home /opt/hermes --shell /usr/sbin/nologin hermes

Install Hermes under /opt/hermes and make that account the owner. The official installer installs for whichever user runs it, so run the script you downloaded as the hermes user, for example sudo -u hermes bash hermes-install.sh, and the files land in its home directory instead of yours. The reasoning is the same as in running services as an unprivileged user: the account the agent runs as is the ceiling on what it can damage. The OS account is only half the picture, because the agent's own settings decide how much it does without asking first, which is the question behind Claude Code's permission modes when the agent is running on a box you are not sitting in front of. If the box eventually has to serve more than just you, OneCLI carries that one-account-per-agent idea up to a whole team by giving every person their own sandboxed agent while the model keys stay in a single gateway nobody has to copy around.

Firewall the box and isolate its secrets

Hermes does its work by reaching out to a model and to the chat apps you connect, so it does not need to accept inbound connections from the internet. Put a default-deny firewall in front of the server:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

Watch the IPv6 firewall gap here, because a rule set that only covers IPv4 can leave a service exposed on IPv6. If the agent does need to reach something that only exists on your home network, such as a NAS or a local database, advertising that network to your tailnet with a subnet router gets it there over an outbound connection instead of an open inbound port. Keep the model API key and any chat tokens in a file that only the hermes user can read (mode 600), and load it into the service rather than pasting it on a command line where it lands in your shell history. A secrets file like that is the same small, high-value target as the admin token behind a self-hosted password manager, and the reasoning in the Vaultwarden hardening pass carries over: guard the one file that unlocks everything else, and guard its backups just as closely.

Run Hermes as a hardened systemd service

A systemd unit keeps Hermes running after you log out and after a reboot, restarts it if it crashes, and lets you add kernel-level sandboxing that limits what it can touch. Turn on NoNewPrivileges, ProtectSystem=strict, PrivateTmp, and ProtectHome so a compromise stays contained.

Generate a hardened unit here, then copy it to /etc/systemd/system/hermes.service. The unit starts hermes gateway, the long-running process that connects your chat apps; run hermes --help after installing to confirm that command and the binary's path on your version before you enable the service:

The directives, and the daemon-reload and enable --now steps, are covered in running a program as a systemd service:

sudo systemctl daemon-reload
sudo systemctl enable --now hermes

For a worked example of the same pattern on another agent, running dsh headless under systemd spends longer on the Restart rules and the journalctl commands you will want the first time the service dies overnight. Better still, do not wait until morning to find out: an OnFailure= unit that pushes the alert to your own ntfy server puts a notification on your phone the moment Hermes gives up restarting.

If you would rather have systemd supervise a container than a native install, keeping KiroCrew alive as a pinned container reaches the same survives-a-reboot result while holding the image version still.

Harden the server around it

Finish by hardening the front door. Move SSH to key-only authentication and disable root login, as in SSH hardening on a VPS, so the account you use to manage the box cannot be guessed. An agent that keeps a persistent memory is worth protecting, and the cheapest protection is making sure no one can log in to the server it lives on.

Once the server itself is locked down, the capability most people add next is web search, and pointing the agent at your own SearXNG instance keeps those queries on your own box, at the cost of feeding it pages nobody has vetted. Hermes is also rarely the only agent on the box, and if you keep Claude Code running there as well, two sessions can hand work to each other directly instead of routing every handoff through you. If the next agent you add is one that reads your code rather than your chat apps, running open-kritt's security scans on the same box fits the same shape: a pinned release, its own account, and a web UI you reach through an SSH tunnel instead of an open port.

If you would rather understand the machinery than run a packaged agent, building your own AI agent on a VPS lays it out step by step. If the vocabulary in that guide is still new, a staged path for learning AI agents takes the loop, tools, memory, and safety in the order they build on each other, so the choices Hermes makes for you stop looking like magic.

FAQ

Can I run Hermes Agent on a cheap VPS?

Yes. Hermes is designed to run on a small server, and a $5 VPS is enough for a personal, always-on agent. It reaches out to a language model and to your chat apps rather than serving heavy traffic, so it is light on resources. Give it its own user, a firewall, and a systemd service, and a small VPS handles it comfortably. If you already have a machine at home, weigh its hardware and power costs against that monthly fee first, because a home Proxmox box and a rented VPS win on different fronts.

Is the one-line install script safe to run?

The curl | bash install is convenient, but the safe habit is to download the script and read it before running it, and to run it as a dedicated user instead of root. That way a piped installer, from any project, can never do more than that limited account allows. Nothing here is specific to Hermes; it is good practice for every install of this shape.

How do I run Hermes without root?

Create a dedicated system user with no login shell, install Hermes under a directory that user owns such as /opt/hermes, and run the service as that account. If the agent is ever compromised, the damage is limited to what that one account can reach.

How do I keep Hermes running after I log out?

Run it as a systemd service. A unit file starts Hermes on boot, restarts it if it crashes, and keeps it running after your SSH session ends, while systemd's sandboxing options limit what the process can touch. Generate a hardened unit with the tool above and enable it with systemctl enable --now hermes.

Does Hermes Agent need a GPU?

No. Hermes is the agent runtime, not the language model, so it runs fine on a small CPU-only VPS. The heavy computation happens wherever the model runs, which is usually a hosted API you connect it to. If you also want to self-host the model on the same box, size the machine for the model rather than for Hermes itself. For CPU-only model hosting, the numbers in the Ollama guide apply.