Proxmox bare-metal in casa: la base per replicare il cloud sulla scrivania

Le luci sopra l’armadio del garage sono accese da metà pomeriggio. Sul ripiano basso ci sono un mini PC comprato 280 € su AliExpress, una chiavetta USB con l’ISO di Proxmox VE 8.3, un cavo HDMI corto e una tastiera USB italiana che non funziona mai al primo tentativo. Boot da USB, pochi tasti, due conferme, IP statico sulla LAN del lab. In meno di mezz’ora la web UI risponde sulla porta 8006 e il nodo si chiama Stark, perché è il primo, ed è il nodo che fa tutto quello che gli altri non vogliono fare.

Questo post racconta la base. Non l’ultimo trick per abbassare il consumo della scheda video, non la sezione su Tailscale o su Cloudflare Tunnel: quello viene dopo. Qui parlo di Proxmox bare-metal, di perché ho scelto questa via per replicare il cloud sulla scrivania, e di cosa ho imparato gestendo lo stesso strato che poi mi serve in produzione per il cluster OpenSearch su LXC o per il routing multi-LLM in produzione.

Cosa è Proxmox e cosa non è

Proxmox VE è una variante di Debian con installato un kernel Ubuntu LTS, l’orchestratore KVM/QEMU, l’integrazione LXC, una web UI sulla porta 8006 e gli strumenti per il clustering. La parte interessante è che lo stack sotto è tutto Linux standard: qm per le VM, pct per i container, pvecm per il cluster. La web UI è una comodità, non una gabbia. Quando voglio scriptare faccio SSH al nodo e uso i comandi nativi.

Il “classic cloud” che paghiamo a fine mese è la stessa identica cosa, con un’astrazione di fatturazione sopra. Una VPS da 4 vCPU su un provider qualsiasi è una VM KVM su un hypervisor che, in molti casi, è proprio Proxmox o un suo cugino. Capire Proxmox in casa significa capire cosa succede nel datacenter di chi vende cloud.

I concorrenti reali nel 2026 sono pochi:

• VMware ESXi: è lo standard enterprise. Costa, è chiuso, ha tooling ottimo. Dopo la cessione a Broadcom è una bomba a orologeria di pricing.
• KVM puro: il kernel Linux ha già tutto, ma scrivere virsh a mano e gestire il networking con brctl è un lavoro full-time.
• Hyper-V: Windows-first, irrilevante per chi fa stack Linux.
• Xen: tecnicamente solido, ecosistema sempre più piccolo.

Proxmox sta in mezzo: open source, buona UI, gestione del cluster integrata, comunità grossa. Per un home lab è la scelta ovvia. Per uno staging aziendale è la scelta che fa risparmiare mesi.

Bare-metal e non Linux + KVM a mano

La domanda l’ho ricevuta al WP Meetup di Pisa di marzo, e la rifaccio io stesso ogni volta che monto un nodo nuovo: perché non Debian liscia con KVM e bridge a mano? Saprei farlo, le runbook ce le ho.

Le ragioni concrete per cui Proxmox bare-metal vince in casa:

1. Setup di rete pronto. vmbr0 esiste dal primo boot, è un bridge linux standard, lo vedi da ip link. Aggiungere VLAN o un secondo bridge per la rete “lab isolato” è due click. A mano ci metti due ore a fare lo stesso e a debuggare il primo container che non risolve DNS.
2. Storage astratto. Proxmox gestisce ZFS, LVM-thin, directory, NFS, CIFS, Ceph come backend. Il container/la VM non sa quale backend c’è sotto. Cambiare disco fisico significa migrare il volume in 30 secondi via UI.
3. Cluster integrato. Quando arriverà il secondo nodo, pvecm add lo aggiunge in 60 secondi. Il quorum di Corosync è gestito, il fencing è gestito, le VM possono migrare a caldo. Replicare la stessa logica con KVM puro è un progetto.
4. Backup nativo. vzdump con scheduling cron + Proxmox Backup Server come destinazione. Backup incrementali a livello byte, restore di una VM con un click.
5. API REST. Tutto quello che fai in UI lo puoi automatizzare con un token API. Lo uso in alcuni script Ansible per provisioning idempotente di LXC.

