Hermes Agent vs OpenClaw on a VPS

The short answer

Hermes Agent and OpenClaw both give you a persistent agent on a VPS that you can reach from a chat app. Pick Hermes Agent when the agent's main job is recurring work: scheduled jobs and procedures it should learn once and reuse. Pick OpenClaw when the main job is reach: one assistant that answers on WhatsApp, Telegram, Discord, Slack and around twenty other channels, extended with packages from a public registry. Both run from the CLI (command-line interface) and from chat, so the choice is about which side each project puts first, and about what each one opens on your server.

This comparison pins Hermes Agent to tag v2026.9.7 (7 September 2026) and OpenClaw to tag v2026.9.4 (11 September 2026). Both projects tag several times a month, so check the docs for anything that has moved. Every claim below comes from each project's own documentation at those tags, or from the two outside sources named where they are used.

What each one is for: agent-first or gateway-first

Hostinger's comparison calls Hermes Agent "agent-first" and OpenClaw "gateway-first". That framing is fair, and it is the fastest way to understand the two projects.

Hermes Agent, from Nous Research, is built around a worker. You give it a task. It runs the task in a terminal backend and writes down what it learned as a skill. It also keeps a small memory of durable facts. Chat is one of several ways to submit work. The CLI, cron jobs, the messaging gateway and the desktop app all feed the same agent, and the gateway is a feature you turn on with hermes gateway setup rather than the thing you install.

OpenClaw is built around its Gateway. The Gateway is a long-running process that its docs call the single source of truth for sessions, routing and channel connections. Models and agent harnesses are plugins that attach to it, and the README names Claude, Codex and local models as harnesses you can swap. Reach is the product. The agent is one thing the Gateway hosts.

The two projects have borrowed each other's good ideas. Both now pair unknown chat senders with a code before they can talk to the bot. Both now let the agent produce skills: Hermes writes them itself, and OpenClaw's Skill Workshop drafts them for your approval. The framing still holds at the centre: Hermes is a worker with a chat front end, and OpenClaw is a chat hub with a worker behind it.

Install path and VPS footprint

Neither project documents a RAM or CPU minimum, so none is invented here. Both agents are thin next to the model calls they make, and the real load on the box comes from what you ask the agent to run. How much RAM and CPU a coding-agent VPS needs works through sizing from the workload rather than from the agent.

One documented number is worth knowing. When Hermes uses its Docker terminal backend, its docs set the sandbox container's limits at container_cpu: 1 and container_memory: 5120 (in MB) by default. Those are limits on the container rather than a measured need, but a VPS smaller than that cannot honour them.

Hermes installs with one script. It needs Python 3.11, which it fetches through uv, and on Linux it needs git, curl and xz-utils first.

sudo apt update && sudo apt install -y git curl xz-utils
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
source ~/.bashrc
hermes doctor

The code lands in ~/.hermes/hermes-agent/ as an editable git checkout and the command in ~/.local/bin/hermes. All data lives under ~/.hermes/. The installer's own text says it uses sudo only for optional system packages and that Hermes itself does not require or retain root. The docs page does not describe pinning, but the installer script accepts --commit SHA, which pins the checkout to a specific commit after clone or update. Get the commit behind the tag, export it as HERMES_SHA, and pass it through:

git ls-remote --tags https://github.com/NousResearch/hermes-agent v2026.9.7
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash -s -- --commit "$HERMES_SHA"

If ls-remote prints two lines, use the one ending in ^{}. That is the commit the annotated tag points at, and --commit wants a commit SHA rather than a tag object. After install, hermes model picks the provider and model, hermes tools turns tools on, hermes setup runs the whole wizard, and hermes doctor checks the result.

OpenClaw installs with one script too, or through npm, and it needs Node. The docs ask for Node 24.16 or newer, or 26.1 or newer, and say the Linux installer fetches Node 24 LTS (long-term support) when it is missing. The npm path is the one that accepts an exact version, which is how you pin it.

curl -fsSL https://openclaw.ai/install.sh | bash
# or, pinned:
npm install -g openclaw@2026.9.4 --allow-scripts=openclaw
openclaw onboard --install-daemon

openclaw onboard --install-daemon runs the setup wizard and installs the Gateway as a systemd user service on Linux. Config lives in ~/.openclaw/openclaw.json, which is JSON5, so comments and trailing commas are allowed. OpenClaw also publishes an Extended Stable line, tagged v2026.6.35 on 10 September 2026, for people who want fewer changes per month; the install docs describe openclaw update --channel stable and --channel dev for moving between channels.

