Homelab playground: Nous Research Hermes

What it is

I stood up the Nous Research Hermes model in the homelab and pointed it at real systems instead of toy prompts. Nothing here is hardened yet. It's a testbed for finding out what tool-using LLM judgment is actually good for before I commit to building any of it properly.

What it can touch, so far

• Terminal-level Proxmox access. It starts, stops, and inspects VMs and containers directly instead of going through the web UI.
• Beszel monitoring. Beszel watches host and container health and tells Hermes when a Docker container starts flaking.
• Webhook events. Uptime Kuma and n8n push events at it too. The obvious one is a container going down.
• Telegram for approvals. When Hermes wants to change something, it sends me what it found and what it plans to do, and waits for my answer.
• Per-service rules. These are early, informal instructions keyed off container tags. The media stack is fine to reboot on its own judgment, other services have defined maintenance windows, and anything not explicitly covered should default to flagging a human rather than acting.

The first working loop: flaking containers

This is the first piece that has gone from experiment to something I'd call real automated, agentic troubleshooting.

1. Detect. Beszel picks up a Docker container that's flaking: restarting, dropping out, or unhealthy.
2. Investigate. Hermes goes in with terminal access. It reads the logs, inspects the container and its host, and works out why it's failing instead of just noting that it is.
3. Propose. It sends the diagnosis and the fix it wants to apply to me on Telegram.
4. Approve. I read it and approve or reject it from my phone. Nothing changes until I say yes.
5. Fix at the root. Once approved, Hermes fixes the underlying cause rather than restarting the container and hoping.

The thing I care about is the gap between steps 2 and 5. A restart-on-failure policy already handles the symptom. What I wanted to know was whether the model could find the actual cause reliably enough that approving its fix is a quick read, not a second investigation. So far, it can.

Why a human approves the fix

Fixing the root cause means changing config, images, volumes, or the host, not just bouncing a process. That's exactly where "technically correct but not what I meant" can do damage. Approving over Telegram keeps the speed (I don't have to sit at a terminal, and the investigation is done by the time I see it) while keeping the final call with me. The per-service rules still decide what Hermes may do on its own. Root-cause changes go through approval.

Why no infrastructure-as-code yet

I'm deliberately holding off. This is still the exploration phase, finding out where the model's judgment is trustworthy and where it isn't, before it's worth versioning the config or building anything like a real deployment pipeline around it.

What I'm actually testing

Whether the interesting failures turn out to be the obvious ones (the model doing something clearly wrong) or the harder ones (the model doing something technically correct that still wasn't what I meant). The container loop is the first place I'm getting real answers, and the approval step is where I'd catch the second kind before it lands.