Hermes Agent on a VPS

DigitalOcean publishes an official Hermes Agent 1-Click App in its Marketplace. As listed on September 26, 2026: Hermes Agent 2026.9.14 on Ubuntu 24.04, with Python 3.12.3 and the OpenAI SDK 2.24.0. It is still a self-managed Droplet — DigitalOcean preinstalls Hermes; it does not run it for you.

• Hermes is installed for a dedicated hermes user. Config is in /home/hermes/.hermes/config.yaml, keys in /home/hermes/.hermes/.env, and the workspace in /home/hermes/workspace; the install itself is under /opt/hermes/.
• The image is preconfigured for DigitalOcean Serverless Inference (https://inference.do-ai.run/v1, default model minimax-m2.5) with a DigitalOcean model access key. Run hermes model to use any other provider.
• DigitalOcean's API example creates the Droplet at size s-2vcpu-4gb (4 GiB RAM, 2 vCPUs, 80 GiB SSD; $24/month on the Basic Regular tier).

# After SSH-ing in, as the hermes user
$hermes --version         # compare with the latest release
$hermes update            # the image may lag the current release
$hermes setup             # or: hermes model
$hermes doctor
$hermes gateway setup     # only if you want messaging
$hermes gateway start

The provider-independent path. It works on any Ubuntu or Debian server, a DigitalOcean Droplet without the 1-Click image, or an always-on machine at home. The official gateway docs cover two ways to keep Hermes running after you log out — a system service, or a user service with lingering. Pick one.

Nous publishes an official image, nousresearch/hermes-agent. All state — config, API keys, sessions, skills, memories — lives in one host directory mounted at /opt/data; the image itself is stateless, so upgrading means pulling a newer image. This is orientation only; the official Docker guide covers profiles, the dashboard, and logs, and our Docker page covers storage, ports, and update pitfalls.

$docker run -it --rm -v ~/.hermes:/opt/data nousresearch/hermes-agent setup

services:
  hermes:
    image: nousresearch/hermes-agent:latest
    container_name: hermes
    restart: unless-stopped
    command: gateway run
    volumes:
      - ~/.hermes:/opt/data

• Upgrade: docker compose pull, then docker compose up -d. Running gateways come back up after a restart or upgrade.
• Never point two gateway containers at the same data directory — the docs warn that session and memory stores are not built for concurrent writers.
• On Docker Desktop for macOS or Windows, bind mounts can corrupt the session database under concurrent access; on a Linux VPS a normal bind mount or named volume is fine.

Hermes has no single official VPS size requirement. Neither the installation docs nor the Docker guide state a minimum CPU, RAM, or disk figure. What exists are a few documented anchors — useful as reference points, not requirements:

What pushes the size up: browser automation, many concurrent sessions or profiles, the dashboard, and above all local models, which need hardware sized for the model rather than for Hermes. With an API or Portal model the model runs elsewhere and the server only runs the agent.

Everything that makes your agent yours — config, API keys, memories, skills, sessions, profiles — is in the Hermes data directory (~/.hermes/, or /opt/data in Docker). The install itself can be recreated.

# Old server
$hermes backup                                  # writes ~/hermes-backup-<timestamp>.zip
$scp ~/hermes-backup-*.zip newserver:~/
$
# New server, after installing Hermes
$hermes import ~/hermes-backup-<timestamp>.zip
$hermes setup                                   # confirm keys and provider

• The full backup skips downloaded models, runtimes, and browser profiles, and reports files it could not copy — read that report before deleting the old server.
• The zip contains your API keys. Store it like a password file.
• Stop the gateway on the old server before starting it on the new one, so two gateways don't answer the same bots.

Restore details, quick snapshots, and Docker-specific steps: Hermes backup and restore.