The Hermes Agent VPS guide and the OpenClaw containment guide carry the full install of each, with the checks that each step should pass.

What each one opens on the network

This section decides the firewall, so it is the most careful one.

OpenClaw opens a port by design. The Gateway listens on TCP 18789 by default, chosen in this order: --port, then OPENCLAW_GATEWAY_PORT, then gateway.port in the config, then 18789. gateway.bind defaults to loopback, and the other values are auto, lan (which means 0.0.0.0), tailnet and custom. The Control UI sits on the same port at http://127.0.0.1:18789, under the /openclaw base path. The docs are direct about the risk: "Non-loopback binds require gateway auth. In practice that means a shared token/password or an identity-aware reverse proxy." gateway.auth.mode takes none, token, password or trusted-proxy, and the onboarding wizard generates a token by default. Leave bind on loopback, reach the UI over an SSH tunnel, and run openclaw security audit to report any drift from those defaults.

Hermes opens no port that its docs name. The gateway connects out to each chat platform as a client, and the security and messaging docs contain no listening-port statement at all. The CLI talks out to a model endpoint and to a terminal backend. The Docker backend talks to the local Docker socket. The SSH backend talks out to another host on port 22. So a Hermes box can keep an inbound policy of "SSH only" and nothing about the agent needs to change.

Chat platforms mostly do not need an inbound port on either project. Both use long polling or outbound WebSockets for the main channels. Hermes' Slack integration uses Socket Mode, and its docs say your instance "doesn't need to be publicly accessible". Hermes' WhatsApp integration runs a Node.js bridge that emulates WhatsApp Web through an outbound connection, paired by QR code, and needs Node.js v18 or newer on the box. OpenClaw's Telegram channel says "Long polling is the default transport. Webhook mode is optional", and its WhatsApp channel is QR-only over an outbound WebSocket. The exceptions are the paths that name a public URL: OpenClaw's Telegram webhook mode (webhookUrl, webhookPort, webhookSecret) and Hermes' separate WhatsApp Business Cloud API option, which its docs say needs a Meta Business account and a public webhook URL. Skip both unless you have a reason.

Both default to denying unknown chat senders. Hermes checks, in order: a per-platform allow-all flag, the pairing approved list, per-platform allowlists such as TELEGRAM_ALLOWED_USERS, the global GATEWAY_ALLOWED_USERS, the global allow-all flag, then deny. An unknown sender gets an 8-character pairing code by DM (direct message), and you approve it with hermes pairing approve <platform> <code>. OpenClaw's dmPolicy defaults to pairing on Telegram and on WhatsApp, and you approve with openclaw pairing approve <channel> <code>. Never set GATEWAY_ALLOW_ALL_USERS=true or dmPolicy: open on a bot that can run shell commands.

How the OpenClaw containment applies to Hermes

The containment in the OpenClaw containment guide comes down to a dedicated unprivileged user, a Gateway pinned to loopback behind the VPS firewall, a Docker sandbox for tool execution with agents.defaults.sandbox.mode set to all, and a token on anything that is not loopback. OpenClaw's own sandbox page makes the boundary explicit: the Gateway process itself always runs on the host, and sandboxing only moves tool execution. tools.elevated is an escape hatch that runs outside it.

The user and the firewall carry straight over to Hermes. The dedicated user is the same wall, and Hermes' production checklist says it in six words: "Never run the gateway as root". The firewall wall is easier, because there is no port to pin, and the token has nothing to guard.

The sandbox maps to terminal.backend in ~/.hermes/config.yaml. Hermes documents seven backends: local, docker, ssh, singularity, modal, daytona and vercel_sandbox. With docker, the container runs with --cap-drop ALL, then re-adds DAC_OVERRIDE, CHOWN and FOWNER, and sets --security-opt no-new-privileges and --pids-limit 256, with /tmp and /var/tmp on tmpfs mounted nosuid. One difference matters. Hermes' docs say the dangerous-command checks are skipped on the docker, singularity, modal, daytona and vercel_sandbox backends, "because the container itself serves as the security boundary". So on Hermes you get one wall or the other per backend. On the local backend you get the approval gate and no container. On docker you get the container and no approval gate.

The Hermes docs add a layout of their own: "run the gateway on a separate machine or VM" (virtual machine) with terminal.backend: ssh. The gateway box holds the chat tokens and the model key and never runs a command. The worker box runs commands and holds nothing worth stealing. A disposable VM for coding agents is the natural worker in that layout, because you rebuild it rather than clean it.

Memory: two small frozen files, or a live workspace

