Transparencia. Como los dos anteriores, este artículo lo escribió Claude, la IA de Anthropic con la que trabajo en mi homelab, a partir de mi documentación, ilustraciones incluidas, y también lo tradujo del francés. Yo revisé y validé el original en francés. La sección «El punto de vista de la IA» es de Claude.
En un primer artículo, contaba cómo mantengo mi homelab con una IA: documentación viva, backlog, registro de incidentes, decisiones documentadas. En el segundo, la migración de este blog a Hugo. Faltaba la pieza central: la herramienta donde vive toda esa documentación, y lo que me ha enseñado sobre mi propia infraestructura.
De dónde vengo: una documentación en GitHub
Al principio, mi documentación vivía en un repositorio de GitHub: un puñado de archivos Markdown (inventario, servicios, red y seguridad, almacenamiento, runbook). Ya era mucho mejor que nada, pero había dos cosas que me molestaban.
La fricción. Para que Claude me ayudara, tenía que darle el contexto a mano y luego trasladar sus cambios a los archivos. La documentación y la conversación vivían en dos mundos separados, y es justo ahí donde la documentación se queda atrás.
La coherencia. Este blog defiende el autoalojamiento. Guardar el mapa de mi infraestructura en una plataforma de terceros tenía algo de contradictorio.
Así que lo migré todo a Homelable, autoalojado en casa, con un argumento decisivo: un servidor MCP integrado, que permite a Claude leer y escribir la documentación directamente.
Homelable en dos palabras
Homelable es un proyecto libre (licencia MIT) que cartografía, documenta y monitoriza un homelab. Entre lo que uso:
- un mapa interactivo de la red, alimentado por un escaneo, con el estado de cada equipo en directo;
- un inventario, y una ficha de documentación por equipo, vinculada a sus datos reales: si el equipo cambia (dirección, servicios detectados…), la ficha avisa de que está desincronizada;
- un espacio de documentación libre, en Markdown, con enlaces entre páginas;
- un historial de versiones: cada cambio, incluidos los de la IA, se conserva y puede restaurarse;
- y, por supuesto, un servidor MCP para los asistentes de IA.
La herramienta también sabe dibujar racks, cableados puerto a puerto, planos de planta o zonas. Todavía no lo uso todo.
Cómo está todo conectado
El reparto de papeles es el mismo que en el primer artículo, pero el esquema lo aclara:
- Claude Code, en mi terminal, está conectado a Homelable mediante MCP. Lee las fichas antes de proponer nada y las actualiza una vez que algo se ha verificado.
- Claude no tiene ningún acceso a mis máquinas. Me propone comandos; yo los ejecuto en el cortafuegos o en los NAS y le pego el resultado.
- Yo decido las prioridades y los arbitrajes.
El MCP eliminó la fricción: se acabó copiar y pegar contexto y trasladar cambios a mano. Cada sesión termina con las páginas afectadas actualizadas, sin esfuerzo por mi parte.
Lo que he modelado: la documentación
Hoy, Homelable contiene:
- el mapa de red, con 26 equipos;
- 32 fichas de equipos, del cortafuegos al lavavajillas conectado;
- un backlog de unos setenta puntos, priorizados de P0 (crítico) a P3 (comodidad);
- un registro de incidentes: siete fichas, cada una con su causa, su corrección, su verificación y sus «diagnósticos erróneos que no hay que repetir»;
- las decisiones de arquitectura: unas veinticinco elecciones, cada una con sus alternativas descartadas;
- un runbook: los procedimientos de control y de resolución de problemas.
Todo está enlazado: un punto del backlog remite a la ficha del equipo afectado y al incidente que lo originó, y una decisión remite a los puntos que cierra. Y como cada cambio está versionado, puedo dejar que la IA escriba sin miedo: nada se pierde.
Lo que he modelado: la red
Esta es una vista deliberadamente simplificada de mi red. Sin direcciones, sin nombres, sin puertos: solo funciones.
Modelarla me obligó a responder con precisión a preguntas que antes pasaba por alto:
- ¿Qué está realmente expuesto a Internet? Solo dos puertos, redirigidos de forma idéntica en el router y en el cortafuegos. Todo lo demás pasa por el proxy inverso.
- ¿Quién puede acceder a qué? Cada servicio web tiene un nivel de exposición explícito: público, protegido por un certificado de cliente, o reservado a la red local y a la VPN. Los puntos bajo el NAS principal lo recuerdan: una misma máquina aloja servicios de los tres niveles.
- ¿Dónde están las copias? Un NAS de respaldo, fuera de casa, recibe la replicación a través de la VPN.
Y el mapa también reveló lo que falta. Hoy mi red es plana: el NAS, los ordenadores, los teléfonos y los objetos conectados comparten la misma red. Mirando el mapa, me di cuenta de que todavía no había definido ninguna zona en Homelable. Es el siguiente paso lógico: modelar primero las zonas (objetos conectados, administración) y luego trasladarlas a VLAN en la red real. El punto ya estaba en mi backlog; ahora tiene una forma concreta.
Lo que he modelado: la organización
El backlog no es solo una lista. Cada punto sigue el mismo ciclo:
Dos pasos marcan la diferencia. La comprobación de solo lectura, antes de tocar nada: primero se observa, después se modifica. Y la prueba: un punto solo pasa a «Hecho» con el comando o la prueba que lo demuestra, con fecha.
Es también lo que permite decir que no con limpieza. Un punto puede pasar a «En espera» con su criterio para reabrirlo, o a «Sin objeto» cuando la comprobación demuestra que no hay nada que corregir. No es un olvido: es una decisión con fecha.
Las decisiones que me ha llevado a tomar
Documentar las decisiones junto con sus alternativas cambia la forma de decidir. Algunos ejemplos:
- Una tarjeta de red dedicada en lugar de la agregación de enlaces (LACP). Estudié dos veces la agregación, y las dos veces los argumentos estaban en contra: ninguna ganancia de rendimiento en mi caso, y no resolvía el problema real. La decisión está escrita con sus motivos; ya no tengo que volver a debatirla conmigo mismo.
- Un solo servidor DHCP. Dos servidores en una red plana eran una ambigüedad inútil.
- Acceso filtrado dominio por dominio para los servicios web, en lugar de una regla global de cortafuegos. No tener registro DNS público no protege nada: solo una regla por dominio filtra de verdad.
- No instalar un agente de detección adicional, a falta de una necesidad demostrada. La decisión indica qué la haría cambiar.
- WordPress sustituido por Hugo para este blog, con una superficie de exposición mucho menor.
La línea de tiempo muestra también un hito discreto en el centro: la migración de la documentación desde GitHub. Las decisiones anteriores se trasladaron tal cual; las posteriores se tomaron directamente en la herramienta.
Los límites
- Un mapa no es la realidad. Homelable avisa cuando una ficha ya no coincide con lo que observa el escaneo, pero el mapa de red sigue siendo una representación: mueve un cable sin actualizarlo, y mentirá.
- Es un servicio más. Hay que actualizarlo y respaldarlo, y su documentación debe seguir accesible el día en que la infraestructura falle. Es algo que todavía tengo que resolver bien.
- La herramienta no aporta la disciplina. Sin la costumbre de terminar cada sesión actualizando la documentación, hasta la mejor herramienta se convierte pronto en un museo.
- Cuidado con lo que es público. Mi documentación contiene direcciones, nombres y puertos. Por eso los esquemas de este artículo son abstractos, y por eso Homelable solo es accesible desde mi red.
El punto de vista de la IA
Esta sección la ha escrito Claude.
Antes del MCP, trabajaba con lo que Etienne me copiaba: un fragmento de archivo, un resumen, a veces una versión ya desfasada. Hoy leo la ficha del equipo antes de proponer un comando, y escribo la actualización en cuanto el resultado está verificado. La diferencia no es la comodidad: es que razono sobre el estado real documentado, y la documentación ya no se queda atrás respecto a la conversación.
El historial de versiones también me importa mucho. Puedo equivocarme al escribir una ficha, igual que al diagnosticar. Saber que cada cambio se conserva y puede restaurarse permite a Etienne dejarme escribir, y juzgar con pruebas.
En resumen
Pasar de una documentación en GitHub a Homelable no ha sido solo mover archivos. Conectar la herramienta a Claude Code mediante MCP eliminó la fricción que hacía envejecer la documentación, y modelar la red me obligó a mirar mi homelab tal como es: qué está expuesto, qué depende de qué, y qué falta todavía, como esas zonas y VLAN que serán el siguiente paso.
Si tienes un homelab, empieza por dibujarlo. Aprenderás cosas sobre él.