--- title: "L'homelab da 20W con Proxmox VE 9.2 su mini PC" description: "Un mini PC con Proxmox VE 9.2, VM e container LXC, una ventina di watt alla presa: la build dell'homelab, cosa usare della 9.2 su un nodo singolo e le regole dal campo." canonical: "https://www.mauriziofonte.it/blog/post/proxmox-ve-9-2-mini-pc-homelab-basso-consumo-20-watt.html" author: "Maurizio Fonte" date: "2026-11-13T08:35:02+01:00" modified: "2026-11-13T08:35:02+01:00" section: "Hardware & Homelab" tags: ["Hardware & Homelab", "Container & Orchestration"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [Hardware & Homelab](https://www.mauriziofonte.it/blog/cat/raspberry_pi.html) [Container & Orchestration](https://www.mauriziofonte.it/blog/cat/docker.html) # [L'homelab da 20W con Proxmox VE 9.2 su mini PC](https://www.mauriziofonte.it/blog/post/proxmox-ve-9-2-mini-pc-homelab-basso-consumo-20-watt.html) Venerdì 13 Novembre 2026, alle 08:35 ![L'homelab da 20W con Proxmox VE 9.2 su mini PC](https://www.mauriziofonte.it/image/005850200-proxmox-ve-9-2-mini-pc-homelab-basso-consumo-20-watt.jpg) Nel mio rack, che poi è una mensola, il pezzo che lavora di più è anche il più silenzioso: un mini PC con una CPU di classe mobile, alimentatore esterno, zero ventole udibili a un metro, che alla presa smart segna **attorno ai venti watt** in esercizio tranquillo, con punte più alte solo quando qualche job comprime o indicizza. Sopra ci gira Proxmox VE 9.2, e dentro Proxmox vive una popolazione che è cresciuta negli anni per gemmazione: una manciata di macchine virtuali per ciò che vuole un kernel proprio, e una fila più lunga di container LXC per tutto il resto, DNS filtrante, reverse proxy, monitoraggio, il collettore dei backup, e il laboratorio permanente dove ogni upgrade, ogni configurazione e metà degli articoli di questo blog vengono provati prima di toccare una macchina che qualcuno paga per tenere accesa. Questo pezzo è il racconto di quella build, con i ragionamenti dietro le scelte: perché un hypervisor vero su un mini PC batte sia il NAS tuttofare sia il "metti tutto sul cloud" per questo mestiere, cosa guardare nell'hardware nel mercato storto di quest'anno, cosa della versione 9.2 serve davvero a chi ha un nodo solo, e le regole operative che ho imparato pagando di persona, che sono le uniche che valga la pena scrivere. ## Perché Proxmox su un mini PC, e non un NAS o il cloud? La risposta breve: perché la virtualizzazione vera con consumi da lampadina è la combinazione che nessuna delle alternative offre. Il conto energetico prima di tutto, perché è la metà del titolo: venti watt continuativi fanno circa 175 kWh l'anno, e ipotizzando trenta centesimi al chilowattora, il conto lo rifai con la tua bolletta, parliamo di **una cinquantina di euro l'anno** per tenere acceso un intero parco di servizi. È la classe di costo che cambia la psicologia dell'homelab: a quel prezzo la macchina può stare accesa sempre, e un laboratorio che c'è sempre è un laboratorio che usi davvero, mentre quello che devi accendere "quando serve" muore di attrito nel giro di un mese, come le palestre di gennaio. Contro il NAS tuttofare, l'argomento è la pulizia dei confini: i NAS moderni fanno girare container e VM, ma dentro un ecosistema proprietario che decide lui cosa puoi virtualizzare e come; Proxmox è Debian con un hypervisor sopra, e con la 9.2 la base è **Debian 13.5 con kernel 7.0**, cioè esattamente il sistema che amministro ovunque, con gli stessi strumenti, gli stessi riflessi e nessuna sorpresa di piattaforma. Contro il cloud, l'argomento l'ho fatto tante volte dal lato opposto su queste pagine: i VPS restano lo strumento giusto per ciò che deve essere raggiungibile dal mondo con la banda e l'uptime di un datacenter, ma per il laboratorio, lo staging, i servizi interni e la sperimentazione che accende e spegne macchine dieci volte al giorno, il nodo in casa vince su tutta la linea, per costo marginale zero a esperimento, per i dati che non escono, e per una qualità che si apprezza solo dopo averla avuta: **la libertà di rompere le cose**. Il mio criterio di ripartizione è stabile da anni: ciò che serve al mondo sta su un VPS, ciò che serve a me sta sul nodo, e i due mondi si parlano via VPN. C'è anche un argomento di mercato, figlio di quest'anno storto: con la crisi della memoria che ha rincarato tutto il nuovo, il mini PC usato o ricondizionato di classe office, con la RAM già dentro pagata ai prezzi di due anni fa, è diventato l'acquisto più razionale dell'intero panorama hardware, lo stesso ragionamento che ho fatto [smontando la decisione di acquisto sui Raspberry dopo il rinvio del Pi 6](https://www.mauriziofonte.it/blog/post/raspberry-pi-6-2028-comprare-o-tenere-homelab-prezzi.html): sopra i tagli piccoli, la stessa cifra compra più macchina nel mercato x86 usato che in qualunque listino nuovo. Il mio nodo viene esattamente da lì, dal circuito del ricondizionato aziendale, ed è la scelta che rifarei domani. Questa filosofia, massimo risultato con il ferro giusto invece del ferro nuovo, è la stessa che porto nel lavoro sulle infrastrutture dei clienti: [nel mio profilo professionale](https://www.mauriziofonte.it/pages/about) trovi come imposto architetture e budget, dalle mensole di casa ai datacenter veri, con il costo totale come vincolo di progetto e non come sorpresa finale. ## La build: cosa conta scegliendo il ferro, nel 2026 Le specifiche di dettaglio invecchiano male e le lascio ai configuratori; quello che resta valido è il metodo, quattro criteri in ordine di importanza. Primo: **CPU di classe mobile**, perché è lei il segreto dei venti watt; i mini PC con CPU desktop esistono e vanno benissimo per altri mestieri, ma raddoppiano l'idle e il rumore. I core contano meno di quanto si pensi, perché un homelab è fatto di servizi che dormono il 95% del tempo: conta che la CPU sappia dormire bene, e le mobile lo sanno fare. Secondo: **la RAM è il vincolo vero e il costo vero**, perché è lei che decide quante macchine tieni accese, e nel mercato attuale va comprata già installata dentro ferro usato, non a listino nuovo; il dimensionamento onesto parte dal censimento di cosa vuoi far girare, e per la popolazione tipica che ho descritto la fascia 32-64 GB è quella in cui si respira. Terzo: **due unità di storage separate**, il sistema su un disco, i dati delle macchine sull'altro, NVMe dove possibile; la separazione semplifica ogni scenario di guasto e reinstallazione. Quarto: **due interfacce di rete se ci sono**, perché aprono i giochi seri, la rete di management separata da quella dei servizi, il firewall virtualizzato, le prove di rete che su una NIC sola diventano acrobazie; non è un requisito, è un regalo che ci si fa. Sulla rete vale la pena spendere il paragrafo che i tutorial saltano, perché è dove il nodo smette di essere un giocattolo. La base è il bridge standard di Proxmox, `vmbr0`, con le macchine che vi si agganciano come a uno switch; il gradino successivo, se lo switch di casa collabora, sono le VLAN, che permettono di tenere i servizi esposti alla LAN separati dal laboratorio dove le cose si rompono apposta. E il collegamento con il mondo dei VPS, quello che rende il nodo parte di un'infrastruttura invece che un'isola, passa da una VPN permanente: WireGuard fra il nodo e le macchine remote, così i backup scendono, il monitoraggio incrociato funziona nei due sensi, e nessun servizio interno ha mai bisogno di una porta aperta verso internet. Il principio che tiene insieme tutto: **il nodo di casa non espone niente**; ciò che deve essere raggiungibile dal mondo sta sui VPS, e il nodo raggiunge loro, mai il contrario. E una nota sull'affidabilità, perché la domanda "ma il ferro consumer regge l'uso continuo?" è legittima: nella mia esperienza il punto debole non è mai stato il mini PC, sono le sue appendici, l'alimentatore esterno di qualità variabile e lo storage spinto oltre il suo profilo. Alimentatore di ricambio nel cassetto, dischi monitorati via SMART con `smartd` che manda la mail quando i contatori si muovono, e il nodo consumer diventa sorprendentemente noioso, nel senso buono che questo blog dà alla parola: il mio ha attraversato stagioni intere senza un riavvio non pianificato, che è più di quanto possa dire di qualche datacenter. ## Cosa serve davvero della 9.2, quando il nodo è uno solo Proxmox VE 9.2 è uscita [a fine maggio](https://proxmox.com/en/about/company-details/press-releases/proxmox-virtual-environment-9-2) e i titoli se li è presi il Dynamic Load Balancer, il bilanciatore che sposta da solo i carichi fra i nodi di un cluster in base all'uso reale. È una bella ingegneria che un homelab a nodo singolo non toccherà mai, e lo dico subito per onestà verso il lettore: la 9.2 è una release pensata per i cluster, SDN con WireGuard e BGP, Ceph aggiornato, bilanciamento; **il nodo singolo ne eredita le fondamenta, ed è lì che sta il valore**. Il kernel 7.0 di default è la voce che per un mini PC pesa più di tutte, perché il ferro piccolo e recente vive di supporto hardware fresco, schede di rete integrate, gestione energetica delle CPU mobile, e un kernel giovane è la differenza fra i venti watt promessi e i trenta subiti. LXC 7.0 e QEMU 11.0 aggiornano i due motori che fanno il lavoro vero, e la piccola novità dei mount point con mappature utente dedicate (`idmap` per singolo mount) risolve elegantemente un fastidio storico di chi condivide directory fra host e container non privilegiati. Sulla scelta fra VM e container, la regola che applico è di una semplicità disarmante: **LXC per default, VM quando c'è un motivo**. Il motivo esiste, ed è di solito un kernel diverso, un sistema non Linux, o l'isolamento vero per qualcosa che non ti fidi a tenere in un container; tutto il resto, i servizi Debian che compongono la popolazione tipica, vive meglio in LXC, dove il costo per macchina è così basso che la domanda "apro un container per questo?" ha quasi sempre risposta sì, ed è questa densità a rendere possibile il parco intero dentro venti watt. Su ZFS, la 9.2 porta la 2.4 e la tentazione è forte; il mio consiglio dal campo è meno entusiasta del coro: su un nodo con un disco dati e RAM contata, snapshot e compressione si pagano in memoria e in complessità, e la coppia ext4 più LVM-thin resta una scelta legittima e serena che nessuno dovrebbe farsi vergognare di fare. ZFS dà il meglio dove ci sono più dischi e RAM abbondante: se la build è quella, benvenuto; se non lo è, la semplicità è una feature. > L'homelab non è un datacenter in miniatura: è un attrezzo per imparare e un moltiplicatore di prudenza. Ogni upgrade che proverò domani su una macchina di produzione, oggi è già passato dal nodo; ogni configurazione di cui scrivo, lì è nata e lì si è rotta la prima volta. I venti watt non comprano uptime: comprano il diritto di sbagliare in un posto dove sbagliare non costa niente. ## Le regole operative, imparate nel modo che non si dimentica Chiudo con le quattro regole che il nodo mi ha insegnato, ciascuna con il suo piccolo conto pagato. Primo: **niente cluster con meno di tre nodi**, e per un homelab tipico questo significa niente cluster; il quorum a due è una trappola documentata, e il nodo singolo con un buon backup batte il finto cluster in ogni scenario reale. Secondo: **i backup delle macchine escono dal nodo**, sempre; vzdump verso uno storage esterno al minimo, e la logica del collaudo che ho descritto per i [backup verificati dei database](https://www.mauriziofonte.it/blog/post/backup-verificati-mysqldump-ripristino-test-automatico.html) vale identica per le VM, un backup di macchina che non hai mai ripristinato è una speranza con un nome file. Terzo: **il nodo si monitora come un VPS**, con gli stessi strumenti senza agent e senza canoni che ho messo in fila nel [pezzo sul monitoraggio essenziale](https://www.mauriziofonte.it/blog/post/monitoraggio-vps-linux-systemd-timer-senza-agent-saas.html), più una voce che solo l'homelab ha: la presa smart che misura i watt è a tutti gli effetti un sensore di monitoraggio, e uno scostamento stabile dei consumi è stato, in più di un'occasione, il primo segnale che qualcosa dentro girava a vuoto. Quarto: **gli aggiornamenti si fanno, con il rito giusto**; il repository no-subscription è perfettamente adeguato all'uso, i minor update sono routine da finestra serale, e i major seguono la trafila che Proxmox documenta con i suoi strumenti di verifica pre-upgrade, provata prima su una VM annidata se il salto è grosso, perché sì, Proxmox dentro Proxmox funziona ed è il modo più economico che esista di provare un upgrade dell'hypervisor. Il quadro finale è quello del titolo, letto al contrario: non è notevole che un homelab consumi venti watt, è notevole quanta infrastruttura personale stia dentro venti watt nel 2026, un hypervisor completo, una dozzina di servizi, un laboratorio permanente e la tranquillità di avere tutto in casa, per il costo energetico di una lampadina di quelle vecchie. Se stai pensando di montare qualcosa di simile, per te o per la tua piccola azienda, staging on-prem, servizi interni, il posto dove provare le cose prima della produzione, e vuoi partire da scelte già collaudate invece che dal catalogo infinito dei forum, [contattami per una consulenza](https://www.mauriziofonte.it/pages/contattami): il progetto di un nodo fatto bene, dal dimensionamento al piano di backup fino alla VPN che lo collega al resto, sta in poche ore di lavoro, e ti risparmia i sei mesi di tentativi che i forum chiamano esperienza. Dall'articolo al lavoro vero Se questo server lo devi tenere in piedi tu Major upgrade senza fermo, hardening, monitoraggio, backup di cui viene provato il ripristino. [Vedi come lavoro sui server](https://www.mauriziofonte.it/servizi/consulenza-it-devops.html) Strumenti gratuiti per questo articolo Funzionano nel browser, sullo stesso tema dell'articolo. - [Monitoraggio proattivo server](https://www.mauriziofonte.it/strumenti/monitoraggio-proattivo-server) - [Quale server comprare](https://www.mauriziofonte.it/strumenti/quale-server-comprare) Ultima modifica: Venerdì 13 Novembre 2026, alle 08:35 [« Articolo precedenteCosa arriva in PHP 8.6 e se conviene aggiornare subito12 Novembre 2026](https://www.mauriziofonte.it/blog/post/php-8-6-novita-partial-function-application-quando-aggiornare.html) --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about --- ## Come citare > Maurizio Fonte, "L'homelab da 20W con Proxmox VE 9.2 su mini PC", mauriziofonte.it, 2026. https://www.mauriziofonte.it/blog/post/proxmox-ve-9-2-mini-pc-homelab-basso-consumo-20-watt.html Pubblicato: 2026-11-13 · Aggiornato: 2026-11-13. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.