The memory models differ more than anything else in this comparison, and mem0's comparison of the two is the clearest write-up of the difference. Its summary: Hermes "optimizes for cache-stable long sessions" while "OpenClaw optimizes for immediate visibility".

[
  {
    "label": "Hermes MEMORY.md (hard cap)",
    "char_limit": "2,200"
  },
  {
    "label": "Hermes USER.md (hard cap)",
    "char_limit": "1,375"
  },
  {
    "label": "OpenClaw MEMORY.md (soft target)",
    "char_limit": "20,000"
  }
]

The Hermes figures are from its memory docs. The OpenClaw figure is the soft target mem0 reports.

Hermes keeps two files under ~/.hermes/memories/. MEMORY.md holds the agent's own notes and is capped at 2,200 characters. USER.md holds facts about you and is capped at 1,375 characters. The docs say the caps are strict: a write past the cap returns an error instead of silently truncating. The agent edits them with three verbs, add, replace and remove, where replace and remove match on a substring. Both files load once at session start as a frozen block in the system prompt, which keeps the prompt-cache prefix stable. The cost of that design is that a memory the agent writes mid-session is on disk at once but not in its prompt until the next session. For older facts, session_search runs FTS5 (SQLite's full-text search) over every past conversation in ~/.hermes/state.db.

OpenClaw treats memory as a workspace. ~/.openclaw/workspace/MEMORY.md is the primary file, with a soft target of about 20,000 characters, plus daily notes in memory/YYYY-MM-DD.md where today's and yesterday's files load automatically. A memory_search tool runs hybrid retrieval, vector similarity plus keyword match, over all of it. mem0 notes that memory is re-injected every turn, so a write is visible on the next turn.

Which is better depends on the job. A Hermes agent running the same cron job every night wants a stable prompt and a small set of facts it can trust. An OpenClaw assistant fielding a hundred short chats a day wants to remember what you said an hour ago without a restart. Hermes lists Mem0 among eight memory providers you enable with hermes memory setup, and mem0 publishes an @mem0/openclaw-mem0 plugin for OpenClaw. Self-hosting a Mem0 memory server gives both agents the same server-side fact extraction and lifts the size caps out of the conversation. Whatever file the agent writes to becomes an input it trusts later, so how agent memory gets poisoned applies to both projects, and to the skills in the next section.

Skills: self-written procedures, or a public registry

Hermes writes its own skills. A skill is a directory under ~/.hermes/skills/ with a SKILL.md and optional scripts/, references/, templates/ and examples/ folders, in the agentskills.io format. The agent has a skill_manage tool, and its system prompt names three triggers for writing one: it worked out a multi-step process worth repeating, it found a workaround after an error, or it took a correction from you. The docs describe the goal as "lessons, not logs". If you do not want an agent editing its own instruction set unreviewed, set skills.write_approval: true; new skills then stage under ~/.hermes/pending/skills/ until you approve them. Hermes can also install skills from outside with hermes skills install <identifier>: from GitHub repos such as anthropics/skills, from skills.sh, from a direct URL to a SKILL.md, or from ClawHub itself. The docs say every hub install is scanned for data exfiltration, prompt injection and destructive commands. A community finding that is not dangerous can be overridden with --force; a "dangerous scan verdict" blocks the install even with --force.

OpenClaw pulls skills and plugins from ClawHub, its public registry. openclaw skills search "calendar" finds one, openclaw skills install @openclaw/demo installs it, openclaw skills update --all keeps them current, and code plugins go through openclaw plugins install clawhub:<package>. Skills load from a ranked set of directories, with <workspace>/skills winning over ~/.agents/skills, then the managed <state-dir>/skills, then the bundled set. A skill's SKILL.md can declare metadata.openclaw.requires.bins and requires.env, and OpenClaw hides the skill when the binary or the variable is missing, which is a cleaner failure than a skill that half-works. The agent does not write skills to disk on its own. The Skill Workshop lets it draft a proposal, and you approve it.

The review models differ in where the check runs. ClawHub's docs say it "runs automated checks on published skills and plugin releases", that scan-held or blocked releases can disappear from the public catalogue, that signed-in users can report a package and moderators can hide it, and that publishing needs a GitHub account old enough to pass the upload gate. That is review at the registry. Hermes runs its scan at install time on your box, and the write-approval gate covers the skills its own agent writes. OpenClaw's skills page still ends with the line that matters for both: "Treat third-party skills as untrusted code. Read them before enabling."

Model and auth options, and the Claude subscription question

Both projects run on an API key or on a local model, and both route through OpenRouter. The differences are in the subscription paths, which is what most people searching this topic want to know.

