Deutsch
VPS plan
Starter VPS Includes 3 CPU cores, 6 GB RAM, 50 GB NVMe storage, Unlimited bandwidth*, 1 free snapshot, 1 backup included, IPv4 + IPv6, Full root access.
How to Self-Host Hermes Agent on a VPS
This guide shows how to self-host Hermes Agent on a Virtarix VPS with SSH, a private runtime workspace, upstream installation commands, gateway service options, firewall basics, logs, snapshots, and rollback checks. Virtarix provides the VPS infrastructure. You install, configure, secure, update, and operate the software you run on it. Virtarix VPS plans provide NVMe storage, full root access, available server locations, IPv4/IPv6, and an always-on server environment; you bring and maintain your own Hermes Agent install, provider accounts, API keys, repositories, tools, channel credentials, and configuration.
20% welcome offer
$4.40/mo for first 3 months (then $5.50)
Hermes Agent Control Panel
Gateway Online
root@hermes-vps:~$ hermes gateway --vps --monitor
> ✓ Hermes Agent gateway online. Logs streaming.
Hermes Ready
Hermes Runtime Agent workspace
Gateway Service Channel bridge
Model Config Provider settings
Tool Access Reviewed actions
Protected Keys Private env files
Live Logs Gateway output
tmux Session Persistent shell
Snapshots + Backups Recovery point
Recommended Quick Setup
Use this path when you want the shortest practical route from VPS order to a usable Hermes Agent server workspace. The full checklist below expands each step and keeps the self-managed responsibilities clear.
Who This Guide Is For
This page is for users who want Hermes Agent to run from a controlled VPS environment instead of relying on a local desktop session, while keeping the Hermes Agent software layer self-managed.
Operators testing persistent AI workflows
Use a VPS when workflow state, logs, and runtime continuity matter.
Builders connecting messaging or tool integrations
Keep integrations, provider access, repositories, and tool configuration on a server you control.
Teams that need server-side logs and scheduled tasks
Move scheduled work and troubleshooting context away from individual workstations.
Users comfortable maintaining Hermes Agent themselves
Virtarix provides the VPS infrastructure. You install, configure, secure, update, and operate the software you run on it.
What You Need Before You Start
Before selecting a plan or installing Hermes Agent, confirm the server access, runtime path, credentials, firewall exposure, and recovery routine needed for the deployment.
Use a Linux VPS suitable for the selected Hermes Agent installer, development clone, Docker backend, or gateway path, with SSH access and root or sudo access ready.
Have basic terminal knowledge, Git, and the package managers required by the selected Hermes Agent installation path.
Add Docker only when using the documented container terminal backend or a deployment path that explicitly calls for containers.
Prepare your own API keys, provider accounts, model access, repositories, runtime configuration, and any channel credentials before connecting the agent.
Set domain and firewall rules for exposed interfaces or webhooks, and take backups or snapshots before production changes or major upgrades.
Choose the Hermes Agent Runtime Path
Before running commands, decide how Hermes Agent should be installed, updated, restarted, and recovered on the VPS. Use current upstream documentation as the authority for exact versions and flags.
Recommended VPS Requirements
Minimum starting point for a test environment:
Recommended Architecture
The VPS is the runtime layer. You connect over SSH, configure Hermes Agent, and control logs, state, and access. Review the Hermes Agent VPS hosting page before moving to production use.
You (Operator)
You connect over SSH and control the full workflow, configuration, security, and updates.
Virtarix VPS
Provides the persistent server with storage, networking, root access, snapshots, and backups.
Hermes Agent Runtime
Installer, CLI, models, tools, gateway, memory, skills, and logs running on the VPS.
External Services
API and model providers, repositories, tools, webhooks, and scheduled jobs you enable.
Step-by-Step Setup Flow
Follow this sequence as a practical deployment checklist, but confirm Hermes Agent-specific versions, installer flags, gateway commands, and service options against current official documentation before production use.
Prepare the VPS, connect over SSH, and create a clean workspace before installing Hermes Agent-specific dependencies.
Choose Ubuntu or another Linux distribution supported by Hermes Agent. Select the location closest to the user, app, API provider, or team where practical, and start with enough CPU, RAM, and storage for persistent background work. For Starter VPS pricing, use 20% off your first 3 months - normally $5.50/month. Confirm bandwidth terms at checkout. Each VPS/VDS plan includes 1 free snapshot and 1 backup.
Use the root login for the first bootstrap only, then continue as a sudo-capable non-root user where practical.
ssh root@YOUR_SERVER_IPsudo apt update && sudo apt upgrade -yCreate a dedicated non-root deployment user for day-to-day project work, then verify that user can connect by SSH and run sudo before disabling root or password login. Reconnect as the deployment user before installing or configuring the agent when your selected runtime path stores user-scoped configuration.
# Create a dedicated non-root user for day-to-day project work
adduser deploy
usermod -aG sudo deployCreate one directory tree for Hermes Agent config examples, working files, logs, and backups. Keep secrets out of shell history and commit only templates, not real keys.
APP_HOME="$HOME/self-host-hermes-agent-on-vps-runtime"
mkdir -p "$APP_HOME/config" "$APP_HOME/workspace" "$APP_HOME/logs" "$APP_HOME/backups"
chmod 700 "$APP_HOME/config"
printf '%s\n' "# add real provider keys privately" > "$APP_HOME/config/env.example"
chmod 600 "$APP_HOME/config/env.example"Install base packages, follow the current upstream install path, and configure runtime/environment settings.
sudo apt install -y git curl wget unzip ca-certificates gnupg tmux ufwThe official Hermes Agent docs list a one-line CLI installer, setup through hermes setup, model selection through hermes model, tool configuration through hermes tools, gateway service commands, command approval, DM pairing, and container-isolation guidance. Use official Hermes Agent documentation to confirm exact versions and flags before relying on the server setup.
Review the current upstream installer before running remote shell commands in production environments, especially when piping a downloaded script into bash.
# Official Hermes Agent installer path from the current upstream README
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
source ~/.bashrc # or source ~/.zshrc
hermes setup
hermes model
hermes tools
hermes doctorFor Hermes Agent, use the setup, model, tools, and config commands exposed by the CLI before editing files directly. Store provider credentials and gateway settings only through the configuration flow documented for your selected runtime path, and keep real secrets out of copied examples.
hermes setup
hermes model
hermes tools
hermes config set <KEY> <VALUE>
hermes doctorStart with an interactive CLI test, then enable the messaging gateway only if you have configured a supported channel and access controls. Choose either a foreground run, a user service, or a system service; do not run duplicate gateway services unless you intentionally configured separate profiles.
# Interactive CLI test
hermes
hermes doctor
# Messaging gateway setup and foreground run
hermes gateway setup
hermes gateway
# User-level service path
hermes gateway install
hermes gateway start
hermes gateway status
journalctl --user -u hermes-gateway -f
# Boot-time VPS service path on Linux
sudo hermes gateway install --system
sudo hermes gateway start --system
sudo hermes gateway status --system
journalctl -u hermes-gateway -fKeep the selected Hermes CLI, gateway, or automation mode observable, lock down access, test the setup, and plan ongoing maintenance.
Use the process-management path that matches the runtime you selected. For a CLI-only workflow, use tmux or screen when you want a resilient interactive terminal. For a messaging gateway or scheduled automation, verify the exact gateway or worker command first, then use the documented Hermes gateway service commands, systemd, supervisor, or a documented container backend when appropriate.
tmux new -s hermes
hermes doctor
hermes gateway statusUse SSH keys where possible, restrict password login if appropriate, enable a firewall, expose only the ports Hermes Agent actually needs, protect ~/.hermes/.env, config.yaml, gateway allowlists, and provider credentials, keep packages updated, and use backups or snapshots before major changes. Before sudo ufw enable, confirm your SSH rule matches the port you are using or keep provider console access open so you do not lock yourself out. Replace OpenSSH with your custom SSH port rule if you changed the SSH port.
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH # replace if your SSH port or app profile is different
sudo ufw status verbose
sudo ufw enable
sudo ufw status verboseWhy Hermes Agent Benefits from a VPS
Hermes Agent can involve skills, memory, provider settings, messaging gateways, scheduled tasks, command approvals, and server-side logs. A VPS keeps those moving parts in one controlled runtime.
Persistent runtime
Keep Hermes Agent running in an always-on remote environment instead of tying it to a local desktop session.
Logs and state on the server
Keep runtime state, logs, credentials, repositories, and operational context in one controlled place.
Background and scheduled tasks
Support persistent background workflows, scheduled tasks, and service restarts over time.
Centralized control
Document every provider, toolset, approval rule, and messaging gateway you enable. Start narrow and expand after logs, credentials, and service restarts are understood.
Security Basics for Hermes Agent on a VPS
Use SSH keys where possible and store private keys outside the VPS.
Keep root login limited after bootstrap.
Use a non-root user where practical.
Restrict ports to SSH and the specific gateway, webhook, or supporting service ports you intentionally expose.
Store secrets through the documented Hermes configuration flow, environment variables, or a secret manager, and avoid pasting live credentials into examples, tickets, or shared logs.
Avoid committing .env, provider keys, repository tokens, gateway tokens, memory files, or channel credentials.
Review SSH logs, Hermes gateway access, provider-key usage, tool approvals, skill changes, memory/config files, and channel authentication settings.
Keep OS packages and Hermes Agent dependencies updated through the selected upstream path.
Snapshot before major Hermes Agent changes and record a rollback point.
Monitor failed login attempts and unexpected gateway access.
Rotate exposed or unnecessary keys immediately.
Keep experiments separate from production systems.
Privileged runtime
The server can contain provider config, messaging gateways, approval settings, secrets, repositories, tool access, and runtime memory. Harden it before production use and avoid granting broad tool permissions until you have reviewed logs, access controls, provider-key scope, and rollback behavior.
Troubleshooting
Common setup problems to check before blaming the VPS or framework.
Server firewall, wrong IP, or SSH service unavailable
Confirm the VPS is running, check the IP, and verify port 22 or your configured SSH port.
Wrong key, wrong user, or disabled login method
Check ~/.ssh/authorized_keys, user permissions, and your SSH config.
Base packages or runtime packages were not installed Re-run the dependency step and compare runtime versions with the official Hermes Agent docs.
The selected Hermes Agent path expects a different runtime or installer dependency version Use the version manager or package source recommended by upstream docs.
Docker daemon stopped or not installed This only applies if you selected the Docker backend; otherwise inspect the Hermes CLI, gateway, or terminal-backend logs for the selected path.
Hermes gateway or CLI was started from an interactive shell
Verify the gateway command and channel configuration first, then run that reviewed command through tmux, the documented Hermes gateway service path, systemd, supervisor, or Docker only when appropriate.
A selected Hermes Agent gateway, messaging integration, webhook, or supporting tool is bound to a port already used by another process
Run ss -tulpn and move one service to a different port.
A required Hermes Agent gateway, messaging integration, webhook, or supporting tool port is not open Open only the required port and keep all other ports restricted.
Configuration is absent or incomplete Compare the generated configuration with the selected deployment path and add only the secrets and paths required.
Key is wrong, expired, or lacks access Rotate the key through the provider and update the server configuration.
Logs, caches, or repositories grew over time
Check df -h, rotate logs, clean caches, and scale storage if needed.
Too many gateway sessions, terminal backends, tool calls, or background tasks Reduce concurrency, inspect process memory, and scale the VPS if the workload is valid.
When This Setup Is Not Necessary
Local testing is enough
You may not need a VPS if you are only testing Hermes Agent locally, working from one private machine, reviewing a small repository, or experimenting without persistent SSH access.
Server management may be unnecessary
This setup is not ideal if you do not want to manage Linux updates, SSH access, firewall rules, disk usage, credentials, or repository permissions yourself.
Use a VPS for persistent remote state
Use a VPS when the workspace, memory state, logs, tools, and agent workflow should stay available in a controlled remote environment.
Ready to run Hermes Agent on an always-on VPS?
Deploy a self-managed Hermes Agent VPS, confirm the current plan terms at checkout, and use this guide as your setup, security, log-review, and rollback checklist.
FAQ
Can I run Hermes Agent on a VPS?
Yes, if the Hermes Agent release supports the Linux distribution and runtime path you choose. Use this guide together with the current official documentation.
Do I need a GPU VPS for Hermes Agent?
Not for the VPS runtime pattern described here. This Hermes Agent guide focuses on the CLI, messaging gateway, provider access, skills, memory, scheduled tasks, approval settings, and server-side logs; verify separate hardware needs if you plan local model inference.
Does Virtarix provide API keys or model access?
No. Bring your own provider accounts, credentials, API keys, model access, repositories, and framework configuration.
What VPS size should I use for Hermes Agent?
Start Hermes Agent with the recommended Virtarix Starter VPS for a practical first deployment, then scale after measuring CPU, RAM, storage, process count, enabled skills, memory usage, provider config, messaging gateways, and approval settings. The Starter VPS includes 3 CPU cores, 6 GB RAM, 50 GB NVMe storage, unlimited bandwidth, IPv4/IPv6, full root access, 1 free snapshot, and 1 backup included.
Can Hermes Agent keep running without my local machine?
Yes, for the selected runtime mode. The VPS can keep Hermes skills, memory, provider config, gateway settings, and approval rules available without your local desktop staying online; use
tmux or screen for interactive work and the documented hermes gateway install and hermes gateway start path only for gateway or automation commands that are meant to persist.
Can I use Docker for this setup?
Use Docker when you intentionally select Hermes Agent’s documented Docker terminal backend or another deployment path that explicitly calls for containers. Otherwise use the standard installer, CLI, gateway, and configuration paths.
Is Virtarix operating Hermes Agent for me?
No. Virtarix provides the VPS infrastructure. You install, configure, secure, update, and operate the software you run on it.