hermes-skills/skills/devops/hermes-standby-deployment/references/hermes-dr-plan-v2.md

Hermes Disaster Recovery Plan v2

Last updated: July 9, 2026 Author: Sho'Nuff + Network Services Team Supersedes: hermes-standby-deployment skill's failover logic

---

Architecture

Core (netcup RS 2000 — 152.53.192.33)          app1-bu (Hetzner CPX21 — 5.161.114.8)
┌──────────────────────────────────┐          ┌──────────────────────────────────┐
│  Hermes Agent (active)           │          │  Hermes Gateway (dormant)        │
│  Ollama + llama3.2:3b (fallback) │◄─Tailnet─►│  Ollama + llama3.2:3b (standby)  │
│  state.db (SQLite, ~1.87 GB)     │          │  state.db (synced)               │
│  Telegram gateway (active)       │          │  Telegram gateway (off)          │
│                                  │          │                                  │
│  S3 backup every 15 min ─────────┼─────────►│  S3 sync every 5 min ◄───────────┤
│  Snapshot every 10 min ──────────┼─────────►│                                  │
└──────────────────────────────────┘          └──────────────────────────────────┘
         │                                              │
         ▼                                              ▼
  s3://hermes-vps-backups/live/
  s3://hermes-vps-backups/snapshots/     (standby pulls snapshots on change)
  s3://hermes-vps-backups/ACTIVE_OWNER   (standby writes on takeover only)

Key changes from v1:

• app1-bu upgraded from CPX11 (2C/2G) to CPX21 (4C/8G, ~$14/mo) to run its own local Ollama
• Both boxes have local Ollama (llama3.2:3b) — health checks never depend on external LLM providers
• Traffic between boxes goes over Tailscale tailnet (not public IPs), avoiding the Hetzner↔netcup routing issue
• No 60-second S3 writes from standby — all cross-box communication uses Tailscale directly
• S3 is backup storage only, not a communication channel

[Full document contents at /root/.hermes/cache/documents/doc_0e07de339e65_hermes-dr-plan-v2.md]