How to Host Hermes Agent on a VPS Safely

Hermes Agent becomes more useful when it is treated as a small operating environment, not as another chat window. It can keep memory, respond through gateways, run scheduled work, use tools, create skills, and move between local or server-based deployments. That is exactly why a VPS can be the right home for it, and also why the setup should be planned before the agent touches real accounts.

This guide focuses on the Hermes-specific deployment problem: persistent memory, skills, gateways, approvals, logs, secrets and migration into a stable server. The Linux example pins Hermes v0.21.7 to an immutable source commit and keeps application code separate from the persistent HERMES_HOME state directory.

Quick Answer

Use a VPS for Hermes Agent when the agent needs to stay online, receive messages, run scheduled automations, keep project memory, or act as a shared workspace for more than one device. Start with one trusted gateway, one dedicated Linux user, a private configuration folder, backups for memory and skills, and manual approval for destructive work. For long-running agent infrastructure, a VPS hosting plan gives Hermes a fixed Linux boundary instead of tying agent state to a personal laptop.

Why Hermes Needs A Different VPS Plan

Installing the tool and selecting a model provider are only the start. Hermes also needs persistent state and an explicit operating boundary. The NousResearch Hermes Agent repository describes persistent memory, scheduled automations, subagents, gateway integrations, terminal backends, skills, and migration paths from OpenClaw. Those features change the infrastructure decision.

A stateless chatbot can fail and restart without losing much. Hermes is different. Once it starts building memory, skills and recurring workflows, the server becomes part of the product. Bad file permissions, missing backups or an exposed gateway are no longer small mistakes. They affect what the agent remembers, who can instruct it, what it can execute, and how easy it is to recover after a bad deployment.

Before Hermes becomes an always-on assistant, decide what must remain stable, private and reviewable: its application release, persistent state, gateway allowlist and permitted tools.

What Already Exists On Voxfor And What Hermes Adds

Use the related guides below for background; use this page for Hermes-specific deployment and state ownership.

Existing Voxfor topic	What it likely answers	Hermes-specific operational concern
AI agents on VPS	General reason to host agents on persistent infrastructure	Hermes memory, skills, gateways and recurring work
How to run an AI agent on a VPS	Generic VPS setup logic for agents	Hermes-specific folders, approvals and deployment order
OpenClaw VPS setup	OpenClaw gateway, workspace and operations	Migration angle and differences in Hermes behavior
Host MCP server on VPS	Private tool/API server hosting	How Hermes should consume tools without exposing every endpoint
VPS specs for Ollama/local LLMs	Model and hardware sizing	When Hermes is light because models are external, and when local inference changes the plan

These components solve different operational problems: Hermes keeps persistent agent state and gateway workflows; n8n manages workflow queues; Ollama supplies local inference; MCP exposes approved tools. Deploy only the components the workload actually needs.

When Hermes Fits A VPS

Hermes fits a VPS when the workload has to continue after your laptop is closed. That includes messaging assistants, client-report automations, scheduled audits, long-running research, private tool access, or a small team using one agent workspace.

Three examples make the decision clearer:

Scenario	VPS fit	Why
Solo operator using Hermes from Telegram or CLI	Good	One stable server keeps memory, logs and credentials in one controlled place
Agency assistant preparing recurring client reports	Good	Scheduled work, browser runs, screenshots and logs need uptime and backup
Team agent with multiple people sending tasks	Possible	Works only with access rules, ownership, retention and approval boundaries
Weekend experiment with no real credentials	Local first	Faster to learn locally before paying operational cost
Heavy local LLM inference	Depends	Hermes may be light, but the model may require GPU or much larger RAM

VPS hosting makes the most sense when Hermes is API-based and the server hosts state, tools and gateways. If the model runs locally, size the server for the model first. If the agent only needs one short experiment, local testing is cleaner.

Recommended VPS Baseline

For an API-based Hermes deployment, the first server does not need to be huge. Browser automation, logs and supporting services are usually heavier than the agent process.

Workload	Starting point	Notes
CLI testing and one gateway	2 vCPU / 4 GB RAM / 50 GB NVMe	Enough for early validation and light scheduled work
Browser automation and screenshots	4 vCPU / 8 GB RAM / 80-120 GB NVMe	Headroom helps with Chromium, logs and failed-run evidence
Client or team workflows	4-8 vCPU / 8-16 GB RAM / 120+ GB NVMe	Better for queues, backups, multiple tools and parallel tasks
Hermes with Open WebUI or vector search	8+ GB RAM, NVMe storage	Size for the extra services, not only for Hermes
Hermes with local LLM inference	Model-dependent	CPU VPS can test small models; serious inference usually needs GPU

