Hermes Wiki
opportunities/2026-08-11-incremental-hetzner-vps

Incremental Opportunities for Hetzner VPS — 2026-08-11

Scope: this is the first incremental opportunities pass for Projects/Hetzner-VPS.md — no prior file exists for this project. Checked against this window's Microsoft "Architectural Implications of Agentic AI Workflows" paper and the Docker Sandbox Kits note.

Microsoft's Agora paper gives the hermes CPX32 instance a concrete diagnostic question it currently has no answer for

Hetzner-VPS.md §4 concludes the current CPX32 (4 vCPU / 8GB) is "comfortable headroom" for Hermes's cron-driven workload — AI Digest scraping every 4h, weekly/monthly synthesis passes, vault lint/fix — based on the workload not appearing "compute-bound." This window's Microsoft paper names the specific failure mode that headroom assumption doesn't account for: agentic workloads (which Hermes's synthesis/fix agents structurally are — LLM reasoning interleaved with tool calls, file reads, and web requests) fragment into bursty, alternating CPU-bound and GPU/API-bound phases, and capacity-planning models built for steady-state or chat-style traffic systematically underestimate CPU pressure once tool-calling dominates. Hermes's workload is exactly tool-calling-heavy (git operations, file I/O, subprocess calls to other agents) layered on top of LLM API calls, not GPU-bound at all — meaning the paper's warning applies in a lighter, single-tenant form: the "comfortable headroom" conclusion was reached by observing the workload doesn't max out CPU on average, not by checking whether CPU spikes during the specific moments multiple tool calls fire in quick succession within one Hermes agent run. Worth a concrete follow-up: check CPU utilization specifically during a synthesis-fullsweep run's tool-call-dense phases (not just averaged over the whole cron window) before treating the CPX32's headroom conclusion as validated rather than assumed.

Docker's Sandbox Kits pattern is a direct, adoptable answer to a gap the VPS note doesn't currently address: how Hermes's agents get scoped, reusable tool access without hand-wiring credentials each run

Hetzner-VPS.md documents the hermes instance as the box running "the vault's automation layer" but says nothing about how the various Hermes agents (fix, lint, synthesis) are provisioned with the tools and credentials they need on each invocation. This window's Docker Sandbox Kits note describes exactly this problem for coding-agent sandboxes generally: empty/ad hoc sandboxes force either repeated manual setup or credentials pasted directly into agent-visible environment variables, and the fix is declarative, versioned spec.yaml kits (install commands, network allow/deny lists, and proxy-managed credentials the agent never directly holds) that compose via sbx run --kit x --kit y. Given Hermes already runs multiple distinct agent types (fix, lint, synthesis) that likely need overlapping-but-not-identical tool access (git write access for fix, read-only for lint, GH_TOKEN for sync per the existing reference_hermes_gh_token.md memory note), the kit pattern — one mixin per capability (git-write, gh-token-proxied, vault-read) instead of one undifferentiated environment every agent runs in — is a concrete, scoped hardening step worth evaluating for the hermes VPS specifically, independent of whether Docker's own tooling is adopted; the proxy-managed-credential principle (agent sees a sentinel, never the real token) is directly applicable to how GH_TOKEN is currently exposed to Hermes's sync scripts.

Hermes Wiki