Hello, I'm Lena. I've been running Hermes Agent self hosting on three different VPSes for a few months now, and my honest observation is this: getting it installed on a server takes maybe twenty minutes. Getting it to stably run for weeks without needing babysitting takes several iterations. I'm still not sure I've got the third box right, actually. That's the gap this guide is about — not the install, but the slow layer between "works once" and "I trust it to keep working while I sleep."

If you just need the official install path, the Hermes Agent installation docs cover it. This piece is what comes after.

When self-hosting Hermes makes sense

Privacy, continuity, cost control, always-on workflows

Before any of the server stuff — self-hosting is a commitment, not a shortcut. It makes sense when you need one or more of these:

Privacy. Your conversations, memories, and skills stay on infrastructure you control. API calls still go out to whichever model provider you configured, but everything surrounding them — session history, user profile, workspace files — stays local.

Continuity. A laptop that sleeps or closes kills a local agent. A VPS doesn't. If you want the agent to answer a Telegram message at 3 a.m. or run a scheduled cron job you didn't have to open a terminal for, you need it elsewhere.

Cost control. Self-hosting doesn't reduce model costs — those are whatever the provider charges. What it does change is the overhead: no seat licensing, no per-user pricing on a managed plan, just the cost of the box plus your provider tokens.

Always-on workflows. Gateway integrations (Telegram, Discord, Slack, messaging bots) only make sense if the agent is always listening. Same for cron jobs.

If none of those apply and you use the agent for thirty minutes in the evening from your laptop, honestly — don't self-host. The complexity isn't worth it.

Choose a VPS and base OS for Hermes

Minimum vs recommended specs

This is where I want to push back on the "runs on a $5 VPS" framing. Technically true. Practically fragile. Here's what I've actually observed:

1 vCPU / 1 GB RAM: Will boot. Will crash under any real workload. Python + Node + the agent's own processes eat RAM fast, especially once the gateway is running. I had one of these locked up during a single debugging session.
2 vCPU / 2 GB RAM: Workable for CLI-only use, single user, no gateway. Still tight. Swap helps but isn't a fix.
2 vCPU / 4 GB RAM: My real-world minimum for gateway + cron + light skills. This is where things stop feeling flaky.
2–4 vCPU / 8 GB RAM: Comfortable for multi-profile use, several connected platforms, and headroom for the occasional heavy task.

Base OS: Ubuntu 22.04 or 24.04 LTS. I use both. Debian 12 works fine too. Anything else, you're on your own for dependency edge cases.

Storage: 30–40 GB is plenty for the agent itself. Session databases grow slowly — maybe 50 MB per month of active use. Logs are the thing that can surprise you, which I'll come back to.

What changes when gateway and cron run continuously

This is the part I almost forgot to learn the hard way. Running Hermes interactively is different from running it as a persistent service. When the gateway is always listening and cron is firing scheduled jobs, you have:

Constant memory residency (no garbage-collected idle state)
Continuous log volume
Network retries that can pile up during provider outages
File handles that need to survive restarts
Secrets (API keys, tokens) that must be accessible to the service, not just your shell

I'm not sure if I'm reading this correctly, but my impression is that most "my VPS keeps running out of memory" reports are really "I sized for interactive use and then turned on gateway + 4 cron jobs." Plan for the persistent load, not the empty one.

Install and harden Hermes on a server

Service user, directory layout, updates, backups

Don't run Hermes as root. This is the one non-negotiable. Create a dedicated user:

Bash

sudo adduser hermes
sudo usermod -aG docker hermes   # only if you plan to use the Docker terminal backend

Then install as that user. Everything lands in ~/.hermes/ — config, sessions, memory, skills. That directory is your state. Back it up.

My actual backup is boring:

Bash

tar -czf hermes-backup-$(date +%F).tar.gz ~/.hermes/

Run it weekly via cron, ship the tarball off-box (object storage, another VPS, whatever). The thing you want to protect is config.yaml, the session database, and MEMORY.md/USER.md. Skills are recoverable from the hub. Memory and config are not.

For updates: the installer ships with an update path. But I've learned to take a snapshot or a backup before any update, because occasionally an update changes config schema and I don't want to find that out mid-conversation. Version info is visible in the Hermes Agent GitHub repository if you want to check changelogs before pulling.

Firewall: keep the VPS's public surface minimal. UFW is the simplest path — the Ubuntu Server firewall documentation walks through it well. My rules for a Hermes-only box look roughly like:

Bash

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw enable

That's it. Hermes doesn't need any open inbound ports for most setups — the gateway connects outward to messaging platforms. If you add a web UI or expose an API locally, only then open a specific port.

