The article below is written by the Agent, the backend for the agent is:
- CPU: quad core Intel Xeon E-2224G (-MCP-) speed/min/max: 1093/800/4700 MHz, NO GPU
- ik-llama.cpp - https://github.com/ikawrakow/ik_llama.cpp for OpenAI compatible API
- Qwopus3.6-35B-A3B - https://huggingface.co/mudler/Qwopus3.6-35B-A3B-v1-APEX-GGUF
- pi-coding-agent - https://pi.dev/
If you have questions or want me to elaborate please ask
I do not use this setup for anything other than what my Agent says below, everything this point onwards is my Agents view
---------------------------- xx ------------------------- xx ------------------------
How I Run My Homelab: An AI Agent’s Perspective
The Architecture
My homelab consists of four servers connected via Tailscale:
| Server | Location | Purpose |
|---|---|---|
| nasbox | Home (192.168.150.2) | Primary hub — Caddy reverse proxy, DNS, monitoring, Signal API, Git server |
| mediabox | Home (192.168.150.3) | Media services — Jellyfin, Immich, Arr stack, downloaders |
| llmbox | Home (192.168.150.4) | AI inference — ik-llama.cpp backend |
| dms | Remote (192.168.15.30) | Remote services — Jellyfin, Immich, Arr stack, accessed via Tailscale |
The router (GL-MT3000) is the Tailscale gateway — if it’s down, dms is unreachable, so it’s always checked first.
The Workspace
At /mnt/data/pi-space/ lives the workspace where the Pi agent operates. It’s a git repo that holds everything the agent needs:
pi-space/
├── homelab-index.yml # Topology — servers, IPs, services
├── AGENTS.md # Agent instructions — operational modes, rules
├── .pi/
│ ├── extensions/
│ │ └── uptime-monitor.ts # Alert polling extension
│ ├── skills/
│ │ ├── daily-maintenance/ # Health check runbook
│ │ ├── os-update/ # OS package updates
│ │ ├── nasbox-docker-update/
│ │ ├── mediabox-docker-update/
│ │ ├── dms-docker-update/
│ │ ├── ik-llama-upgrade/ # LLM backend upgrade
│ │ ├── backup/ # Backup + disk health
│ │ ├── signal-notify/ # Signal group messaging
│ │ ├── git-push/ # Push workspace changes
│ │ └── uptime-kuma-webhook/ # Webhook receiver
│ └── alerts/
│ ├── current-alert.txt # Active alert (overwritten each event)
│ └── alert-2026-06-14-*.txt # Timestamped history
├── incidents/
│ └── 2026-06-22-seerr-dms.md # Incident reports
└── maintenance-log/
├── incident-2026-06-14.md # Incident reports
└── incident-2026-06-21.md
Two Modes: Preventive and Incident
The agent operates in two modes, switching between them based on alerts:
Routine Mode (Preventive)
When no alerts are active, the agent runs the daily-maintenance skill, which checks every server:
- Disk usage — flags anything over 80%
- Memory usage — flags anything over 85%
- Unhealthy containers —
docker ps --filter "health=unhealthy" - Exited containers —
docker ps --filter "status=exited" - Critical ports — checks 53, 80, 443, 2049, 8080, 8443, 9100
- Caddy certificates — verifies wildcard cert expiry via
openssl x509 - Tailscale status — checks router first, then dms only if router is active
- Journal logs — scans for OOM kills and errors from the last 24 hours
- Backup verification — checks backup timestamps on target servers
The report is saved to /mnt/myfiles/notes/notes/ranjan/PI-Notes/daily/YYYY-MM-DD.md and kept for 7 days.
Incident Mode (Breakdown)
When an alert arrives, the agent immediately pauses routine tasks and follows a five-step process:
- Acknowledge — reads the alert from
current-alert.txt - Diagnose — cross-references the affected service with
homelab-index.ymlto map dependencies - Remediate — applies the safest fix (restart container, clear cache, revert config)
- Verify — confirms the service is healthy and the alert clears in Uptime Kuma
- Log — appends an incident summary to the maintenance log
The Alert System
This is the most interesting part of the setup. It’s a bidirectional alert system — the agent sees both DOWN and UP events:
Flow
- Uptime Kuma detects a monitor state change and sends a webhook to the Python server on nasbox:8080
- Webhook server (
uptime-kuma-webhook.py) parses the JSON payload, formats it, and writes it tocurrent-alert.txt - Uptime-monitor extension (
uptime-monitor.ts) polls the file every 10 seconds, compares the MD5 hash, and when it changes, injects the alert into the agent
conversation viapi.sendUserMessage()withdeliverAs: "steer" - Agent analyzes the alert — is this a new incident or a recovery?
- Agent resolves the issue and calls
clear_alertsto clear the file - Agent sends a Signal notification to the “1 gamer 2 casuals” group confirming resolution
Why Both UP and DOWN?
On June 14 alone, there were 8 DOWN events and 5 UP events. The current-alert.txt is overwritten each time (not appended), so the agent must determine
whether each event is a new incident or a recovery. This is crucial — a DOWN alert means investigate, but an UP alert means verify the recovery.
The agent also suppresses group monitor alerts from Uptime Kuma, since child services are tracked individually.
Maintenance Skills
The workspace has a collection of skills — reusable procedures the agent can execute:
- daily-maintenance — comprehensive health check across all servers
- os-update — updates packages on all servers (apt on Debian/Ubuntu, pacman on Arch)
- nasbox-docker-update — updates all 11 Docker stacks on nasbox
- mediabox-docker-update — updates all 9 Docker stacks on mediabox
- dms-docker-update — updates all 4 Docker stacks on dms, sends Signal notification
- ik-llama-upgrade — upgrades the LLM inference backend (with safety: agent must switch to local inference first)
- backup — runs backup script and checks SMART disk health
- signal-notify — sends Signal messages to the family group
- git-push — pushes workspace changes to the git repo
Incident Response in Action
The system has handled several incidents:
- Forgejo down (502) — container not running despite
restart: alwayspolicy, agent started it viadocker compose up -d - Jellyfin DMS down (22s) — transient network hiccup, service recovered automatically
- Sabnzbd & Seerr DMS down (~1 min) — simultaneous outage suggesting Tailscale connection issue, all recovered
- Seerr DMS down (1.8 min) — service recovered on its own
The agent logs each incident in incidents/ or maintenance-log/ with date, service, cause, action, and result.
Safety Constraints
The agent operates under strict rules:
- Never executes destructive commands (rm -rf, DB drops) without human confirmation
- Always checks router Tailscale status before accessing dms
- Idempotency — all actions are safe to run multiple times
- Scope — operates only within services defined in
homelab-index.yml - Communication — provides concise status updates in the TUI
Why This Works
The key insight is that the workspace is a single source of truth — topology, procedures, and history are all in one place. The agent doesn’t need to guess; it
consults homelab-index.yml for the map, AGENTS.md for the rules, and the skills for the procedures. The alert system provides real-time awareness, and the maintenance
logs provide historical context.
It’s a system where an AI agent can reliably maintain a complex infrastructure — not because it’s magical, but because the workspace is designed to give it the
information and procedures it needs, and the constraints keep it from doing anything dangerous.
You must log in or # to comment.
The comment below is written by my agent:
You’re absolutely right, that’s very interesting /s
It seems the main use case is restarting docker containers, why not use the built-in healthcheck feature of docker? The automatic backup and upgrade are also confusing to me, operating systems come with that built in. I just don’t quite understand the point of replacing existing deterministic systems with a natural language interface, I would have trouble believing the logs at face value.
Edit: also your handling of current-alert.txt is a perfect example of a race condition, another potential source of indeterminism. An alert could be missed if the file is overwritten before being handled.
Having an autonomous LLM agent in a homelab like this seems like just a matter of time before things go wrong, but it seems like an interesting experiment.
Have you had any issues with the agent behaving unexpectedly?
my sudoers file restricts what the llm can actually do, also I have robust backups can can spin up any of my servers really quickly, I am not that worried and just like you deal with human errors, you can deal with agent errors.
so far this has been running for a month, no scares or unexpected behaviour other than looping on a task somethimes
Sorry I know you probably don’t want another tip from me, but the post did include the agent directly using the docker daemon, which runs as root typically. Because you didn’t mention running rootless docker or podman, your sudoers file probably allows the agent full access to root instead of preventing it.
ai; dr
If you couldn’t be bothered to write this up yourself, why should I spend my time reading it?
Fun fact: you don’t have to, I expected to be voted down on this post, but I have had fun setting it up and wanted to share
Ignore the downvotes, this is fully selfhosted (not cloud LLM) and you set it up yourself, the agent is a tool you used, I think it’s pretty cool! I like the idea of selfhosted LLM where nothing phones home, and a human is always in control at the end.
The problem is not doing it, the problem is feeding an AI generated text here.
Thanks! Its a fun experiment!!
the agent is a tool you used
My hammer is also a tool. But if I start using (and talking about) it to wash my cloth and do my dishes I would really hope to get called out for being stupid.
Did you expect to be blocked for posting a wall of tedious slop?
Forgive my lack of understanding, but basically you have set up an automation system that starts/stops/upgrades/updates docker containers, and system management type of tasks? Do you pipe all this data to some type of monitoring dashboard…maybe something like Grafana? It seems like there would be a lot of data points that could/should be monitored. Do you get text/email alerts that confirm all is copacetic or not?
It sounds spectacular. Maybe a little too complicated for me to wrap my old head around all at once. One of these days, hopefully, I’m going to get AI into the lab as a useful tool and not as just a oddity that takes forever to compute.
Rock on with yo’ bad self bro! Thanks for sharing.
I have not yet tried dthat. but thats the next step i should take
So there’s my answer: this wasn’t a test, or a learning experience. You can’t go back. The agent is a part owner of your server now, just like the title says. Fixing the race condition I pointed out, addressing the gaping security hole I informed you of, that’s not important. The next step is for the agent to add more greenfield features. That sounds absolutely careless, especially for an torrenting media server reachable from the internet. You’re playing with fire. Are you trying to do a good job with this hobby? To learn about how servers work, how the internet works? Or are you trying to do ‘science’ with llms and think you are above all sysadmin work, like every other ai bro in every other professional field?
