Deploy Hermes Agent on a VPS

Hermes Agent is Nous Research's MIT-licensed, self-improving AI agent: it keeps memory across sessions, builds its own skills, and runs scheduled automations. Run it on a server of your own and what it learns about your work stays on a disk you control, keeps working while you sleep, and cannot be changed by somebody else's terms of service. Nous Research maintains the installer and its documentation, so this guide covers the half that is ours: the server underneath, keeping it alive and private, and protecting what it learns. The product page is Self-Hosted Hermes Agent Hosting.

Prepare the server first#

An agent that browses, runs terminal commands, and manages files deserves a machine with nothing else on it. Ten minutes of work before it exists:

1. Harden the fresh install. Work through First Steps on a New Linux Server: updates, a sudo user, SSH keys, password logins off.
2. Close what you are not using. Set the firewall to default deny inbound, SSH only, then open a port only where the vendor documentation says a channel you paired needs one.
3. Keep it dedicated. No site, no database, nothing else you would mind it touching. The separate server is the isolation boundary, and the cheapest control you have.

Run the official installer#

Installation is one command from Nous Research, and it changes when they change it. Read the official documentation at hermes-agent.nousresearch.com/docs, run its installer on a fresh Linux server, and follow the onboarding: model provider credentials (Nous Portal, OpenRouter, OpenAI, or any OpenAI-compatible endpoint), plus a chat platform to pair if you want one. The CLI works before any channel is connected, so pairing can wait.

Keep it running across reboots#

Scheduled automations only fire if the server is awake and the process is up. Confirm that what the installer registered survives a restart:

systemctl list-units --type=service --state=running   # find the unit the installer created
sudo systemctl is-enabled <unit>                      # should print: enabled
sudo journalctl -u <unit> -f                          # live logs, Ctrl+C to stop
sudo reboot                                           # then reconnect and check again

No unit? Write one. Run an App as a systemd Service covers unit files, a dedicated unprivileged user, and secrets in an EnvironmentFile. Under Compose, restart: unless-stopped does the same job; see Install Docker and Docker Compose.

Keep the dashboard private#

A UI that can drive an agent with terminal access does not belong on the public internet, no matter how good its login is. Bind it to loopback, then reach it over an SSH tunnel or a tailnet: Keep a Dashboard Private has all three options.

Back up what it learns#

The memory and skills store is the artifact worth protecting: lose the disk and you lose the agent you trained, not just an install you can repeat. Every VPS plan includes one free off-node backup, but that is one point in time rather than a versioned history, so add your own.

Find the directory before you try to back it up. The vendor documentation names it, and the running service will tell you where it ended up on your server:

systemctl show -p WorkingDirectory --value <unit>   # where the service runs from
systemctl show -p EnvironmentFiles --value <unit>   # config, which usually names the data path
sudo lsof -p "$(systemctl show -p MainPID --value <unit>)" | grep -i data   # what it has open

With the path in hand:

• Take a snapshot before an upgrade or a risky change.
• Copy that directory off the server nightly. The restic pattern in Back Up a Dockerised App works for any directory, container or not.
• Backups, RAID, and Data Protection covers what each layer misses.

Next: scope the credentials before you hand it anything real. Security for a self-hosted AI agent covers what to give it, what to keep back, and what to do the moment it does something you did not intend.