Homelable homelab: il tool che ha riempito un vuoto
Quanti diagrammi del tuo homelab hai iniziato su draw.io e poi abbandonato? Il terzo container che aggiungi, le linee che si incrociano, una modifica che richiede venti minuti di drag manuale. Ho perso il conto dei miei tentativi. Poi è apparso Homelable — un tool open-source che in 40 giorni ha raccolto 1.100 stelle su GitHub, 35 fork e 20 release. L'ho installato sul mio cluster Proxmox per capire se l'hype fosse giustificato.
Spoiler: lo è. Ma non per i motivi che pensavo.
Homelable homelab visualizer nasce da Remy Jardinet, IT Architect presso Eleven Labs in Francia. TypeScript al 71% per il frontend, Python al 27% per il backend, scanning via nmap e un canvas interattivo dove i dispositivi appaiono dopo la scansione. Health check multi-protocollo (ping, HTTP, HTTPS, SSH, Prometheus, endpoint /health) e — dettaglio che mi ha fatto alzare un sopracciglio — un server MCP integrato che espone la topologia a Claude Code e Claude Desktop sulla porta 8001.
Chiedi all'AI "cosa c'è sulla mia rete?" e lei risponde dal tuo infra reale. Non da una knowledge base statica.
L'installazione: tra iptables, bridge network e CT unprivileged
Ho dedicato un container LXC a Homelable: CT 125, Debian 12, 2 CPU, 2 GB di RAM. Docker 29.4 installato, docker compose up e via.
No. Non è andata così.
Primo problema: lo script community LXC richiede un terminale interattivo — inutile se vuoi automatizzare. Secondo: Docker non parte senza iptables in un CT unprivileged. Serve il flag nesting=1 o un container privileged. Terzo — e questo mi ha fatto perdere mezz'ora: il backend in bridge network non raggiunge le subnet fisiche. I container Docker vedono solo la rete del bridge. La soluzione è brutale ma funziona: network_mode: host nel docker-compose.
# docker-compose.yml — fix per scanning subnet
services:
backend:
network_mode: host # senza questo, nmap non vede le subnet fisiche