API keys. Hermes reads ANTHROPIC_API_KEY, OPENROUTER_API_KEY, OPENAI_API_KEY and a long list of others from ~/.hermes/.env. hermes model picks a provider and model interactively, and hermes config get model shows the choice. Nous Portal is its own provider: hermes setup --portal is one OAuth login that gives a model provider plus the hosted tool gateway. OpenClaw takes ANTHROPIC_API_KEY through openclaw onboard --anthropic-api-key "$ANTHROPIC_API_KEY", and openclaw models list --provider anthropic shows what it can reach. Its docs list anthropic/claude-opus-5 as the primary default, with anthropic/claude-fable-5-1 and anthropic/claude-sonnet-5 alongside.

Local models through Ollama. The two projects point at Ollama differently, and mixing them up is a real failure. Hermes uses the OpenAI-compatible endpoint: in config.yaml, set model.provider: custom and model.base_url: http://localhost:11434/v1, or pick "Custom endpoint" in hermes model. Its docs also state that Hermes "requires at least 64,000 tokens of context for agent use with tools", and Ollama's default is far lower, so start it with OLLAMA_CONTEXT_LENGTH=64000 ollama serve. OpenClaw goes the other way. Its Ollama page says: "Do not use the /v1 OpenAI-compatible URL (http://host:11434/v1). It breaks tool calling and models can emit raw tool-call JSON as plain text." OpenClaw talks to Ollama's native /api/chat, with the config key baseUrl set to http://127.0.0.1:11434 and models named ollama/<model>. Same daemon, opposite URLs.

A Claude subscription. Here is exactly what each project's docs say, as of September 2026, and no more.

Hermes: an OAuth login exists through hermes model (choose Anthropic OAuth) or hermes auth add anthropic --type oauth, and Hermes then routes "as Claude Code against your Anthropic account". The docs add: "It only works if you're on a Claude Max plan and have purchased extra usage credits." The base Max allowance is not consumed; usage bills against the extra credits. Claude Pro cannot use this path, and the docs tell Pro subscribers to use an ANTHROPIC_API_KEY at standard API pricing.

OpenClaw: the docs describe reusing "an existing Claude Code login through the installed executable on the same host". You install the Claude CLI on the VPS, run claude auth login, then choose "Claude CLI" in openclaw onboard. A second form uses a setup token: run claude setup-token, then openclaw models auth login --provider anthropic --method setup-token. Two sentences from the same page set the limits: "Claude Code owns its existing login and subscription; OpenClaw does not persist or refresh that login", and subscription-plan usage through the Agent SDK, claude -p and third-party apps "still draw from the signed-in subscription's usage limits".

The two projects describe the billing of that usage differently, and neither page is Anthropic's. Before you build a nightly workload on a subscription login, read Anthropic's current terms for third-party use of a Claude plan. Both projects document a path, and both paths go through Claude Code's identity rather than a plain claude.ai login. Hermes scopes its path to Max with extra credits; OpenClaw scopes its path to the same host as the Claude CLI login.

Other subscriptions. Hermes also documents OpenAI Codex through device-code OAuth against a ChatGPT plan, and GitHub Copilot through its device flow, though the Codex page says which plan tiers are eligible is "not currently documented". OpenClaw lists Codex among its swappable harnesses. If you already pay for one of those, that is a real reason to prefer the project that documents it.

Security posture, in each project's own words

Hermes gates commands. approvals.mode in config.yaml is smart by default: an auxiliary model rates each command. Low-risk commands run and clearly dangerous ones are refused. Anything uncertain asks you. manual always asks on a dangerous match, and off disables the gate. The scanner matches recursive deletes, chmod 777 and its relatives, mkfs, dd if=, redirects into /etc/, systemctl stop or disable or mask, DROP TABLE, curl ... | sh and fork bombs. In chat, the gateway posts the command and waits for yes, y, approve, ok or go, with no or cancel to refuse, and a 300-second default timeout. The --yolo flag (or /yolo in a session, or HERMES_YOLO_MODE=1) skips the prompts, but a hardline blocklist stays on even then: rm -rf /, fork bombs, mkfs on a mounted root, dd to a block device, and an untrusted URL piped to a shell. Remember from the containment section that this gate is off on the container backends.

OpenClaw draws boundaries. Its security page says the Gateway is "one trusted boundary per gateway" and "not a hostile multi-tenant security boundary for mutually adversarial users", so two people who do not trust each other get two Gateways with two sets of credentials. Tool allow and deny policies are checked before the sandbox rules, so a tool denied globally stays denied inside a sandbox. Per-agent access profiles and a read-only mode narrow what an agent can touch. openclaw security audit compares the live config against safe defaults. The skills side is the ClawHub review described above, plus the instruction to read third-party skills before enabling them.

