Running My Homelab With AI Agents

For years, my homelab demanded a steady stream of small maintenance work. Now most of it gets done through Claude Code and Codex.

I describe what I want, the agent does the keyboard work, and I approve the changes. The maintenance hasn't gone away. It just isn't mine anymore.

What's in the lab

The lab is a Proxmox cluster of about half a dozen nodes, mostly small-form-factor boxes plus one with an NVIDIA card and a Strix Halo system I use for local LLM experiments. Services run in LXC containers: AdGuard Home, Jellyfin, Plex, Home Assistant, Uptime Kuma, and a few dozen others. Networking goes through a UDM Pro with 5G failover on WAN2.

Nothing exotic, but enough moving parts that something always needs attention.

How I work with the agents

I keep a HomeLab repo with inventory files, plans, runbooks, and snapshots of live state. That includes cluster_status.json from Proxmox, AdGuard configs, and network diagrams. The agents read from that repo, SSH out to the actual hosts, and propose changes.

I do almost all of this through the Claude and Codex desktop apps rather than agents embedded in a code editor. I run a lot of side projects, often with several agents working in parallel, and giving each one its own desktop window keeps everything from tangling.

All of this runs locally on my MacBook for now. Eventually I want to move the agents to my dev server so they can keep working when the laptop is closed, but remote-agent tooling isn't quite there yet.

When something interesting happens during a session, it gets written back into the repo so the next session has context.

Five recent jobs the agents handled

Each of these is the kind of small, fiddly infrastructure work that used to sit on my todo list for weeks. With an agent doing the typing, most got done in a session or two.

Planning the Jellyfin/Plex NVENC switch

Jellyfin and Plex were running on the node with the NVIDIA card, but transcoding was going through Intel QuickSync and playback had gotten unreliable. The GPU was sitting unused. I wanted to switch to NVENC.

For this one I asked for a plan before any changes. Claude wrote it out: driver versions, container config changes, order of operations, what to test after each step, how to roll back. I read it, pushed back on a couple of pieces, and only then did we start executing.

That plan-first pattern is now my default for anything that touches kernel modules or the hypervisor.

Cleaning up the pool pump dashboard in Home Assistant

My pool pump runs on a Shelly relay that was already in Home Assistant, but the dashboard was a mess: pool cleaner cards I no longer used, physical button states, power-consumption history, and stale entities from an old ESPHome controller I was retiring.

I worked through it with Codex over a few sessions. We rebuilt the Pool section to just what I actually use: pump, waterfall, spa blower, a configurable "Run for N hours" boost button, and the current schedule status. The pump's real schedule lives on the Shelly itself for reliability, not in HA.

The key was letting Codex drive the in-app browser to see the live dashboard after each change. Each iteration: edit the Lovelace YAML, restart Core, reload the dashboard, verify. That feedback loop is what made the cleanup actually converge.

Adding 5G failover to my UDM

My AT&T WAN had been showing intermittent packet loss. I'd been meaning to replace my old GL.iNet + USB modem failover with something cleaner, and ended up with a Waveshare 5G M.2 card and a Quectel RM520N-GL plugged directly into the UDM as WAN2.

Claude helped with the modem AT commands, the carrier APN config, the UDM failover policy, and the docs I now keep in the repo so I'll remember in six months why a particular sysctl is set the way it is. The physical install was mine. Everything else was a conversation.

Migrating Uptime Kuma to a different Proxmox node

I needed to move Uptime Kuma and a few related services to a different node in the cluster so I could repurpose the original host. Not hard, just fiddly. Back up the LXC, restore on the new node, update DNS, update inventory, double-check the monitor list still resolves.

I described what I wanted in one paragraph. Claude produced a step-by-step plan, asked about edge cases (keep the same container ID? same storage backend?), then walked through it one step at a time. Each step was small enough that I could see what was about to happen before it did.

Fixing an AdGuard DNS loop

AdGuard Home was showing my UDM gateway as an upstream DNS server. That was wrong, and DNS resolution across the network had gotten subtly weird.

Claude traced it to a container-level resolver config. The AdGuard LXC had inherited the gateway as its nameserver from the Proxmox host's /etc/resolv.conf, so AdGuard was forwarding queries back to the gateway, which forwarded them right back to AdGuard. A small loop, easy to miss.

The fix took longer to verify than to find.

How this changed the homelab for me

The lab used to demand maintenance. Now I operate it. I decide what to run; the agent does the typing.

The marginal cost of "one more service" has fallen through the floor. I'm standing up things I would have skipped a year ago.

What's next

Today I'm using closed-source desktop apps and hosted models. They're great. But it's a little funny to depend on someone else's infrastructure to manage my own.

Where I want to land is open-source agent apps driving local models. I've got a Strix Halo box running Qwen3 via lemonade-server, and the pieces are starting to look credible. They'll get there in time.

The next step I keep daydreaming about: when Uptime Kuma flags a service as down, an agent picks up the alert, investigates the host, finds the root cause, and either fixes it or hands me a diagnosis with a recommended fix waiting for approval. Most of the pieces already exist. Webhooks, SSH access, repo context, a model that can reason about symptoms. It's mostly about wiring them together carefully enough that I trust the result at 2 AM.

For now, I'll keep paying the API bill.