Linux + KVM a mano lo scegli se hai un caso d’uso specifico (server con un solo carico, dove ogni overhead conta). In tutti gli altri casi Proxmox bare-metal vince per pure economia di tempo.

VM contro LXC: la matrice decisionale

Qui sta il valore del talk al meetup, e qui si vede chi ha provato e chi ha solo letto i blog.

VM tradizionale (KVM): kernel separato, qualunque OS (Windows, BSD, Linux ovunque), isolamento forte, overhead di memoria 1-2 GB solo per stare viva, cold start 60-90 secondi, hardware emulato.

LXC: kernel condiviso con l’host (lo stesso del nodo Proxmox), solo Linux compat (Debian, Ubuntu, Alpine, Rocky), avvio in 2 secondi, overhead minimo (decine di MB), ridimensionamento RAM e storage a runtime senza riavvio.

La matrice che uso quando devo decidere:

Domanda	VM	LXC
Devo girare Windows?	sì	no
Mi serve un kernel custom o moduli kernel?	sì	no
È un workload “rumoroso” che potrebbe far crashare cose?	sì	no
È un servizio Linux standard (nginx, Postgres, Redis, app)?	overkill	sì
Mi serve avvio sotto i 5 secondi?	no	sì
Voglio scalare RAM a caldo da 2 GB a 8 GB senza riavvio?	no	sì
Vado in cluster con quorum e migrazione live?	meglio	possibile

In pratica: default LXC, eccezioni VM. Su Stark girano 14 LXC e 2 VM. Le VM sono una macchina Windows per testare un client legacy di un partner storico e una VM Debian che fa girare un kernel custom per un esperimento di networking che non voglio vicino al kernel dell’host. Il resto è LXC.

L’argomento del kernel condiviso non è teorico. Su Proxmox quando l’LXC fa kernel panic, non va in panic l’LXC: va in panic l’host. È capitato, ne parlo dopo.

Helper script community: il salto di produttività

Una volta che il nodo Proxmox è su, la cosa più noiosa è creare LXC nuove. La sequenza standard è: scarico un template Debian, faccio pct create con i parametri giusti, configuro storage e rete, avvio, faccio SSH dentro, installo il software, configuro, avvio i servizi. Mezz’ora a essere veloci.

I Proxmox community helper script (l’evoluzione comunitaria del progetto storico tteck) hanno cambiato questa storia. Sono script bash che incapsulano la creazione della LXC, l’install del software dentro la LXC, la configurazione di base, il primo avvio. One-liner copia-incolla in shell Proxmox.

Esempio reale: deploy di Vaultwarden (server Bitwarden self-hosted, leggero, on-premise) sul mio lab.

bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/ct/vaultwarden.sh)"

30 secondi e c’è una LXC nuova con Vaultwarden in funzione su una porta dedicata. Il punto chiave di Vaultwarden è che le password stanno cifrate sul device, il server fa solo sincronizzazione. È l’esempio perfetto di un servizio che in casa ha senso più che in cloud: non sto delegando il mio password manager a un terzo, sto solo tenendo lo stato sincronizzato fra i miei device.

Stessa cosa per:

• n8n: workflow automation, alternativa self-hosted a Zapier.
• Home Assistant OS: domotica, marketplace di plugin, automazioni.
• Mattermost: chat self-hosted (la stessa che racconto in Mattermost self-hosted su Hetzner, qui in versione lab per test di feature).
• Nextcloud: alternativa Google Drive/Photos.

L’avviso onesto: questi script sono comodi per il primo deploy. Per workload di produzione preferisco scrivere io il provisioning in Ansible (idempotente, versionato, replicabile su un secondo nodo). Gli helper script sono perfetti per il lab personale dove voglio provare un servizio nuovo in 30 secondi e decidere se merita.

