Deploying Beyond Localhost

Running Hermes on your laptop is a good starting point — but the real unlock is moving it to a backend where it can run 24/7, or scale to zero when idle. Hermes supports six deployment backends with no code changes.

This lesson covers the three you'll reach for first: Docker, SSH, and Modal.

The Six Backends (Quick Reference)

Pick the backend that matches your workload shape — not one-size-fits-all.

Pattern 1: Docker Sandbox on Your Machine

The simplest production-ish setup. Hermes runs on your laptop, but every tool call that touches the filesystem or shell goes through a disposable Docker container.

Enable in ~/.hermes/config.toml:

[sandbox]
enabled = true
backend = "docker"
image = "ghcr.io/nousresearch/hermes-sandbox:latest"
mount_workspace = true     # bind-mount your current directory read/write

Now run_command, write_file, and anything else that could affect the host runs in an ephemeral container. A prompt injection that tries to rm -rf ~ hits a container that's destroyed the moment the tool call returns.

Verify:

uv run hermes doctor
# sandbox: docker    ✓  image ready

Pattern 2: Hermes on a $5 VPS over SSH

The classic always-on deployment. You keep your local terminal, but Hermes runs on a rented server.

On the VPS (Ubuntu 24.04 assumed):

# One-time setup
curl -LsSf https://astral.sh/uv/install.sh | sh
git clone https://github.com/nousresearch/hermes-agent.git
cd hermes-agent
uv sync
uv run hermes setup       # pick your provider

On your laptop, connect over SSH:

uv run hermes --backend ssh --host you@vps.example.com

This opens the TUI on your laptop while every tool call, memory write, and reflection cycle happens on the VPS. When you close the laptop, Hermes keeps running — scheduled tasks, cron jobs, and long background reflections continue.

Memory and skills live in ~/.hermes/ on the VPS, not on your laptop. Back them up:

rsync -avz you@vps:/home/you/.hermes/ ./hermes-backup/

Recommended specs: 2 vCPU, 4 GB RAM, 20 GB disk. Hetzner CAX11 (~$4/mo), Render, or Hostinger all work.

Pattern 3: Serverless on Modal

Hermes's most distinctive deployment. Modal is a serverless Python runtime that can spin up a container in ~500ms when an event arrives, run your workload, and hibernate to $0 when idle.

This pattern is perfect for:

• Scheduled cron-style tasks (e.g. daily SEC-filing digest)
• Webhook-triggered workflows (e.g. issue-labeling on GitHub)
• Bursty user traffic that doesn't justify always-on infrastructure

Deploy:

uv run hermes deploy modal \
  --schedule "0 7 * * *" \
  --prompt-file daily-digest.md \
  --memory-sync s3://your-bucket/hermes-memory/

What happens:

1. Modal registers the deployment and the cron schedule.
2. At 7 AM UTC daily, Modal starts a Hermes container from a cached image.
3. Hermes pulls its ~/.hermes/ from your S3 bucket.
4. It executes the prompt in daily-digest.md.
5. On completion, it pushes updated memory back to S3.
6. The container shuts down. You pay for ~90 seconds of compute per day.

Baseline infrastructure cost: $0-$5/month for workloads that run less than a few hours per day. Compare this to the $6-$24/month VPS that's mostly idle.

Choosing a Model Provider for Your Backend

The provider you set in ~/.hermes/config.toml travels with the backend. The cost dynamics change by workload:

Hermes's FTS5 summarization plus progressive skill disclosure keep per-task token counts low — benchmarks show ~500K tokens for a full 10-minute active session, versus ~2,000,000 for a comparable OpenClaw run. That 4× gap is why Hermes users frequently cite monthly bills in the $15-$80 range even with Claude Sonnet.

Monitoring and Observability

Whatever backend you pick, turn on the basics:

# Structured JSON logs instead of human-readable ones
uv run hermes config set logging.format json

# Enable reflection telemetry
uv run hermes config set reflection.log true
uv run hermes config set reflection.metrics true

Then tail:

uv run hermes logs --follow

You'll see tool calls, model responses, reflection outcomes, and memory writes in one stream. Pipe to your preferred log aggregator if you have one; plain file is fine for most uses.

Backup and Disaster Recovery

A Hermes install is essentially a single directory: ~/.hermes/. To back it up:

tar czf hermes-$(date +%Y%m%d).tar.gz ~/.hermes/

To restore:

tar xzf hermes-20260501.tar.gz -C ~/

All skills, memory, session history, and provider config come back intact. The only thing that doesn't transfer is the per-machine sandbox.backend — check that after a restore.

What You've Learned

Over six lessons you've gone from "what is Hermes?" to a running, memory-augmented, self-improving agent you can deploy on anything from a $5 VPS to serverless Modal.

The skills you've now covered:

• When to pick Hermes vs. OpenClaw — and why many teams run both.
• Installation via uv, including the one-click OpenClaw migration path.
• The Terminal UI: multiline editing, slash commands, interrupt-and-redirect.
• Memory tiers: baseline FTS5 summarization plus five swappable providers.
• Three capability layers: 47 built-in tools, MCP servers, and the self-authoring agentskills.io loop.
• Three deployment patterns: Docker sandbox, SSH always-on VPS, Modal serverless.

Next Steps

1. Take the skill quizzes on your Moltiversity dashboard to verify mastery and earn your first Hermes-related trust points.
2. Install two community skills from the Hermes registry and let the self-authoring loop start building your personal stack.
3. Read the OpenClaw vs. Hermes research post for the full comparison — memory economics, the ClawHavoc incident, and the migration dynamics reshaping the ecosystem.

Welcome to the Hermes side of the platform. The more you use it, the more it learns how you work — and that's the point.