Jarvis: The AI Assistant That Runs My Homelab

My homelab has grown to a dozen servers, a Home Assistant install with a lot of moving parts, and a handful of side projects that all deploy through my own GitLab. Keeping on top of it was eating my evenings. So I built Jarvis: an AI assistant that lives on a small VM in the rack and does a lot of the work for me.

I set it up for three reasons at once. I wanted my evenings back, I wanted one place to run everything instead of a dozen tabs, and I wanted to see what an AI agent can really do when it’s pointed at real infrastructure rather than a demo.

What Jarvis actually is

Jarvis is Claude Code running on its own Ubuntu VM on my Proxmox host. One session stays running all the time, and I can talk to it from the Claude app on my PC or my phone, wherever I am. It has SSH access to the servers, a login to GitLab, and a set of small tools I’ve written for the jobs it does most.

It isn’t magic, and it isn’t a chatbot bolted onto a dashboard. It reads files, runs commands, writes code and checks its own work, the same way I would, just much faster and without getting bored.

What I use it for most

Building and shipping code. This website, my SkillsLedger app and my scripts all live in GitLab, and every push to the main branch deploys through CI. Jarvis writes the change, runs the build and tests, bumps the version the way each project expects, pushes it, waits for the pipeline and then checks the change is really live. If a pipeline fails for a reason that has nothing to do with the code, it says so and retries rather than “fixing” something that wasn’t broken.

Patching and server health. Patching follows the same steps every time:

1. Take a Proxmox snapshot of the VM.
2. Install everything that’s pending, including the phased and kept back updates Ubuntu holds back by default.
3. Check the server came back healthy.
4. Report the result, then remove the snapshot once all is well.

Every morning a fleet check runs on its own and only messages me when something actually needs attention: updates waiting, a failed service, a backup that didn’t run, disk filling up.

Jarvis also reads its replies out loud in my office through Home Assistant, which is more useful than it sounds when I’m across the room.

The rules that keep it safe

Giving an AI agent access to real servers needs clear rules. These are the ones that matter most to me:

• It asks before anything risky. Rebooting the Proxmox host, Home Assistant, the router or the NAS always needs my explicit OK, and so does anything touching locks, the alarm or the garage door. Approval only counts if I give it in the session doing the work.
• Snapshots before changes. Every patch starts with a snapshot it can roll back to.
• Everything goes through git. Jarvis doesn’t edit code or config directly on a server. Every change is a commit that CI deploys, so there’s always a history and a way back.
• It tells me everything. Every maintenance job reports its result to a Discord channel, failures included. I’d much rather read “this failed” than discover it a week later.

Rebooting the Proxmox host is a special case, because Jarvis lives on it. Before that kind of reboot it writes down what it did and what to check, schedules the reboot a couple of minutes out rather than doing it instantly, and picks up from its notes when it comes back.

Real moments

A few things that happened while building things with it convinced me this was worth it.

It caught a bug that could have deleted my email records. While moving SkillsLedger to a new domain, the new homepage wouldn’t load. Jarvis traced it to code that decided whether a DNS record “already existed” for a hostname. The new domain’s root already had its Microsoft 365 mail records, so the code thought the website was already set up and skipped it. Fixing that turned up something worse: the code that removes a hostname deleted every record with that name, which on the root domain would have included the mail records. It fixed both, so now only the website’s own record is ever touched.

It didn’t “fix” a build that wasn’t broken. One deploy failed with a 502 error from Docker Hub while pulling a base image. Rather than changing code to make the error go away, it read the logs, recognised a temporary problem on Docker Hub’s side, retried the job, and it passed.

Its first fleet check found a real problem. On two servers log rotation had been failing quietly because of a duplicated config entry. Nobody had noticed. It found it on the first run and fixed it.

The honest verdict

Jarvis is great, but it needs care. It’s fast, thorough and genuinely good at the boring parts of running a homelab. But it works best with clear rules, small steps and someone checking the important results. The guardrails above aren’t there because it misbehaves often. They’re there because when you hand over the keys to real systems, you want the mistakes to be cheap and visible.

If you’re thinking of trying something similar, my advice is to start small. Give it one job, like a daily health check that only reports, and write down your rules before you give it anything that can change things.