7 Rules for Letting an AI Agent Maintain Your Homelab

An AI coding agent now does a lot of the day-to-day work on my homelab and on this website. It edits theme files on the live server, moves services between machines, cleans up my NAS, and debugs whatever broke overnight.

It’s also a program with SSH keys to my servers that runs shell commands. The agent itself isn’t the danger. The risk is that it’s fast and confident, so a small mistake reaches production in seconds. These are the rules I’ve settled on after months of real use, including a couple I learned the hard way.

1. Every edit starts with a backup next to the file

Before the agent touches a file on a server, it copies it alongside the original with a descriptive suffix:

cp single.php single.php.bak-heroes
cp main.css main.css.bak-20260820-0641

It’s low-tech and it works. The backup sits in the same folder, so rolling back is one cp, not a restore job. And the suffix tells you months later what that change was for. My theme folder has dozens of these.

2. Check the change before it goes live, and revert automatically if it’s broken

A syntax error in a WordPress theme file takes the whole site down. So the workflow for PHP is: edit a local copy, upload it, run php -l on the server, and put the backup straight back if the check fails. Only then clear the cache.

php -l single.php || cp single.php.bak-heroes single.php

The same idea applies elsewhere: nginx -t before reloading nginx, docker compose config before up -d, a dry run before anything that deletes. Make the agent prove the change is valid before it can hurt anything.

3. Look before you delete, and keep a manifest

My NAS cleanup reclaimed over a terabyte, mostly from recycle bins that had never been emptied and from duplicate photo libraries. That’s exactly the kind of job where one wrong path is catastrophic. The purge script writes a manifest of everything it’s about to remove before it removes anything. The duplicate finder confirms every match with a full hash rather than trusting size and partial hashes, which turned out to be wrong for about half of same-camera video files.

The rule for the agent: list first, check the list, then act. For anything irreversible, a human reads the list.

4. One key per account, and check which account it landed on

The agent gets its own SSH key, authorized only for the accounts it needs. It never gets root, and never a password.

Here’s one that caught me this week. I added the agent’s key to my web server through my hosting control panel, and the panel attached it to its own system user instead of the account that owns the site files. The agent could log in, just as the wrong user. It checked who it was before changing anything, spotted the mismatch, and stopped. Had it gone ahead, it would have left files owned by an account the site can’t write to. After adding a key, always confirm:

ssh user@server 'whoami; ls -ld ~/path/to/site'

And when you retire a machine, remove its key and revoke its tokens. Deleting a login file locally doesn’t sign the device out on the provider’s side.

5. Know which machines can’t take the load

My web server is a small VPS that hosts several live sites. I once had the agent try an OSINT scanning tool on it. Load average spiked to around 90 on a two-CPU box that also serves several live sites. Now it’s written down: heavy jobs don’t run on the production box, full stop.

Keep a short list of where things are allowed to run. It saves you from the agent doing something perfectly reasonable in the wrong place.

6. Write down what it learns

An agent that forgets everything between sessions repeats the same mistakes. Mine keeps notes: which cache has to be cleared after a theme edit, which server is overloaded, why a “fix” that looked right was actually wrong. Those notes get read at the start of each session. Most agents support some kind of project memory or instruction file — use it, and correct it when it’s wrong.

7. Decide deliberately how much approval you want

Claude Code, like most agents, can ask before every command or run without asking. I run my own homelab sessions in the no-prompt mode. That’s only reasonable because of rules 1–6: backups, checks, scoped keys, and a written list of things that are off-limits. If you don’t have those in place yet, leave the prompts on. They’re annoying, but they’re the backstop you haven’t built.

Whichever mode you choose, a few actions should always come back to a human: deleting data, anything on a production database, anything that sends or publishes to the outside world, and changes to access (keys, firewall rules, accounts).

The payoff

With these guardrails, handing work to an agent is less scary than doing it myself at midnight. It’s more careful about backups than I am, it never skips the syntax check, and it doesn’t get bored reading a 400-line manifest. The trick is making the safe path the default. Once it is, the speed is just a bonus.

If you want to set up an always-on agent of your own, start with my guide to running Claude Code 24/7 on a Mac Mini.