25 marzo 2026 · 7 min lettura
Self-HostingLa cloud sovranità europea è sovereignty washing: i datacenter sono in UE, le chiavi restano a Seattle. Gaia-X è fallito, NIS2 stringe. Il homelab risponde.
Self-Hosting900k siti WordPress esposti a RCE critico, 500k a file read su wp-config.php. Se ospiti WordPress in homelab o su VPS, ecco cosa fare nei prossimi 30 minuti.
Self-HostingIscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.
Da YNAB a Google Photos, ogni SaaS che usi ha un'alternativa self-hosted su PikaPods a meno di $6 al mese. 10 confronti con prezzi reali.
Era un PC da gaming. Un Ryzen 7 1800X montato nel 2017, quando Zen 1 era la grande promessa di AMD. Ha fatto il suo lavoro per anni, poi è arrivato l'upgrade a un Ryzen di nuova generazione e la macchina vecchia è rimasta lì, spenta, a prendere polvere. Non me la sentivo di lasciarla morire.
L'ho presa, le ho tolto il case originale, l'ho infilata dentro un vecchio case tower server recuperato — adattando gli slot a mano perché le misure non combaciavano. Ho aggiunto un alimentatore ATX, una scheda di rete PCI da 2.5 Gbps comprata apposta, una scheda video riciclata da un PC ancora più vecchio. Il risultato non era bello. Ma si accendeva, postava, e aveva sedici thread da dare in pasto a Proxmox.
Oggi quella macchina Frankenstein fa girare dodici container Linux, un sistema di intrusion detection con AI, cinque applicazioni web in produzione e l'analytics del blog che stai leggendo. Il cloud non ha mai visto un mio centesimo. Del Raspberry Pi 5 e dell'intelligenza artificiale che analizza il traffico di rete ne avevamo già parlato. Quella era una fetta del sistema. Oggi apro il cofano intero.
Il processore è l'originale della macchina gaming: un AMD Ryzen 7 1800X, otto core fisici, sedici thread, boost a 3.85 GHz. Primo della stirpe Zen, quello che riaprì la competizione con Intel dopo anni di stagnazione. Nove anni dopo, con dodici container in esecuzione, la macchina non suda. Ce n'è d'avanzo.
La scheda madre è una ASUS PRIME B350-PLUS — entry level puro, nata per il gaming budget. Quattro slot DIMM, un M.2 per l'NVMe e PCI Express standard. Niente ECC, niente IPMI, niente di quello che un purista del self-hosting considererebbe necessario. Per un homelab che non deve garantire cinque nove di uptime, funziona.
La RAM è il pezzo più anarchico di tutto il sistema: 48 GB di DDR4 distribuiti su tre moduli da 16 GB di produttori diversi, forzati a convivere a 2666 MHz dal BIOS della B350. Un overclocker piangerebbe. Ma in un homelab che fa girare container Linux, l'unica metrica che conta è la stabilità. E dopo giorni di uptime continuo: zero memory error.
La scheda video è una AMD Radeon HD serie 5000 recuperata da un PC ancora più vecchio — un fossile che serve solo per la console locale quando il server non risponde via rete. Proxmox gestisce tutto da interfaccia web; la GPU è lì per le emergenze. Il pezzo che invece ho comprato nuovo è la scheda di rete PCI da 2.5 Gbps — l'unico upgrade deliberato. La NIC da 1 Gbps integrata nella B350 è spenta; i 2.5 Gbps si sentono eccome quando fai snapshot ZFS o backup tra macchine sulla stessa LAN.
La strategia storage non è nata da un progetto — è cresciuta per necessità, un disco alla volta.
Il boot sta su un NVMe da 256 GB. Sopra ci gira LVM con la partizione classica di Proxmox: sistema root, swap e un pool thin-provisioned di riserva. Tutto lo storage dei container vive su ZFS.
E ZFS è dove diventa interessante. Tre SSD SATA da 240 GB ciascuno: due in mirror e uno standalone. Il mirror è la spina dorsale: checksum automatici, scrub settimanali, e se uno dei due SSD muore l'altro continua a servire i dati senza interruzione. Il terzo SSD ospita dati meno critici — nessuna ridondanza, ma anche nessuna perdita irreparabile se salta.
# Pool ZFS - struttura
Pool mirror ~220G (2x SSD SATA in mirror, scrub settimanale, zero errori)
Pool singolo ~220G (1x SSD SATA, dati non critici)
NVMe (LVM) ~240G (boot + swap + thin-pool di riserva)Proxmox VE 9 gestisce tutto. Nessuna VM, solo container LXC — più leggeri, più efficienti, con overhead vicino allo zero. Ecco la mappa di quello che gira sulla macchina, divisa per funzione.
Cinque web app girano in container dedicati. Questo blog (Next.js + PostgreSQL) è il più pesante con 4 core e 3 GB di RAM. Le altre quattro sono gestionali e app di servizio per realtà locali — associazioni sportive, servizi comunali, gestione interventi tecnici, programmi di allenamento. Ciascuna ha tra 2 e 4 core e tra 2 e 3 GB di RAM.
Il totale allocato supera i thread fisici disponibili — e va bene così. Proxmox non riserva core, li condivide: nessun container usa mai tutto contemporaneamente e il kernel distribuisce il tempo CPU in base alla domanda reale. La RAM, invece, è allocazione dura: circa metà della disponibile è riservata ai container, il resto fa da margine per buffer di sistema e cache ZFS.
La rete interna è segmentata su più bridge virtuali, ciascuno su una subnet dedicata. Il traffico delle web app non si mischia con quello del monitoraggio, e i container Docker vivono su una rete isolata. Non è paranoia — è buon senso quando esponi servizi su internet.
L'accesso dall'esterno passa per un tunnel crittografato che espone i servizi pubblici senza aprire porte sul router. Per l'accesso remoto c'è una VPN mesh: la macchina raggiungibile come se fossi sulla LAN, con autenticazione a chiave e zero configurazione sul firewall.
Lo stack di sicurezza è a più strati e, sì, è sproporzionato per un homelab domestico. Ma quando hai cinque web app esposte su internet, la paranoia diventa igiene.
Sull'host gira un IDS (Intrusion Detection System) che ispeziona il traffico in tempo reale, affiancato da un firewall collaborativo che banna automaticamente gli IP sospetti consultando una threat intelligence comunitaria — una blocklist alimentata da migliaia di istanze nel mondo.
Un Raspberry Pi 5 funziona da gateway di rete con una seconda istanza IDS. I log di tutte le sorgenti — host, gateway, reverse proxy, DNS filtering — confluiscono in un container dedicato che li correla e li analizza con un LLM. Se non hai letto l'articolo dedicato ad AIWALL, è lì che trovi il dettaglio completo di come funziona.
Grafana con Prometheus raccoglie metriche da tutto l'ecosistema. Exporter dedicati sull'host riportano CPU, RAM, I/O e stato di ogni container. Gli alert dell'IDS vengono convertiti in metriche navigabili. Il risultato è una dashboard dove vedo in tempo reale lo stato di salute dell'intera infrastruttura.
Se qualcosa si rompe alle tre di notte, la mattina dopo lo leggo nei grafici senza scavare nei log. Non è overengineering — è il minimo sindacale per dormire tranquilli quando fai self-hosting serio.
Tutto questo gira su un ex PC da gaming che stava per finire in cantina. L'hardware è consumer, metà dei pezzi sono riciclati, il case è un adattamento fatto a mano. Niente di quello che vedete su r/homelab con i rack ordinati e le luci LED coordinate.
Funziona. Da anni.
Il pezzo più costoso di tutta la configurazione non è l'hardware — è il tempo. Ma quello, a differenza di un abbonamento cloud, lo investi una volta e resta tuo.
Fonti: dati hardware e configurazione letti direttamente dalla macchina via SSH — Proxmox VE Documentation, OpenZFS, Plausible Analytics, Forgejo