Postmortem: il giorno in cui un LXC ha tirato giù il cluster

Una sera di gennaio, ore 23:14. Stavo testando un container con un software di rete sperimentale che caricava un modulo kernel custom (perché qualcuno, sul forum, aveva detto che era “innocuo”). Il container partiva, il modulo si caricava, e in 8-12 secondi il kernel dell’host andava in panic. Schermo nero sulla console, web UI giù, SSH morto, tutte le altre LXC e VM giù.

Power-cycle dell’host, ripartiva, primo dmesg | tail, e c’era la traccia del panic dentro il modulo custom.

Cosa ho imparato:

1. L’isolamento dell’LXC è forte verso utente, debole verso kernel. È quello che ti vendono i blog: cgroups + namespace + seccomp. Tutto vero a livello user-space. A livello kernel, una syscall che innesca un bug nel kernel host ti uccide tutto.
2. Workload “ad alto rischio kernel” devono andare in VM. Modulo kernel sperimentale, driver custom, fuzzer di rete, stack di networking esotici (eBPF aggressivo, XDP custom): tutto questo va isolato in una VM, dove al massimo la VM crasha ma l’host respira.
3. Snapshot prima di esperimenti. Banalità ma fondamentale. Ho preso l’abitudine di fare snapshot di una VM/LXC prima di qualsiasi esperimento “non standard”. Rollback in 30 secondi.

La regola operativa che mi sono dato dopo quell’episodio: il container “domestico” sta sul bridge di rete del lab interno, il container con esperimenti sta in una VM separata, la VM sta su un bridge isolato che non vede gli altri container. Tre linee di defense, sui workload che potrebbero rompere qualcosa.

I numeri di Stark in produzione domestica

Qualche numero concreto, perché è lì che si vede se Proxmox in casa è una scelta razionale o una passione cara.

Hardware: mini PC consumer Ryzen-class, 8 core / 16 thread, 32 GB DDR5, NVMe gen4 da 1 TB. Costo: 280 € il PC, 50 € la RAM aggiuntiva, 0 € il NVMe (incluso). Totale 330 €.

Provisioning:

• LXC vuota Debian 12: ~12 secondi dal click “Create” alla shell utente.
• VM Debian 12 nuova: ~90 secondi dal click “Create” all’SSH ready.
• LXC con servizio applicativo via helper script: ~30-90 secondi a seconda del servizio.
• VM con servizio applicativo via Ansible: ~3-5 minuti.

Risorse a regime (14 LXC + 2 VM in funzione contemporanea):

• CPU media: 4-8% (con picchi al 30% durante backup notturni e test di build).
• RAM usata: 18-22 GB su 32 GB (il resto file cache).
• Storage: 380 GB su 920 GB utili.
• Rete: 30-50 Mbps medi sulla LAN interna del lab.

Energia:

• Consumo medio idle: 12-15 W.
• Consumo medio con tutti i servizi attivi: 22-28 W.
• 24/7 a 0,30 €/kWh: ~28-32 € l’anno.

Sì, 30 € l’anno. La cifra che fa sorridere quando la confronti con l’equivalente cloud. Una VPS da 8 vCPU / 32 GB RAM su un provider serio sta intorno a 80-120 €/mese. In casa, con un mini PC da 330 € e 30 € di luce all’anno, ho lo stesso (e la flessibilità di farci girare quello che voglio).

L’ovvia precisazione: la VPS in cloud ha SLA, banda dedicata, IP pubblico, disaster recovery. Il mini PC in casa ha la mia ADSL, una UPS APC da 600 VA che tiene 8-10 minuti, e un nodo singolo. Gli usi sono diversi. Il punto del lab non è sostituire il cloud per i clienti, è avere un ambiente di dev/staging vicinissimo a quello di produzione, con costo operativo trascurabile.

Storage: il pezzo che merita pensiero al day uno

