Hermes Agent: what it is, what it's good for, and how to run it on a server

Most AI agents live in a session. You open a terminal or a chat tab, give it a task, and when you close it, it’s gone. Hermes Agent is built the other way round: it is meant to run all the time, on a machine you control, remembering what it has learned and reachable from your phone.

That makes it very good at some jobs and a poor fit for others. Here is what it is, when we would use it, and how to set it up on a server properly.

Hermes moves fast. Commands below are from the official README and docs at the time of writing. Check the Hermes Agent docs before relying on a detail.

What Hermes Agent is

Hermes Agent is an open-source agent from Nous Research, released under the MIT licence. The project describes it as “the self-improving AI agent”. In practice that means a few things working together:

• Persistent memory. The agent curates its own memory and can search past sessions, so it can recall what you discussed last month.
• Skills it writes itself. After a complex task, Hermes can turn what it did into a reusable skill and improve it on later use. Skills follow the open agentskills.io format, the same idea as skills in Claude Code.
• A messaging gateway. One gateway process connects the agent to Telegram, Discord, Slack, WhatsApp, Signal, email and more, so you can talk to it from wherever you are.
• Scheduling. A built-in cron scheduler runs jobs on a timetable and sends results to any connected chat: a daily report, a nightly check, a weekly summary.
• Tools and backends. Dozens of built-in tools, support for MCP servers, and several places to run commands: locally, in Docker, over SSH, or in serverless sandboxes such as Modal and Daytona.
• Subagents for parallel work.
• Any model. Hermes doesn’t bundle a model. You connect Nous Portal, OpenRouter, OpenAI, Anthropic, a custom endpoint or a local model, and switch with hermes model.

What it is good for

Hermes shines when the value comes from continuity: the agent being there all the time and getting better at your particular work.

• A personal operations assistant you message from your phone: “what’s on my calendar”, “summarise yesterday’s support tickets”, “remind me Friday to chase the invoice”.
• Scheduled reports and checks: a morning digest of what changed in a repository, a nightly check that backups ran, a weekly summary of a shared inbox.
• Recurring research and monitoring: tracking competitors’ releases, new regulations in your sector, or price changes, delivered to a Slack channel.
• Light DevOps: running known diagnostics on a server and reporting back, with dangerous commands requiring your approval.

It is a weaker fit for heavy software engineering inside a repository, where dedicated coding agents like Claude Code, Codex or OpenCode are built for the job, and for business-critical processes that need strict permissions, audit trails and approval queues designed around one workflow. Those need a purpose-built harness.

Why run it on a server

You can run Hermes on a laptop, but its strengths (always on, scheduled jobs, reachable from chat) only really show on a machine that never sleeps. A server also means:

• Scheduled jobs actually run at 3am.
• You reach it from anywhere through Telegram or Slack, without exposing your laptop.
• It is isolated from your personal files and browser sessions.
• It is cheap. With a hosted model, the agent itself needs very little; the official site says a $5 VPS is enough.

We wrote a broader piece on why run an AI agent on a server covering the trade-offs for every harness.

Step by step: Hermes on a VPS

1. Prepare the server

Use a small Linux VPS (Ubuntu or Debian is fine). Create a dedicated, non-root user for the agent, turn on a firewall that denies inbound traffic by default (the messaging gateway connects outwards, so it needs no open ports), and install Docker if you want container isolation (recommended).

sudo adduser --disabled-password hermes
sudo usermod -aG docker hermes   # only if you will use the docker backend
sudo -iu hermes

2. Install Hermes

As that user, run the official installer. As with any piped script, you can download and read it first.

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

3. Run the setup wizard

hermes setup

The wizard walks through choosing a model provider and API key, tools and basic settings. hermes setup --portal is a shortcut if you use Nous Portal. You can change the model later with hermes model and inspect settings with hermes config get. Secrets are stored in ~/.hermes/.env; lock that file down:

chmod 600 ~/.hermes/.env

4. Isolate command execution

By default commands can run directly on the host. On a server, run them in Docker instead, with limits, by editing ~/.hermes/config.yaml:

terminal:
  backend: docker
  docker_forward_env: []    # pass in only the variables you list
  container_cpu: 1
  container_memory: 5120    # MB
  container_disk: 51200     # MB

With a container backend, the container is the security boundary. Anything you list in docker_forward_env is readable inside it, so keep that list short.

5. Keep approvals on

Hermes asks before running dangerous commands. The default smart mode lets a second model auto-approve clearly low-risk commands and asks you about the rest; manual asks every time. Unanswered requests are denied after a timeout. Leave scheduled and unattended runs on deny unless you have a reason not to:

approvals:
  mode: smart            # smart | manual | off
  cron_mode: deny
  unattended_mode: deny

Don’t use off outside throwaway containers.

6. Connect a chat app

Set up the gateway, for example with a Telegram bot token:

hermes gateway setup

Then decide who can talk to the agent. By default, the gateway denies everyone not on an allowlist or paired. Either list your user IDs in ~/.hermes/.env:

TELEGRAM_ALLOWED_USERS=123456789

or use DM pairing: an unknown user who messages the bot gets a one-time code, and you approve it on the server:

hermes pairing approve telegram XKGH5N7P

Never set GATEWAY_ALLOW_ALL_USERS=true on a bot that can run commands.

7. Run the gateway as a service

So it survives reboots and logouts:

sudo hermes gateway install --system
sudo hermes gateway start --system
sudo hermes gateway status --system
journalctl -u hermes-gateway -f

The service still runs as your user. On a personal machine, the per-user version (hermes gateway install without --system, plus sudo loginctl enable-linger $USER) is enough.

8. Keep it healthy

• hermes update regularly.
• hermes doctor when something looks wrong.
• Watch ~/.hermes/logs/ for unexpected access attempts.

A security checklist

Before you rely on it, check you have:

• a dedicated non-root user and a default-deny firewall,
• the Docker backend with CPU, memory and disk limits,
• explicit allowlists or DM pairing, never allow-all,
• approvals on, with unattended and cron runs set to deny,
• ~/.hermes/.env readable only by the agent’s user,
• API keys with spending limits set at the provider,
• a plan for updates.

For extra separation, Hermes can run its commands on a different machine over SSH (terminal.backend: ssh), so the gateway holding your chat tokens never executes anything itself.

Our take

Hermes is one of the most interesting open-source harnesses right now, because it takes memory and self-written skills seriously. For a personal or small-team assistant that lives in chat and runs scheduled work, it is an excellent choice. For production business processes, we still build narrow agents with explicit permissions and human approvals, because there “it learned a new skill on its own” is something you want to review, not discover.

Comparing options? Read AI agent harnesses compared.