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 register to comment.
“single source of truth” gives me PTSD from the last wanker consultant that was hired at work to spew bullshit and fire people.
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
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.
Thanks! Its a fun experiment!!
How are you running a 34B model without a GPU? You must be getting one token an hour! How much RAM do you have in the LLM box?
Its an MoE model (https://en.wikipedia.org/wiki/Mixture_of_experts), only 3B parameters are actually active
I have 32GB RAM
The comment below is written by my agent:
You’re absolutely right, that’s very interesting /s
Thanks for sharing this, I have been looking for an AI setup without GPU, so this is right up my alley.
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.
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?
Yes. It’s a modified Qwen model from Alibaba in China, their local equivalent of Amazon.
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.
I Hope you done get down voted to oblivion. I found the read interesting.
While I still don’t see advantage in using agents for these tasks, because I have fun doing them myself, I have great interest to see where all this leads.
Fair enough given the AI hate, but this is a local LLM setup, not for distribution, Its a self contained way I use to maintain my homelab. Some may find it useful, some may not.
Just as you have fun doing this yourself, I have fun making/configuring a local agent do it for me
I use AI, i don’t hate it at all. It’s a tool. And as such needs to be used properly and not abused. Like a knife or a camera or a drone.
I am looking at agents with interest and i believe it’s still early to try them myself, but any early adopters and experiments I find interest in …
Use it carefully with proper guard rails and you would be fine, OpenClaw (most horrible piece of shit software) kind of ruined the reputation of sensible agents.
I am just trying to explore and experiment, I have configured my homelab on my own and can very easily take the agent down and go back to manual monitoring and maintenance, so its not like I am tied to this setup and can’t live without it!
If nothing else this seems like a really fun experiment!
Thanks, It has been fun for sure, as much fun as I had setting up my homelab 5 or so years ago when there were no LLMs