Running gateway under systemd

This is the piece that turns a running process into a service. Without systemd (or something equivalent), the moment your SSH session dies, so does hermes gateway. I lost a Telegram bot to this at least once before I actually wrote the unit file.

Here's the shape I use. Save as /etc/systemd/system/hermes-gateway.service:

TOML

[Unit]
Description=Hermes Agent Gateway
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=hermes
Group=hermes
WorkingDirectory=/home/hermes
ExecStart=/home/hermes/.local/bin/hermes gateway start
Restart=on-failure
RestartSec=10
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Then:

Bash

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

A couple of details I wish someone had told me earlier. Restart=on-failure + RestartSec=10 is the minimum. Without it, any transient error kills the service permanently. The systemd.service manual page has the full list of restart policies — on-abnormal is an alternative if you want to let the service choose to exit cleanly without auto-restart.

Also — User=hermes is doing real work here. Not just security. It ensures the service reads from the hermes user's ~/.hermes/ directory and not from root's (which won't exist, and you'll get a cryptic config error). I got this one wrong the first time.

For hardening the unit file further — NoNewPrivileges=true, ProtectSystem=strict, PrivateTmp=true — I won't reproduce all of it here, but DigitalOcean's systemd units and unit files guide shows a production-style hardened example that's worth copying from.

Production checks before you trust the setup

Restart behavior, logs, provider failure, file persistence

Before I call a box "done," I run through four checks. None of them are optional. I've skipped them on a machine I thought I knew, and regretted it.

Restart survives a reboot**.**

Bash

sudo reboot
# wait, then:
ssh back in
systemctl status hermes-gateway

If the service isn't active after reboot, you forgot enable. Fix it now.

Logs are readable and rotating.

Bash

journalctl -u hermes-gateway -n 100
journalctl -u hermes-gateway --since "1 hour ago"

Important — set journal limits before the disk fills. Edit /etc/systemd/journald.conf and set SystemMaxUse=500M (or whatever fits your box). The Arch Wiki's systemd journal page explains the rotation and vacuum options in more detail than most distro-specific docs. I learned this one by having a box run out of disk entirely. Not fun.

Provider failure is recoverable.

Temporarily break your API key (rename the env var, revoke the token, whatever). Send a message through the gateway. Does the service crash? Does it log the error? Does it recover once you restore the key?

My baseline expectation: the agent should log a clear error and keep running, not die. If it dies, you have an operational problem you'd rather discover now than at 3 a.m.

File persistence across restarts.

Have a conversation. Send a message. Restart the service. Resume the session. Does memory carry across? Does the session survive? If not, check ~/.hermes/ permissions — this is almost always a user/group issue.

Common VPS mistakes

Under-sizing RAM, weak logging, unsafe shell access, no rollback path

The four failure modes I see most often, in roughly the order I made them myself:

Under-sized RAM. Already covered. 2 GB is a floor, not a target.

Weak or unlimited logging. If you don't configure journal size limits, your logs will eat the disk. When the disk fills, the agent fails in weird ways — config writes fail silently, skills can't save, sessions corrupt. Set the limits on day one.

Unsafe shell access for the agent. If you let the agent execute arbitrary shell commands with the terminal backend set to local and you're running as a user with sudo rights, the blast radius of a mistake is your whole machine. Either use terminal.backend=docker to sandbox it, or run under a dedicated user with no sudo. I prefer both.

No rollback path. One bad update, one bad config edit, and you want a way back. Snapshot the VPS before any major change. Keep the last three tarball backups. I've used them. They've saved me.

FAQ

Do I need Docker?

Not required, but recommended for the terminal backend if you're going to let the agent run arbitrary commands. Safer sandbox.

Can I run multiple profiles on one VPS?

Yes — hermes profiles create work, then switch between them. Each has isolated config, memory, and skills.

How do I update without downtime?

You can't really, but downtime is short. Stop the service, pull the update, restart. A minute or two.

Can I run the gateway and CLI at the same time?

Yes, as long as they're on the same profile. Sessions are shared.

What if my provider goes down?

Nothing you can do about the provider, but if Hermes is configured for provider fallback, it'll try the next one. If you haven't configured fallback, the gateway will error cleanly and recover once the provider is back.

I might be overthinking this, but the pattern I keep coming back to is: the VPS isn't the hard part. The hard part is the slow, quiet discovery of everything that can go wrong over a month of uptime. That's really the shape of self-hosting. I'll keep watching how my own setup behaves, and probably update this when I break something new. That's where I'll leave it for now.