A new IT admin started working for me this week. It checks every machine in my homelab, files a ticket when something looks off, sends me a summary every morning and keeps the boxes updated. No holidays, no salary.

It’s a Hermes agent from Nous Research, and I named it hermes-it.

There is one catch, and it’s kind of the whole point. It can’t change anything without me saying yes first.

Why I wanted one

In August the GPU on ai-box fell off the PCIe bus and the service was down for over two hours before I noticed. I was the monitoring system, and I’m not a very good one. I wanted something that looks at everything every day and tells me what’s wrong, without me having to remember to check.

Where it lives

It runs in its own container on a Minisforum UM890 Pro running Proxmox. I didn’t buy anything for this. The UM890 is the box I picked for OpenClaw back in March, and it had been sitting unused, so it got a new job.

The model behind the agent is Qwen3.8-27B on ai-box, my Blackwell box. So my logs and configs never leave the house.

It looks after six machines: the home server, ai-box, the Proxmox box it lives on, two TrueNAS boxes and my Mac.

Look all you want, touch nothing

The deal is simple. It can look at anything it has access to, whenever it wants. Anything that changes a machine, like updates, restarts, config edits or reboots, goes through a Jira ticket that I approve first.

I already track all my homelab work in Jira, so the agent just files tickets in the same HOME project I use. It has its own bot account, so I can always tell what it wrote and what I wrote.

Now, I could have just told it “don’t change anything without asking” and hoped for the best. But that’s only an instruction. A model can get it wrong, and a weird log line or web page can talk it into something. So I didn’t want the agent to be the one checking for my approval.

How approval works

When it wants to change something, it puts the exact commands in the ticket, in a code block with a first line that says which machine they’re for. Something like this:

# it-change host=ai-box
apt-get update
apt-get --with-new-pkgs upgrade -y
systemd-run --on-active=30 systemctl reboot

Along with that it writes why, what should happen and how to roll it back. Then it assigns the ticket to itself, moves it to In Progress and emails me. If I’m happy with the plan, I add the label approved.

Only then can the agent run sudo it-change HOME-26 on that machine. it-change is a small Python script owned by root, and it’s the only sudo command the agent has for making changes. It goes to Jira on its own and checks that:

  • the approved label was added by my account
  • the commands weren’t edited after I approved
  • the approval is less than a week old
  • the code block is for this machine
  • this approval hasn’t already been run

If anything fails, it refuses. If everything passes, it runs exactly those commands and nothing else, and the agent posts the output back on the ticket.

sequenceDiagram
  participant A as hermes-it
  participant J as Jira (HOME)
  participant P as Me
  participant G as it-change (root, on the target)
  A->>J: Ticket with commands, plan and rollback
  A->>P: Email: HOME-26 needs approval
  P->>J: Add label 'approved'
  A->>G: sudo it-change HOME-26
  G->>J: Read the ticket and its history
  G->>G: My account? Unchanged? Right machine? Not run yet?
  G-->>A: Run the approved commands, return output
  A->>J: Post output, move to Done

It’s very strict about who approved. The label being there isn’t enough. If any account other than mine added it, the run gets refused. I had the bot try adding the label itself through the Jira API, and the script refused it straight away. Running the same approval twice and editing the commands after approving got refused too.

What it can get to

Each machine only gives it what it needs.

Machine What it gets Changes
Home server, ai-box SSH as hermes-it (only from the agent’s IP), logs, and a few read-only commands for disks and Docker Only through it-change
Proxmox Read-only API token It files a ticket, I do it
TrueNAS boxes Read-only API keys It files a ticket, I do it
Mac A standard user It files a ticket, I do it

No root shell anywhere, and it’s not in the docker group either (that’s basically root). The Proxmox firewall also blocks anything on my network that isn’t on its list, so it can’t go poking around.

There’s one thing it can do without asking. It can download newer Docker images on the home server, since that doesn’t touch anything running. Actually switching a container over to the new image is a ticket like everything else. There’s a Plex update sitting in my queue right now.

It can’t spam me

An agent with email and a bunch of scheduled jobs could fill up my inbox pretty quickly. So the mail tool doesn’t let it. It can send at most 4 emails a day, the same subject twice in a day gets dropped, and it can only send to me. Those limits are kept under a separate user account the agent can’t touch, so it can’t just reset them.

It also can’t read email at all. Nobody can send it instructions that way.

On a normal day I get one digest at 7:30 in the morning. Every two hours it checks for real problems and stays quiet if there aren’t any. On Monday there’s a weekly report with pending updates.

Funny enough, it hit the 4 email limit on day one. A failed update and a few follow-ups did that. Annoying, but that’s the limit doing its job.

The digests have been great. Not having to worry about the health of my home network is a massive boon. I know what the current state is, and if I have questions I can always just ask the agent.

Teething problems

It’s only been a couple of days, so it’s not perfect yet.

Its very first change on ai-box failed at apt update. One of the NVIDIA repo files there had been broken since June, and I never noticed. Nothing changed on the box, and the agent filed a new ticket with the fix, which I approved and it ran fine.

After that update, vLLM on ai-box got stuck in a restart loop and the agent said everything was fine. It was only checking LiteLLM, which still answers even when vLLM behind it is down. Its instructions now say to check vLLM directly.

On the home server it called a held-back kernel “transient”. It wasn’t, that’s just how apt-get upgrade works. It rewrote the ticket, I approved it, and the server is on the new kernel now.

And for a bit it was using the model on my Mac, which went to sleep halfway through a job. It runs on ai-box now, which is always on.

What I don’t love

  • I’m still the bottleneck. If something breaks at 2am, it can tell me, but it can’t fix it till I wake up and approve.
  • The gate only makes sure the commands I approved are the ones that run. It doesn’t make sure they’re the right commands. I still have to actually read the ticket.
  • The Proxmox box has two SSDs with no redundancy. If one dies, the agent goes with it. There are nightly backups to the NAS, but still.
  • I haven’t set up the read-only accounts on the TrueNAS boxes and the Mac yet, so for now it only half watches them.

I’ll be upfront, I didn’t build most of this by hand. I wrote the plan and Claude Code did the build over SSH, one step at a time. So my new IT admin was set up by another AI, and my job now is mostly adding labels in Jira.