Source: Self-Healing Infrastructure (madebynathan, 2026-02)¶
Reference architecture canónica para "AI agent gestiona la infra del homelab": 5 capas (Proxmox → Terraform/Ansible → K3s → Monitoring → OpenClaw como AI brain). Tres principios reusables: everything is code, AI as operator not owner, defense in depth. Repo público:
ndbroadbent/homeserver-terraform-ansible-public.
Metadatos¶
- Tipo: blog post (madebynathan.com) por Nathan Broadbent.
- Fecha: 2026-02-03.
- Lectura: 2 min.
- Repo público asociado:
github.com/ndbroadbent/homeserver-terraform-ansible-public.
Por qué entró al wiki¶
- Tesis del usuario alineada al 100%: "treat smart home como un problema de software engineering, use IaC, modern techniques to get it to work reliable without too much extra complexity".
- Tiene principios reusables y stack concreto reproducible — no es ciencia ficción, es repo público.
- Es la primera referencia tangible para Q10 (AI tooling) + Q3 (IaC) + Q5 (observabilidad) simultáneamente.
- Caveat importante: usa K3s. El usuario descartó k8s. La página derivada
analysis/self-healing-adapted-to-user-setupadapta el patrón.
Páginas derivadas¶
- ../entities/openclaw — el AI agent brain.
- ../entities/gatus — health check tool.
- ../concepts/self-healing-infrastructure — el patrón general.
- ../concepts/ai-as-operator — principio de diseño AI con autoridad limitada.
- ../concepts/everything-is-code — principio "if it's not in git, doesn't exist".
- ../analysis/self-healing-adapted-to-user-setup — adaptación al setup del usuario (k8s OUT, agentes IN como pieza central).
- ../analysis/q10-ai-tooling-strategy-v1 — primera versión de Q10: rol del agente, perímetro autónomo, trayectoria mes 1 → mes 12.
Resumen del contenido¶
Stack (5 capas)¶
- Proxmox bare-metal — VMs + LXC + ZFS (snapshots, replicación).
- IaC: Terraform (VMs/LXCs/DNS/storage) + Ansible (packages/services/configs en VMs) + Git (single source of truth, no manual SSH).
- K3s — 40+ apps incluyendo HA, Gitea, monitoring; ArgoCD GitOps; Traefik ingress + SSL.
- Monitoring: Gatus (HTTP/TCP/DNS health checks) + Loki (logs centralizados) + Grafana (dashboards).
- OpenClaw — AI agent en LXC, acceso SSH a todo, ejecuta
kubectl/terraform/ansible/gh, lee logs vía Loki, abre PRs.
Self-healing loop (6 pasos)¶
Detect (Gatus) → Investigate (logs vía Loki) → Diagnose → Fix → Verify → Document
Ejemplos de fixes autónomos citados¶
- Pod crash loops: lee logs, fixea config, restart.
- Certificados expirando: triggers cert-manager renewal.
- Disk space: limpia old backups + ajusta alert thresholds.
- Servicios unreachable: revisa ingress config + fix routing.
Principios¶
- Everything is code — sin SSH manual, sin UI mutating; todo va por git.
- AI as operator, not owner — fixea known patterns autónomo, pide aprobación humana para cambios significativos, documenta todo, humano mantiene control overall.
- Defense in depth — health checks + logs + multi-channel alerts (Telegram, email) + scheduled audits para drift.
- Fail safe, not fail secure — degradación graceful prioriza availability sobre consistency; el AI puede restart servicios pero no puede borrar datos.
Citas textuales¶
-
"Everything is code, and an AI agent watches over it all."
-
"If it's not in Git, it doesn't exist."
-
"AI as Operator, Not Owner" — fixes known issue patterns autonomously, requests approval for significant changes, documents all actions, and humans maintain overall control.
-
"The AI layer is the force multiplier — it turns your monitoring from alert-and-wait into detect-diagnose-and-fix."
Abierto / gaps¶
- El artículo no documenta qué considera "significant changes" que requieren approval humano. Es decisión propia.
- No lista failures cases ni ejemplos de cosas que el agente decidió mal. Hay un HN thread en candidatos media que tiene críticas — ingerir para balance.
- No explica cómo se autentica OpenClaw para
gh(token? machine user?). Inferir del repo público. - Adaptación a setup del usuario: Proxmox sí es opción razonable, pero K3s no (constraint explícito). Ver ../analysis/self-healing-adapted-to-user-setup.