Recommended baseline: start with 4 vCPU, 8 GB RAM and NVMe storage if the agent will use browser automation, scheduled tasks or more than one integration. Start smaller only when the deployment is clearly a lab.

A Safe Hermes VPS Architecture

A practical Hermes setup should separate six things:

1. The Linux user that runs the agent.
2. Memory and workspace files.
3. Skills and reusable workflows.
4. Gateway access from Telegram, Discord, Slack, WhatsApp, Signal or CLI.
5. Tool execution, browser profiles and terminal backends.
6. Secrets for model providers, APIs and private services.

Keep that separation visible in the file structure. A simple layout can look like this:

/opt/hermes/
  app/              # pinned Hermes source checkout
  state/            # HERMES_HOME: persistent user data
    config.yaml     # model, tools and gateway configuration
    .env            # private provider/gateway credentials (mode 0600)
    memories/       # persistent memory
    skills/         # reviewed reusable skills
    cron/           # schedules
    sessions/       # conversation history
    logs/           # runtime logs
  .local/bin/hermes # installer-managed launcher
  backups/          # protected local staging before off-server copy

Avoid putting .env files, memory exports or gateway tokens in a web-accessible directory. Do not run Hermes as root. Do not mix client data, experiments and production credentials in one folder.

Service, Firewall And Access Pattern

For a first VPS, use a dedicated Linux user and one process manager. Systemd is usually enough. Docker Compose can be fine when Hermes or its gateways ship clean containers, but do not add Docker just to look modern.

High-level service pattern:

linux user: hermes
working directory: /opt/hermes/app
persistent state: HERMES_HOME=/opt/hermes/state
launcher: /opt/hermes/.local/bin/hermes
restart policy: restart on failure
logs: journalctl plus /opt/hermes/state/logs
network: only explicitly required gateway routes

Firewall pattern:

• Keep SSH limited to trusted IPs or VPN where possible.
• Expose only the gateway endpoint that must receive traffic.
• Put dashboards behind VPN, SSH tunnel, reverse proxy authentication or IP allowlists.
• Use HTTPS when any gateway or callback endpoint is public.
• Keep database, vector store, internal APIs and admin tools private.

Do not expose these endpoints directly: raw admin dashboards, terminal backends, memory browsers, skill editors, local databases, model-provider keys, browser-debug ports, webhook test consoles, backup directories, and anything that can run shell commands.

Example Linux Baseline

The example below targets Hermes v0.21.7, source commit 71d34bad1045610252eda02ee79549436896e784. The installer flags, launcher, state layout and gateway run command were checked against that release source. This is a deployment template, not a claim that a real provider or messaging account was connected in this repair. Start on a fresh Linux service account with Git, curl, tar, less and SHA-256 utilities available; the administrator must supply required distribution libraries.

Start with the Linux user and directory layout:

set -euo pipefail
if id hermes >/dev/null 2>&1; then
  echo 'Refusing an existing service account; review migration separately' >&2
  exit 1
fi
sudo test ! -e /opt/hermes
sudo test ! -L /opt/hermes
sudo adduser --system --group --home /opt/hermes hermes
sudo install -d -o hermes -g hermes -m 0700 /opt/hermes/state /opt/hermes/backups
sudo chmod 750 /opt/hermes
# Refuse to reuse an existing application checkout.
sudo test ! -e /opt/hermes/app
sudo -u hermes -H bash <<'HERMES_INSTALL'
set -euo pipefail
export HERMES_HOME=/opt/hermes/state
HERMES_COMMIT=71d34bad1045610252eda02ee79549436896e784
INSTALL_SCRIPT=$(mktemp /opt/hermes/hermes-install.XXXXXX)
trap 'rm -f -- "$INSTALL_SCRIPT"' EXIT
curl -fsSL "https://raw.githubusercontent.com/NousResearch/hermes-agent/$HERMES_COMMIT/scripts/install.sh" -o "$INSTALL_SCRIPT"
# Review the pinned upstream script before continuing.
less "$INSTALL_SCRIPT"
bash "$INSTALL_SCRIPT" --commit "$HERMES_COMMIT" --dir /opt/hermes/app \
  --hermes-home "$HERMES_HOME" --non-interactive --skip-browser --skip-computer-use
test "$(git -C /opt/hermes/app rev-parse HEAD)" = "$HERMES_COMMIT"
test -x /opt/hermes/.local/bin/hermes
/opt/hermes/.local/bin/hermes --version
HERMES_INSTALL

