C'è un momento preciso in cui un homelab smette di essere un hobby e diventa infrastruttura. Per me è stato quando mi sono reso conto che le applicazioni che ci girano sopra le usano persone vere, ogni giorno, e non possono stare ferme.
Non parlo di Plex o di Pi-hole. Parlo di applicazioni che ho costruito io, che risolvono problemi reali, e che girano su un server in casa mia. Self-hosting nel senso più concreto del termine: i miei dati, le mie macchine, il mio controllo.
Cos'è un homelab di produzione?
È un server domestico che non è più un esperimento. Le applicazioni che ci girano sopra hanno utenti reali, dati che non possono andare persi e un'aspettativa di uptime. Non è un datacenter — non ha ridondanza elettrica, non ha SLA contrattuali, non ha un team dedicato. Ma ha le stesse esigenze di affidabilità, e le affronta con gli stessi principi: isolamento, backup, monitoring, failover. La differenza è il budget e la scala, non la mentalità.
Se ti stai chiedendo perché qualcuno sceglierebbe di gestire tutto da sé, ho scritto anche perché sto lasciando il cloud. Questo post va oltre: non è il perché, è il come.
Il cluster Proxmox del mio homelab: due nodi online, quorum attivo. Screenshot a scopo illustrativo.
Serve hardware nuovo per un server casalingo?
No. Il mio nodo principale è un AMD Ryzen 7 1800X con 47 GB di RAM. Era il computer di mio fratello — un ottimo PC che a un certo punto è diventato "datato" per l'uso che ne faceva lui. Ma datato per cosa? Otto core, sedici thread, quasi 50 giga di memoria. Per un server che ospita container LXC è una macchina perfetta.
Chi lavora con hardware tech lo sa: non butti via un pezzo del genere. Lo metti da parte, e prima o poi trova uno scopo. Questo è diventato pve, il cuore del mio homelab — 12 container, un Ryzen 7 e zero cloud.
Stessa storia per il secondo nodo. Un Intel Core i7-6700K su una ASUS Sabertooth Z170 Mark 1 — la mia workstation precedente. Quattro core, otto thread, 8 GB di RAM. Per anni è rimasta in un angolo dello studio. Poi è arrivato il momento in cui serviva un nodo di failover, e quella macchina era lì, pronta.
Iscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.
Self-Hosting
SSO e 2FA su tutto con Authentik — un login per il homelab di produzione
10 servizi, 10 password diverse, zero audit. Poi ho installato Authentik: un identity provider self-hosted con SSO, 2FA e audit log centralizzato. Come e perché l'ho fatto nel mio homelab.
Zero acquisti. Due PC che nella vita precedente facevano altro, e che adesso reggono un'infrastruttura con failover automatico. Un server casalingo non richiede hardware da datacenter — richiede hardware che conosci e di cui ti fidi.
Questo post è il primo di una serie in cui documento come ho trasformato un homelab da "macchina sotto la scrivania" a un'infrastruttura con cluster Proxmox, failover automatico, SSO e monitoring. Non è teoria: ogni dato viene dal mio setup reale, ogni errore l'ho fatto davvero.
Si possono hostare applicazioni reali su un homelab?
Sul mio cluster girano quattro applicazioni che ho sviluppato e che sono in produzione. Non demo, non proof of concept — software che viene usato ogni giorno.
Un gestionale per un'associazione sportiva. Un'app per la raccolta differenziata. Una piattaforma per la gestione degli interventi tecnici. Un sistema di fitness tracking.
Sono progetti miei. Li ho scritti, li mantengo, li hosto. E ho scelto di tenerli in casa perché è la scelta che ha più senso: controllo totale sui dati, zero costi ricorrenti di hosting, e la libertà di configurare tutto esattamente come serve.
Accanto a questi, ci sono i servizi che fanno funzionare il resto: il blog che stai leggendo, il Git server dove vive il codice, l’SSO che gestisce l’autenticazione di tutte le applicazioni, il monitoring, le automazioni. Dieci container attivi su un singolo nodo Proxmox, ognuno isolato, ognuno con le sue risorse.
È on-premise nel senso più letterale: i miei dati, le mie macchine, a casa mia.
Alcuni dei container in produzione: il blog, l’app per la differenziata e AIWALL IDS. Screenshot a scopo illustrativo.
Conviene il self-hosting rispetto al cloud?
La domanda giusta non è se conviene in assoluto — dipende da cosa devi fare. Ma per il mio caso, i numeri parlano chiaro.
Dodici container in esecuzione permanente — grazie anche al supporto OCI nativo di Proxmox 9.1. Su un provider cloud, anche con istanze piccole, la spesa mensile si aggira facilmente tra i 100 e i 200 euro. Con il mio homelab, la spesa ricorrente è la corrente elettrica: stimata tra i 15 e i 20 euro al mese per due server, un Raspberry Pi e uno switch. Aggiungi il dominio e poco altro, e sei sotto i 30 euro.
Ma non è solo una questione economica. È una questione di indipendenza. Non devo aprire un ticket per avere accesso root. Non devo pagare per ogni gigabyte in più. Non devo sperare che il provider non cambi le condizioni del servizio. Se qualcosa si rompe, so esattamente dove guardare.
Il trade-off è reale: sei tu il sysadmin, sei tu il supporto, sei tu che ti svegli se il server va giù. Ma se le applicazioni che ci girano sopra sono tue e le conosci nel dettaglio, nessuno le gestisce meglio di te.
Cosa succede quando il server si spegne?
Per anni il mio homelab è stato un singolo server. Funzionava. Quando dovevo aggiornare Proxmox, spegnevo tutto, aggiornavo, speravo che ripartisse. Quando un disco dava errori SMART, ordinavo un SSD e pregavo che arrivasse prima del guasto.
Il punto di svolta è stato banale: un aggiornamento del kernel andato male. Era un venerdì sera, stavo aggiornando Proxmox come avevo fatto decine di volte. Reboot. Schermata nera. Nessun output, nessun prompt, niente GRUB. Due ore a fare boot da USB, montare la partizione root a mano e risalire alla configurazione che l'aggiornamento aveva sovrascritto.
Nel frattempo, quattro servizi giù. Nessun alert — perché non avevo un sistema di monitoring. Ho scoperto il problema il giorno dopo, quando un utente del gestionale sportivo mi ha scritto: “non riesco più ad accedere.” In quel momento ho capito che quello non era più un hobby. Era infrastruttura, e la stavo trattando come un giocattolo.
Quel giorno ho deciso tre cose: serve un secondo nodo, serve failover automatico, serve monitoring che mi avvisi prima che se ne accorga qualcun altro.
Il secondo nodo era già lì — la mia ex workstation. L'ho montata, installato Proxmox, aggiunta al cluster. Adesso se il server principale muore, quattro container critici si riavviano automaticamente sull'altro nodo. Nessun intervento manuale.
Lo stress test a pieno carico dice 61 gradi con un margine di 39 gradi dal throttling. Con il dissipatore Noctua NH-D15 e la pasta termica Thermal Grizzly Duronaut, questo nodo regge senza problemi.
Come si ottiene alta disponibilità in un homelab?
Non serve hardware enterprise. Serve decidere che quello che gira in casa tua merita la stessa attenzione che daresti a un server in un datacenter.
Nel mio caso, alta disponibilità significa un cluster Proxmox a due nodi con un Raspberry Pi come arbitro per il quorum. Tre reti separate per non mischiare il traffico di gestione con quello dei servizi. Un unico sistema di login per tutte le applicazioni. Un firewall intelligente sul gateway. Accesso remoto via VPN senza esporre nessuna porta su internet.
Il pannello HA di Proxmox con i container protetti da failover automatico. Screenshot a scopo illustrativo.
Non ho un rack da 42U. Non ho ridondanza N+1 sull'alimentazione. Non ho un team di sysadmin. Ma ho un'infrastruttura che sa reagire da sola quando qualcosa va storto, e che mi costa meno di un abbonamento Netflix.
Le sfide aperte (e come le stiamo risolvendo)
Un homelab di produzione non è mai finito. Ci sono sfide aperte, e fanno parte del percorso. La differenza rispetto a un anno fa è che oggi so esattamente quali sono e ho un piano per ognuna.
Lo storage è la prossima sfida: la replica ZFS tra i due nodi è configurata e funzionante, ma va messa a regime per garantire che i dati più recenti siano sempre su entrambi i nodi. La RAM del secondo nodo è il collo di bottiglia più evidente — 8 GB bastano per il failover dei container critici, ma un upgrade è in programma. I backup oggi sono locali: nella quinta parte di questa serie vedremo come costruire una strategia di disaster recovery concreta, con offsite incluso.
Ogni sfida è un articolo che scriverò e un problema che risolverò davanti a voi. Se seguite questa serie, vedrete l’intero percorso — non solo il risultato finale, ma ogni decisione, ogni errore e ogni soluzione.
La serie completa
Questa è la prima di sei parti. Ognuna copre un aspetto dell'infrastruttura con configurazioni reali, output dal mio cluster e i problemi che ho incontrato.
Perché trattare il homelab come produzione — questo post
Cluster Proxmox con 2 nodi: Corosync, QDevice e HA — come funziona il failover, con test reale
3 subnet, un Pi come firewall e VPN — segmentazione di rete e accesso remoto
SSO e 2FA su tutto con Authentik — un unico login per tutte le applicazioni
ZFS, backup e disaster recovery — proteggere i dati con budget limitato
Monitoring: sapere tutto prima che si rompa — dashboard, alert e automazioni
Ogni post è autonomo. Ma insieme raccontano una storia: si può costruire in casa un'infrastruttura di produzione affidabile senza spendere migliaia di euro e senza un datacenter.
Basta trattarla come produzione. Nella prossima parte stacco la corrente al server principale e vediamo cosa succede davvero. Corosync, QDevice, fencing e HA manager: il test di failover che avrei dovuto fare molto prima.