Una cosa su cui ho speso più tempo di quanto pensassi: il backend di storage. Su Stark ho ZFS sul singolo NVMe, configurato direttamente dall’installer Proxmox come rpool/data. È stata la scelta meno romantica e la più giusta.

ZFS porta tre cose che fanno la differenza in un home lab:

• Snapshot atomici a livello di dataset. Prima di un upgrade rischioso (kernel, MariaDB, una nuova versione di un software che non conosco bene): zfs snapshot rpool/data/subvol-XXX-disk-0@pre-upgrade. Se va male, rollback in 10 secondi.
• Compressione trasparente (LZ4 o ZSTD). Sui container con database e log compressibili sto su un risparmio del 30-40% di disco a costo CPU minimo. Su un mini PC dove il NVMe è il vincolo, la compressione è oro.
• Send/receive per replica fra nodi. Quando arriverà il secondo nodo, replicare un container con zfs send | zfs receive è la via canonica, byte-perfect, incrementale dopo il primo.

I tradeoff: ZFS mangia RAM (regola classica: 1 GB di RAM per ogni TB di disco). Sul mini PC con 32 GB e un singolo NVMe da 1 TB l’overhead è invisibile. Su un nodo grande con 8 dischi da 4 TB ci pensi due volte.

Una nota pratica: i template LXC scaricati dalla web UI Proxmox finiscono in local, non in ZFS. Quando crei un container, scegli ZFS come storage del rootfs del container. Se ti dimentichi e usi local-lvm, hai container su LVM-thin invece che su ZFS, e perdi snapshot e send/receive. È capitato a un mio amico al primo deploy, gli ho fatto rifare la pratica.

Networking: il dettaglio che rifarei meglio

Una cosa che avrei fatto diversamente al day uno: separare i bridge di rete.

Quando ho montato Stark ho creato un solo bridge vmbr0 collegato alla LAN di casa. Tutti gli LXC e le VM stavano lì, IP nella stessa subnet della famiglia, della TV, del laptop di mia moglie. Funzionava ma era brutto: ogni nuovo container era un host in più sulla LAN domestica.

Refactor recente: vmbr0 per i container “esposti” (Vaultwarden, Mattermost dev, n8n, Home Assistant, gli unici che parlano con la rete domestica), vmbr1 per i container di “lab” (esperimenti, build runner, container che tirerò giù in due settimane), su una subnet privata isolata. Le LXC di lab parlano con internet via NAT del nodo Proxmox, la LAN domestica non le vede.

Per il provisioning Ansible è una riga in più nel template Proxmox del container. Per la sicurezza è un livello in più: una LXC compromessa nel lab non scopre subito gli host della famiglia.

Cosa mi sono portato a casa

Prima. Proxmox bare-metal su mini PC consumer regge 14 container e 2 VM con margine. Non è un esperimento, è uno stato stazionario da mesi. Il costo elettrico è trascurabile, la web UI è la stessa di un cluster da 12 nodi in datacenter.

Seconda. LXC è il default, VM è l’eccezione. La regola “kernel condiviso” non è un dettaglio, è la differenza fra “il container crasha” e “l’host crasha”. Workload sperimentali in VM, sempre.

Terza. Gli helper script community sono un acceleratore enorme per il primo deploy di un servizio. Per la produzione meglio Ansible, ma per “voglio provare Vaultwarden stasera” sono perfetti. Il marketplace effettivo del 2026.

Quarta. Separare i bridge di rete dal day uno. Refactor a posteriori si fa, ma è due ore di down e qualche grattacapo. Al primo install: vmbr0 esposto, vmbr1 isolato.

Il prossimo passo è il secondo nodo del cluster (Targaryen, server con la 5080) e il Proxmox Backup Server come destinazione di tutti i backup notturni. Su quello scriverò quando i numeri di esercizio saranno solidi. Per ora, Stark da solo dimostra che il cloud sulla scrivania non è uno slogan: è un mini PC da 280 € e una chiavetta USB.