Configure the provider and one gateway interactively as the same service account. The installer creates /opt/hermes/state/.env with private permissions; do not put keys into shell arguments or logs. Set the gateway allowlist before starting a persistent listener:

sudo -u hermes -H env HERMES_HOME=/opt/hermes/state /opt/hermes/.local/bin/hermes setup
sudo -u hermes -H env HERMES_HOME=/opt/hermes/state /opt/hermes/.local/bin/hermes gateway setup
sudo -u hermes -H chmod 600 /opt/hermes/state/.env
sudo -u hermes -H env HERMES_HOME=/opt/hermes/state /opt/hermes/.local/bin/hermes doctor

The service uses the same persistent data directory as the setup wizard; model and gateway values belong in Hermes configuration, not invented environment-variable names. Confirm these paths and permissions before enabling the unit:

sudo -u hermes -H test -r /opt/hermes/state/config.yaml
sudo -u hermes -H test -r /opt/hermes/state/.env
sudo stat -c '%a %U:%G %n' /opt/hermes/state /opt/hermes/state/.env

This systemd unit starts the real foreground gateway command through the release installer’s launcher. Save it as hermes.service. Do not also install a Hermes-managed user service for the same state directory; one supervisor must own the gateway:

[Unit]
Description=Hermes Agent gateway (v0.21.7)
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=hermes
Group=hermes
WorkingDirectory=/opt/hermes/app
Environment=HERMES_HOME=/opt/hermes/state
Environment=PATH=/opt/hermes/.local/bin:/usr/local/bin:/usr/bin:/bin
ExecStart=/opt/hermes/.local/bin/hermes gateway run
Restart=on-failure
RestartSec=5
UMask=0077
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full
ProtectHome=true
ReadWritePaths=/opt/hermes

[Install]
WantedBy=multi-user.target

Install and check the service:

sudo install -o root -g root -m 644 hermes.service /etc/systemd/system/hermes.service
sudo systemd-analyze verify /etc/systemd/system/hermes.service
sudo systemctl daemon-reload
sudo systemctl enable --now hermes
sudo systemctl status hermes --no-pager
sudo journalctl -u hermes -n 80 --no-pager

For firewall rules, open only what the deployment actually needs. SSH should be limited to trusted access where possible, and dashboards should stay behind a VPN, tunnel or reverse proxy authentication:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verbose

If a public webhook is required, expose only that specific port or reverse-proxy route. Do not open browser-debug ports, local databases, raw terminal services or private dashboards to the internet.

Deployment Path That Gives Value

Start narrow. Hermes should earn each new permission.

1. Provision the VPS and update packages.
2. Create a hermes Linux user with no unnecessary sudo access.
3. Create /opt/hermes and its private state directory with strict ownership.
4. Install the pinned official release and confirm its commit, launcher and CLI first.
5. Configure one model provider through the setup wizard under HERMES_HOME=/opt/hermes/state.
6. Run the agent through systemd or a simple supervised process.
7. Add one gateway only, such as Telegram or Discord.
8. Allow one trusted user and block unknown senders.
9. Create one harmless scheduled task, such as a daily status note.
10. Confirm logs, restart behavior and backup coverage.
11. Add browser automation, MCP tools or shell actions only after the base agent is predictable.

This order gives useful debugging signals. If CLI works but the gateway fails, the issue is not the model provider. If the gateway works but cron fails, check scheduling and environment variables. If a tool fails, inspect permissions before giving the agent broader access.

Approval Rules Before Real Work

Hermes should not receive production-level authority on day one. A good approval model is simple:

Action type	Default rule
Read public pages	Allow
Read local project files	Allow only in approved directories
Write notes or draft files	Allow in workspace folders
Send messages externally	Require approval unless channel is explicitly trusted
Run shell commands	Require allowlist and logs
Change production systems	Require manual approval
Rotate or view secrets	Human-only
Publish content	Human approval or a separate publishing workflow

This is not about slowing the agent down. It prevents one bad instruction from turning a helpful assistant into a server-side process with too much reach.

Memory, Skills And Backups

Hermes memory and skills are not temporary cache. They are part of the agent’s operating history. Back them up like application data.

Back up:

• Memory files and long-term notes.
• Skill directories or generated playbooks.
• Gateway configuration that is safe to store.
• Cron or scheduled-task definitions.
• Custom scripts and prompts.
• Review logs for actions that touched real systems.

Do not back up plaintext secrets into shared folders. Keep secrets in a protected environment file, secret manager or root-owned path. If a key appears in logs, screenshots or chat history, rotate it.

Review a generated skill before making it reusable. Check its tools, writable paths, external recipients and approval requirements; reject instructions that expose private files or silently broaden production access.