Neither project claims more than that. Hermes does not claim its scanner catches everything, and its docs move you to a container or a second machine when the stakes rise. OpenClaw does not claim the sandbox contains the Gateway itself, and it says so on the sandbox page. Both are honest documents, which is a good sign for software you are going to leave running unattended.

The decision matrix

Recurring workflows: Hermes. Cron jobs with memory, a skill it writes after the third time it does the same task, a memory it cannot overrun, and a terminal backend you choose per risk level. If the agent's week is mostly jobs and only sometimes conversation, this is the shape.

Messaging reach: OpenClaw. Around twenty channels behind one Gateway, DM pairing on all of them, a Control UI on the same port, and a registry of ready-made skills and plugins. If the agent's week is mostly conversation across apps and only sometimes a job, this is the shape.

One box: either, with the wall that fits. OpenClaw on one VPS with a dedicated user, gateway.bind: loopback, a token, and sandbox.mode: all. Hermes on one VPS with terminal.backend: docker, knowing that the approval gate is off inside the container, or with terminal.backend: local and approvals.mode: manual, knowing that a wrong approval runs on the host.

Two boxes: Hermes, by its own docs. Gateway on one VPS, terminal.backend: ssh to a worker VPS, chat tokens and model keys on the first, nothing worth keeping on the second. OpenClaw can sit behind a reverse proxy with trusted-proxy auth, but the Gateway still executes on its own host unless every agent is sandboxed.

Local model only: check the URL twice. Hermes wants /v1 and 64k of context. OpenClaw refuses /v1 and wants the native API.

Already paying for Claude Max with extra credits: Hermes documents that path, narrowly. Already running Claude Code on the same host: OpenClaw documents reusing it. Paying for Claude Pro: use an API key on either.

Undecided between these two and the rest of the field: the self-hosted agent roundup places both against Agent Zero, OpenHands and the others on the same axes.

FAQ

Can Hermes Agent use a Claude Max subscription?

Hermes' docs say yes, with a narrow scope. Log in through hermes model (Anthropic OAuth) or hermes auth add anthropic --type oauth, and Hermes routes as Claude Code against your account. The docs state it "only works if you're on a Claude Max plan and have purchased extra usage credits", that usage bills against those extra credits rather than the base allowance, and that Claude Pro subscribers must use ANTHROPIC_API_KEY instead. As of September 2026, read Anthropic's own terms before relying on it for unattended work.

Does OpenClaw need a port open on my VPS?

Not for normal use. The Gateway listens on TCP 18789, but gateway.bind defaults to loopback, so it answers only on 127.0.0.1. Reach the Control UI at http://127.0.0.1:18789 over an SSH tunnel. Telegram uses long polling and WhatsApp uses an outbound WebSocket, so no channel needs an inbound port unless you choose Telegram's optional webhook mode. If you do bind to lan or tailnet, the docs require gateway auth: a shared token or password, or an identity-aware proxy in front.

Which one is safer to leave running unattended?

Neither is safe on a local backend with approvals off. Hermes is safest as two boxes: gateway on one VPS, terminal.backend: ssh to a worker VPS, which its own docs recommend "for maximum security". OpenClaw is safest with a dedicated unprivileged user, gateway.bind: loopback, a token, and agents.defaults.sandbox.mode: all. In both cases treat the agent's memory files and skills directory as inputs that an attacker can write to through a chat message.

Can I run Hermes Agent and OpenClaw on the same VPS?

Yes. They do not share ports or directories. Hermes keeps everything under ~/.hermes/ and opens no listening port. OpenClaw keeps everything under ~/.openclaw/ and listens on 127.0.0.1:18789. Give each its own Linux user so a compromised agent cannot read the other's chat tokens. Do not point both at the same Telegram bot token, because Telegram allows one long-polling client per bot and answers the second with 409 Conflict: terminated by other getUpdates request.

How do I pin each project to a release?

OpenClaw's npm path takes an exact version: npm install -g openclaw@2026.9.4 --allow-scripts=openclaw, and npm view openclaw versions lists what is published. Hermes' installer takes --commit SHA, so get the commit behind v2026.9.7 with git ls-remote --tags https://github.com/NousResearch/hermes-agent v2026.9.7 and pass it as bash -s -- --commit <sha>. Both projects tag several times a month, so record which tag you tested against.