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.
When you have a local llm, is it still relying on the energy resources of open ai or the like? Sorry for the dumb question
Originally training the model had used the energy resources of that original corporation or whatever. But when you download that model and start running it on your own hardware, you are using your own energy.
Think of it kind of like some software like Jellyfin. When the developers write the software, they do so using their own electricity. But when you download Jellyfin and actually run the software on your own hardware, you are now only using your electricity, not the developer's electricity at all.
Thank you for explaining!
The local LLM is run on the homelab, just like immich is run on your homelab and doesnt talk to google photos is any way, its the same for my model, self contained, inhouse with no data leaving my network
Meaning you download the entire large language model?
Yes, the download link for the model is in the original post
So it does use the resources of an LLM company like Google or open ai?
The model is an open weight model, Google or Open AI did not create it. I use my electricity at home, So no it doesn't
What's an open weight model?
An Open-Weight Model is an AI model whose core components are publicly released, allowing anyone to download it. This lets users run the model on their own computers, study how it works, and even modify it for their own specific needs.
Is that different from an open source model?
Open-source models provide complete access to the entire model architecture, training methodology, and weights. This comprehensive access includes the model code, architecture design, training scripts, and parameter weights under licenses like MIT or Apache.
Open-weight models represent a more limited approach to model sharing. These models release only the trained parameter weights while restricting access to training methodologies and code. Also under MIT or Apache licenses
Yes. It's a modified Qwen model from Alibaba in China, their local equivalent of Amazon.
Does... It matter?
Energy use is energy use no?
The energy required to do inference (i.e. amount it questions and the like) is no worse than doing some gaming for a short period of time.
That said it's probably less efficient to run locally since anthropic and openai have been getting more efficient data center hardware from nvidia compared to consumer desktop gpus.
Well, questions of efficiency seem like it does matter, no?
Consider also the energy and water they use to cool the datacentre equipment, which doesn’t usually happen at home.