VPS
1. VPS — Putting Hermes on Your Own Infrastructure, Running 24/7
This is the most foundational chapter in the entire handbook: everything discussed in chapters 10, 11, 16, 17 — skills, integrations, content, business workflows — is only truly “always on” when Hermes runs on a server that never goes down, not on a personal laptop that loses the connection the moment you close the lid.
This chapter is about infrastructure — server, privileges, network, backups. Actually installing Hermes onto that infrastructure (installer, Docker, dependencies, systemd service) belongs to chapter 2.
Recommended configuration: a 4GB RAM VPS
This is a sensible resource level for an agent that runs seriously — not the bare minimum to “get it running”, but enough headroom to run stably over the long term:
| Component | Why it is needed |
|---|---|
| Main gateway (Telegram/Discord/Email…) | Background process, light on resources but always resident |
| Several MCP servers at once | Each server is its own process; RAM adds up |
| Cron jobs running in the background | Schedules can overlap, creating parallel agent sessions |
| Local STT/TTS (if you choose an offline provider) | Small models, but still a few hundred MB up to 1GB+ |
| Buffer for processing large attachments (PDFs, images) | Avoids out-of-memory on sudden heavy tasks |
With 1-2GB RAM the system still runs, but it is easy to hit OOM when several MCP servers plus one heavy file-processing session collide. 4GB provides a safety margin without paying for an oversized configuration you do not need.
Docker or direct install — decide this before moving on to chapter 2
If you are comfortable with Docker, run Hermes in a container from the start instead of installing directly on the OS. The reason lies in how the infrastructure in this chapter operates:
- Natural isolation — fits the “do not run as root” principle in 1.2; a container is by itself an additional isolation layer.
- Compact backup/migration — fits 1.6; the entire state lives in a single volume.
- Clean rollback — changing versions is just changing the image tag, with no dependency conflicts against other software on the VPS.
If you are not used to Docker, a direct install is still a reasonable choice — the infrastructure principles below (dedicated user, SSH, firewall, Tailscale, backups) apply almost identically; only the concrete deployment steps differ. Each installation path is detailed in chapter 2.
The five layers to build, in strict defensive order
This is the single most important thing to grasp before diving into the sub-sections — the order is not accidental:
- Dedicated User (1.2) — limits the damage of any incident, whether you install directly or run Docker.
- SSH Access (1.3) — the only admin entry point; it must be absolutely safe.
- Firewall (1.4) — open only the ports that are truly needed, no more.
- Tailscale (1.5) — a private network layer so you do not have to open any public port at all.
- Backups (1.6) — because agent memory, skills, and configuration accumulate over time; if lost, they are truly gone.
A real incident worth remembering — why this order is not just theory
The official documentation records a real attack in June 2026: a Hermes dashboard left exposed and unauthenticated on the public internet was discovered by an automated scanner, leading to the attacker making the agent install a backdoor SSH key onto the very server. Since that incident, Hermes requires authentication on the dashboard port when bound outside loopback — the “shortcut” of skipping this step is gone, whether you run Docker or install directly. This is why the infrastructure steps in 1.2–1.5 should be completed before Hermes actually goes into operation in chapter 2 — not something done afterwards just for show.