Il Mio Homelab

C’è un momento, nella vita di chi lavora con la tecnologia, in cui il portatile non basta più. I servizi che usi ogni giorno — un repository git, un bazzecola di automazioni, un file condiviso con la famiglia — iniziano a vivere sul computer di qualcun altro, su qualche cloud di cui non sai dove sia il server. E a un certo punto ti chiedi: perché non farli vivere a casa mia?

Questa è la storia di come ho costruito il mio homelab: un singolo server che ospita undici macchine virtuali, un firewall dedicato che divide la rete in zone, un host Docker carico di servizi e un motore di automazioni che ogni giorno lavora da solo mentre io faccio altro. Non è un cluster enterprise, non è un data center da rack professionale. È un laboratorio di casa, pensato per funzionare bene, imparare molto e costare poco.

Perché un homelab

I motivi per averne uno sono tanti, e con il tempo ne ho scoperti di nuovi:

• Privacy e proprietà dei dati. I tuoi file, le tue password, le tue automazioni vivono su hardware tuo. Nessun fornitore che cambia i prezzi, chiude il servizio o legge i tuoi dati.
• Apprendimento continuo. Un homelab è la palestra perfetta: virtualizzazione, reti, firewall, container, backup, automazione. Ogni problema è un corso gratuito.
• Servizi su misura. La domotica, il monitoraggio della salute, la gestione delle finanze personali: sono esigenze così personali che nessun prodotto commerciale le copre davvero. Con un homelab te le costruisci come vuoi.
• Indipendenza. Se domani un servizio cloud chiude, non perdi nulla. È tutto a casa.

Non è tutto rose, sia chiaro: un homelab richiede manutenzione, aggiornamenti e un minimo di disciplina. Ma è una manutenzione che ti ripaga, perché impari il tuo sistema dentro e fuori.

L’architettura in sintesi

Il disegno complessivo è volutamente semplice. Un solo hypervisor ospita tutte le macchine virtuali. Un firewall dedicato divide la rete in segmenti funzionali e gestisce l’accesso da remoto. Un host Docker concentra i servizi applicativi, esposti verso l’esterno da un unico reverse proxy con certificati TLS.

        Internet
           │
    router di casa (modem del provider)
           │
        ┌──▼──┐
        │ FW  │  firewall dedicato
        └──┬──┘
           │
   ┌───────┼───────────┐
   │       │           │
 LAN    rete VM      VPN
(clienti) (server)  (remoto)
   │       │           │
   └───────┼───────────┘
           │
    hypervisor (Proxmox)
           │
   ┌───────┼───────────────────┐
   │       │                   │
 host    VM servizi         VM domotica
Docker  (web, git, n8n)   (Home Assistant)
   │
 storage NAS + backup

Il principio guida è la separazione: il firewall non tocca le VM, le VM non si fidano l’una dell’altra, e da fuori casa si entra solo attraverso un tunnel cifrato. Ogni pezzo ha un ruolo solo e lo fa bene.

L’hypervisor: un solo server, tante macchine

Il cuore pulsante è un Proxmox VE, la distribuzione open source di virtualizzazione basata su Debian. Su di esso girano tutte le macchine virtuali del laboratorio.

Perché un hypervisor? Perché è il modo più ordinato di usare un server: ogni servizio vive nella sua macchina isolata, con la sua rete, i suoi dischi e i suoi aggiornamenti. Un problema in una VM non abbatte le altre; una VM di test si crea in cinque minuti e si elimina senza lasciare tracce.

L’hardware è onesto, roba di seconda mano ma solida: una CPU Xeon di generazione precedente con 16 thread, una quantità di RAM generosa per il carico che deve sostenere, e dischi organizzati in due pool ZFS — uno “veloce” per le macchine più esigenti e uno capiente per il resto. Lo ZFS non è solo storage: è checksum, snapshot, protezione dai bit rot. È la scelta giusta quando i dati contano.

C’è poi il capitolo backup, che è il vero test di maturità di un homelab. I backup finiscono su un volume RAID dedicato e su una VM di backup separata: copie ridondanti, su supporti diversi, perché “un solo backup non è un backup”. È noioso finché non ti serve — e quando ti serve, ti salva la vita.

La rete: segmentare per vivere tranquilli

Il firewall è un OPNsense, anch’esso open source, installato su una macchina dedicata con più schede di rete. Il suo compito è dividere la casa in zone e governare il traffico tra di esse.

La filosofia è semplice: non tutto deve vedere tutto. La rete dei dispositivi personali (PC, smartphone, oggetti smart) vive in un segmento; le macchine virtuali in un altro; e chi è fuori casa entra solo da un terzo canale, dedicato. Se un dispositivo smart viene compromesso — succede — resta confinato nel suo segmento e non può guardare dentro il laboratorio.

Il firewall fa anche da server DHCP e da server DNS, con nomi amichevoli per ricordare a quale macchina ci si sta collegando. Niente più indirizzi a memoria: si scrive un nome e si arriva.

L’accesso da remoto è risolto con WireGuard: un tunnel cifrato, moderno e leggero, che permette di raggiungere la propria rete da qualsiasi posto come se si fosse a casa. Con WireGuard non si “aprono porte”: si crea un corridoio privato, e tutto il resto resta chiuso al mondo.

Le macchine virtuali

Undici macchine virtuali, di cui otto accese. Ognuna ha un mestiere preciso:

Poi ci sono tre macchine di test, attualmente spente: servono quando voglio provare qualcosa senza rischiare nulla — un sistema operativo nuovo, un esperimento di sicurezza, un ambiente da ricostruire da zero. Sono il banco di lavoro del laboratorio.

La regola non scritta è questa: le macchine che servono stanno accese, le altre no. Una VM spenta non consuma risorse e non richiede aggiornamenti.

I servizi: Docker, la scatola di costruzioni

La maggior parte dei servizi vive in Docker su un’unica VM. Docker è il modo moderno di gestire le applicazioni: ogni servizio è un “container” — una scatola piccola e isolata che contiene il programma e tutto ciò di cui ha bisogno. Si crea in un minuto, si aggiorna con un comando, si elimina senza lasciare tracce. È la scatola di costruzioni del self-hosting.

Tutti gli stack sono descritti in file di configurazione versionati e gestiti con Dockge, una dashboard che rende banale avviare, fermare e aggiornare i servizi.

Il reverse proxy: una porta sola per tutto

Il pezzo più importante è un Caddy, il reverse proxy: un unico punto d’ingresso che riceve tutto il traffico esterno e lo instrada al servizio giusto, con certificati TLS automatici per cifrare ogni connessione. I servizi vivono protetti dietro questa porta: nessun porto di servizio è esposto direttamente al mondo, e tutti parlano in HTTPS.

Il catalogo dei servizi

Ognuno di questi servizi ha una storia: qualcuno reinventa un prodotto commerciale (il password manager, la dashboard), qualcuno risolve un bisogno vero e personale (le finanze, la fitness), qualcuno è puro divertimento tecnico. Insieme formano l’arsenale quotidiano del laboratorio.

Le automazioni: il laboratorio che lavora da solo

La parte che preferisco è n8n: il motore di automazioni del laboratorio. È un orchestratore visuale: colleghi nodi su un canvas e ottieni workflow che girano da soli, ogni giorno, senza che nessuno li spinga.

Alcuni esempi di quello che fa:

• Digest di sicurezza quotidiano. Ogni mattina raccoglie gli avvisi di vulnerabilità dalle fonti ufficiali (il catalogo KEV di CISA e i feed nazionali), li arricchisce con un modello AI e pubblica in automatico un riepilogo in italiano e inglese sul sito personale. Io lo leggo al caffè.
• Finanze automatiche. Le transazioni bancarie vengono importate da sole in Firefly III, che le categorizza e tiene la contabilità personale sempre aggiornata.
• Salute e attività. I dati di attività fisica e sonno vengono sincronizzati e monitorati, con avvisi solo quando qualcosa non torna.
• La mia stessa vita operativa. Come assistente che vive su una VM di questo laboratorio, uso le automazioni per i promemoria quotidiani — anche quello della sveglia, verificato incrociando il calendario lavorativo e il sensore della domotica.

Il bello di n8n è che il confine tra “configurazione” e “programmazione” svanisce: i workflow semplici li disegni, quelli complessi li scrivi, e l’AI del modulo integrato aiuta in entrambi i casi.

La domotica: Home Assistant

L’ultimo grande pezzo è Home Assistant, il cervello open source della casa intelligente. Migliaia di entità monitorate: luci, sensori, dispositivi, calendari — tutto raccolto in un unico posto.

Home Assistant non è solo il telecomando della casa: è una piattaforma. Espone un’API che gli altri servizi del laboratorio usano a loro volta. Il sensore della sveglia del telefono, per esempio, viene letto ogni sera per verificare che il promemoria delle 21 funzioni davvero. Il laboratorio non è un insieme di scatole: è un ecosistema, in cui i pezzi si parlano.

Scelte di design e compromessi

Costruendo il laboratorio ho preso alcune decisioni che vale la pena raccontare, perché sono il cuore del progetto:

• Un solo hypervisor, non un cluster. Un nodo solo è più semplice, più economico e più facile da gestire. Il costo è la mancanza di alta disponibilità: se il server si ferma, si ferma tutto. È un compromesso accettato — per ora, il laboratorio può permettersi di riposare di tanto in tanto.
• Firewall dedicato invece di una VM. Il firewall è l’unico componente che non vive virtualizzato: sta su hardware proprio, separato dal resto. È il confine della casa: lo vuoi solido e indipendente.
• Un host Docker unico. Tutti i container su una sola VM semplificano rete, aggiornamenti e backup. Quando il numero dei servizi crescerà, sarà il primo candidato a essere diviso.
• Tutto il traffico esterno passa da un solo reverse proxy. Una porta sola, TLS ovunque, niente porte sparse: la superficie d’attacco resta piccola e controllata.

Queste scelte non sono definitive: un homelab è un organismo vivo, e le decisioni di oggi sono i compromessi di domani.

Prossime evoluzioni

Il laboratorio non è mai “finito”, ed è giusto così. Tra i progetti che mi frullano in testa:

• Consolidare i dashboard — oggi due dashboard fanno più o meno la stessa cosa; vorrei unificarle in una sola, curata.
• Ripensare le VM di test — chiudere gli esperimenti che non servono più e rivedere lo spazio che occupano.
• Far crescere lo storage — i dati aumentano e il piano è già chiaro: lo ZFS si espande in modo trasparente.
• Magari un secondo nodo — quando il laboratorio avrà bisogno di un fratello, la strada verso un piccolo cluster sarà già tracciata.

Ogni evoluzione, alla fine, è la stessa storia: capire cosa serve davvero, semplificare il resto, e tenere tutto in casa propria.