Hermes, OpenClaw And Migration

Hermes and OpenClaw have separate configurations and state ownership. Treat a move between them as a migration, not as permission to reuse every existing integration.

Inventory the source workspace, gateway settings, skills and schedules, then map only the required items into Hermes memory, gateway channels, terminal backend and tool configuration.

Migration is the useful bridge. If a team already runs OpenClaw-style workflows, Hermes should not simply inherit every old directory and permission. Treat migration as a review:

• Which memories should be imported?
• Which skills are still valid?
• Which secrets should be rotated instead of copied?
• Which cron jobs are still needed?
• Which gateways should start disabled?
• Which tool permissions were too broad?

Keep the old workspace available until imported state, gateway access and one harmless scheduled task have been checked in the new deployment.

Hermes Versus Local Install Versus Managed Cloud

Option	Use it when	Avoid it when
Local install	You are learning Hermes or testing one workflow	The agent must run while your machine is offline
VPS	You need persistence, gateways, cron, logs and private control	You cannot maintain Linux, updates, secrets and backups
Managed cloud	You need a quick proof of concept or team convenience	You require full control over files, memory, gateways and audit trails
GPU server	You need local model inference	The agent only calls external APIs

For many Hermes users, a VPS is the middle path: more durable than a laptop, more controllable than a black-box hosted demo, and less expensive than GPU infrastructure when the model runs through APIs. The Hermes self-hosting path should still be checked against the current official self-hosting documentation before any production deployment.

How Voxfor Can Connect The Stack

Hermes can sit beside other private AI infrastructure:

• AI agents on VPS for the broad server-side agent model.
• OpenClaw on VPS for OpenClaw-specific workspace deployment.
• MCP server hosting for private tool/API surfaces.
• VPS specs for Ollama when local model inference enters the plan.

Use MCP for narrowly permissioned tool endpoints and Ollama only when local inference is required. Keeping those services separate makes their resource and access boundaries easier to inspect.

Strengths And Practical Gaps

This Hermes VPS approach has a clear security advantage: it warns against running agents as root, separates secrets from public folders, and treats gateways as control surfaces rather than harmless chat inputs. That matters because a self-hosted agent can receive instructions, call tools, write files and trigger scheduled work.

Segmentation is another useful part of the plan. A VPS makes sense when Hermes needs uptime, gateways, memory, logs and scheduled work. A local install is still better for early experiments, and managed cloud can be better for a fast proof of concept. Choose the deployment boundary that matches the workload rather than putting every experiment on an always-on server.

Release upgrades are a new change. Recheck the upstream release notes, installer flags, launcher and gateway run behavior before moving away from this pin. Preserve the persistent state directory, verify CLI and gateway acceptance, and schedule the update deliberately rather than changing the service command to a floating release.

After startup, send one harmless message from an allowed gateway user, confirm an unknown sender is refused, and inspect journalctl -u hermes plus /opt/hermes/state/logs. Restart the service once and confirm that memory and the approved schedule persist. The unit restrictions can limit tools that need broader filesystem access; adjust only the specific tool requirement after review.

Recommended Next Step

If Hermes is still experimental, start locally or on a small private VPS with one gateway and one harmless scheduled task. If it will become a daily workspace, plan the server around memory, skills, logs, browser tasks, backups and approval rules before adding real credentials. The safest first production step is not a bigger server; it is a narrower permission model that can grow only after the base setup behaves predictably.

FAQ

Can Hermes Agent run on a VPS?

Yes. Hermes can run on a VPS when it needs persistent memory, gateway access, scheduled automations, skills and tool execution. Secure the server before giving the agent real credentials or production access.

How much RAM does Hermes need on a VPS?

API-based use can start around 4 GB RAM, but browser automation, screenshots, parallel tasks and extra services need more. For daily work, 8-16 GB RAM is a more practical range.

Should Hermes run as root?

No. Run Hermes under a dedicated Linux user, keep secrets outside public folders, and give the agent access only to the directories and tools it needs.

Is Hermes the same as OpenClaw?

No. Both can support self-hosted agent workflows, but Hermes has its own memory, skills, gateway channels, terminal backend and Nous Research ecosystem. Review state compatibility and permissions before migrating between them.

Should the Hermes gateway be public?

Usually no. Keep control surfaces private or protected with HTTPS, authentication, IP allowlists, VPN or SSH tunneling. A public webhook may be needed, but dashboards and terminal access should stay private.

Can Hermes use MCP servers on the same VPS?

Yes, but keep MCP endpoints private and permissioned. Hermes should consume approved tools, not receive unrestricted access to every internal API on the server.