Self-host Hermes Agent on a VPS

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.

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.

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. 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.

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

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.

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.

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.

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.