These days I run my homelab with Claude Code as a working partner. It diagnoses problems, runs commands over SSH, edits configuration, and writes documentation across two Linux Docker hosts running dozens of services, a Synology NAS, a UniFi network, and the monitoring that watches all of it. That it can do the work isn’t the interesting part. What matters is what makes it safe to let it: the guardrails, the handling of secrets, and the written rules that keep it from repeating a mistake.
The Setup
- Claude Code in a terminal on my desktop, reaching the servers over key-based SSH.
- Markdown context files: a main reference document describing the whole environment, which the AI reads before starting any task, plus short “memory” notes, one lesson each.
- 1Password for secrets: credentials are managed in 1Password and pulled at runtime through the 1Password CLI, unlocked by Windows Hello.
- A human in the loop: I review what it’s doing, and risky operations such as reboots, deletions, and network changes wait for my approval.
Guardrails That Came From Real Mistakes
Every rule below exists because something broke. None of them were designed up front.
1. Rewrite config files whole; never patch lines in place
An automated one-line insert once dropped a reverse-proxy route inside the wrong block of an indentation-sensitive YAML file. The proxy silently ignored it, and I spent an hour chasing a 404. The rule now: read the entire file, make the change, write the whole file back in one operation, restart the proxy, and confirm the route is live through the proxy’s own API.
2. Never casually reboot the main server
A routine update reboot once hung for hours (the full story is in The Outage That Wasn’t My Server). Reboots now go through a purpose-built tool with preflight checks, and the AI is instructed to use it, never a bare reboot.
3. Clone what works; don’t hand-craft
Monitors created by hand-written database inserts looked correct but never ran a single check, because a few defaults were left empty. Patching those fields afterward didn’t rescue them. The rule: copy a known-good monitor, then change only what’s different.
4. Verify the real thing, not a stand-in
Some monitors pointed at friendly hostnames were quietly landing on a login page that returned “200 OK.” Green, and meaningless. Similarly, an authentication gateway in front of a service returns a healthy-looking redirect even when the service behind it is down. The rule: test the actual origin before calling anything fixed.
5. Check upstream before blaming the host
When a server drops off the network, the first suspect is the server. Sometimes it’s the network gear above it. Again, the story is in the companion post.
How a Lesson Becomes a Rule
A fix isn’t finished until the lesson is written down in a form the AI will read before it acts next time. Each note follows the same shape:
Why: the incident that taught it, with specifics.
How to apply: the exact procedure and how to verify it worked.
Over time the notes add up to a runbook the AI actually follows, and an audit trail I can read. Just as important, notes that turn out to be wrong get corrected or deleted, so the AI isn’t acting on stale guidance.
What Stays Human
- I approve risky changes, and I decide what “done” means, which always includes a verification step.
- The AI works from documented context and written rules, not from guesses about the environment.
- Credentials are managed in 1Password.
What This Means for Customers
Teams adopting AI for operations ask the same three questions: Can we trust it? What about our secrets? Who’s accountable? The answers I’d give a customer, from running it myself and from integrating Claude with Azure, Datadog, PagerDuty, Jira, Confluence, and Microsoft 365 at work:
- Start read-only. Diagnosis, analysis, and documentation first; changes behind approval gates later.
- Keep secrets out of AI context. Use a secrets manager with runtime retrieval, not credentials in prompts or files.
- Write lessons down as rules. Behavior improves, and it’s auditable.
- Keep a human accountable for every change that reaches production.