Volevo da tempo gestire un server tutto mio, ma mi spaventavano i costi e la complessità. Poi mi sono imbattuto in Proxmox VE — e, col senno di poi, mi chiedo perché non l'abbia fatto prima. Proxmox è una piattaforma di virtualizzazione gratuita e open source basata su Debian: KVM per VM complete, LXC per container leggeri e un'interfaccia web che semplifica davvero la vita di tutti i giorni.
Il bello è che non serve un server costoso. Ho iniziato con un mini PC usato (un Dell OptiPlex Micro) con RAM potenziata e un SSD NVMe — silenzioso, a basso consumo e più che sufficiente per 10–15 container più qualche VM. Con i prezzi dell'energia da queste parti, un mini PC che consuma 10–15 watt in idle fa un'enorme differenza rispetto a un server rack.
Dopo l'installazione, la prima cosa che ho fatto è stata disattivare il repository Enterprise e configurare i repository della community, proteggere l'accesso SSH con chiave e installare Fail2ban. Poi sono arrivati i primi servizi: Pi-hole come blocco pubblicitario per tutta la rete, Nginx Proxy Manager e Portainer. Questo ordine si è rivelato vincente — iniziare in piccolo, non con venti container tutti insieme.
Il mio consiglio più importante, che ho dovuto imparare a mie spese: configura i backup prima di installare il primo servizio. Seguendo la regola 3-2-1 — e i backup tramite snapshot integrati in Proxmox lo rendono quasi fin troppo facile. Tra l'altro, il RAID non è un backup — anche questo ho dovuto capirlo col tempo.
Inizia e basta. Un container, un servizio, e imparerai sull'infrastruttura più che in qualsiasi corso online. E chi vuole solo provare può anche usare un server cloud economico per imparare.
Fonte: Homelab Guide
Secondo IT之家, il NAS a quattro baie Qu405-N150-8G di QNAP è ora in vendita su JD.com. Ha 8 GB di memoria e una garanzia standard di due anni. Il solo dispositivo costa 2599 yuan, mentre il pacchetto con un disco rigido Seagate IronWolf da 4 TB costa 3599 yuan.
Il design è essenziale. Il telaio misura 165 mm x 168 mm x 217 mm e pesa 2,15 kg. Il processore è un Intel N150 a 4 core e 4 thread. Secondo il produttore può gestire la transcodifica di video 4K e far girare macchine virtuali e container Docker, un punto di forza per chi ama smanettare con i server domestici. La memoria SODIMM DDR4 da 8 GB in dotazione può essere portata a 16 GB.
Lo spazio di archiviazione è costituito da quattro alloggiamenti per dischi SATA da 3,5 o 2,5 pollici. All'interno ci sono anche due slot M.2 2280 NVMe PCIe Gen 3 x1, utilizzabili per la cache o per i dati di sistema e dei container. Le porte includono due porte di rete 2.5GbE, due USB-A 3.2 Gen 2, una USB-C 3.2 Gen 2 e una HDMI 2.1.
A mio parere, la combinazione di doppia 2.5G con un N150 è diventata negli ultimi due anni una configurazione comune per i NAS domestici di fascia base. Fa girare Docker senza consumare molta energia, e il prezzo è abbastanza contenuto. L'articolo, però, riporta solo le specifiche senza test reali, quindi se stai pensando di acquistarlo conviene verificare prima rumorosità, consumi ed esperienza software con recensioni affidabili.
Fonte: IT之家
Synology ha annunciato per la Germania la nuova serie neo+, composta da DS725neo+, DS925neo+, DS1525neo+ e DS1825neo+. ComputerBase li descrive come versioni più economiche dei modelli Plus, in cui è cambiata solo la configurazione della memoria.
Secondo il resoconto, la sigla «neo» sta per «Non-ECC option». Questi dispositivi usano memoria standard senza ECC, e sempre e solo da 4 GB. I DS725+ e DS925+ montano 4 GB di RAM ECC, mentre i DS1525+ e DS1825+ ne hanno 8 GB: le varianti neo+ quindi ne hanno meno. Per il resto dotazione, funzioni ed espandibilità corrispondono ai modelli Plus, e anche il sistema DSM con le app è identico.
Al prezzo di vendita al pubblico consigliato, la differenza è di circa 200 euro: il DS725neo+ è in listino a 549 euro netti, il DS725+ a 748 euro netti. Nel commercio, però, il divario non è così netto: il DS725+ si trova ora a partire da 663 euro, il DS725neo+ da 629 euro. La memoria può poi essere facilmente sostituita con RAM ECC.
Synology indica come motivo la situazione attuale del mercato della memoria, ossia i forti aumenti di prezzo che hanno colpito anche i modelli Plus.
Per il server domestico trovo interessante questo compromesso. Chi usa il NAS soprattutto per backup, contenuti multimediali e qualche container se la caverà probabilmente con 4 GB senza ECC. Chi tiene all'integrità dei dati dovrebbe guardare con attenzione cosa ottiene con la differenza di prezzo.
Fonte: ComputerBase
Hardware.com.br presenta un homelab che colpisce per le sue dimensioni ridotte. Un utente di Reddit ha pubblicato su r/HomeServer un piccolo rack da 10 pollici con firewall, tre mini PC, un NAS e tutta l'infrastruttura di rete necessaria per far funzionare decine di servizi in casa.
La parte di elaborazione è affidata a tre mini PC, ciascuno con un processore a 8 core e 16 thread e 32 GB di RAM, per un totale di 24 core, 48 thread e 96 GB destinati alla virtualizzazione. Per creare macchine virtuali e container LXC usa Proxmox. Tra i carichi di lavoro ci sono una VM per Jellyfin, lo stack arr in esecuzione su Docker, un altro host Docker con Portainer, Pi-hole e dashboard come Homer e Homepage, oltre a server di giochi come Terraria e Core Keeper.
Lo storage è un HP ProLiant MicroServer con quattro dischi da 4 TB in RAIDZ1 di ZFS, che permette di continuare ad accedere ai dati anche se un disco si guasta. Si tratta di 16 TB lordi, con uno spazio utile inferiore a causa della parità. La rete è gestita da un Fortinet FortiGate, che si occupa di routing, VLAN e VPN SSL, mentre un gruppo di continuità APC Back-UPS 850 protegge da cali di corrente.
La parte più interessante, a mio avviso, si trova fuori casa: il proprietario tiene due VPS con Debian in data center esterni, collegati all'homelab tramite una rete WireGuard in configurazione hub-and-spoke. Fanno da livello pubblico dell'infrastruttura, con Traefik come reverse proxy.
È un buon esempio del fatto che un homelab non ha bisogno di un rack gigantesco: con una buona pianificazione, piccoli apparecchi e un po' di ordine, si può far girare molto in poco spazio.
Fonte: Hardware.com.br
Se su un unico server girano più progetti, prima o poi ci si scontra con le porte 80 e 443, che può ascoltare un solo processo. Un articolo di Habr, dal blog di Selectel, mostra passo dopo passo come risolvere il problema con Nginx Proxy Manager.
L'autore spiega prima il problema: le porte privilegiate, la regola di un solo ascoltatore per porta, i problemi di CORS quando frontend e backend sono separati per porta e l'assenza di HTTPS. Un reverse proxy risolve tutto facendo da intermediario e instradando il traffico in base a dominio e percorso. Un vantaggio in più: il firewall deve avere aperte solo le porte 22, 80 e 443.
L'ambiente di prova è un VDS con 2 vCPU, 2 GB di RAM e 40 GB NVMe, con Ubuntu 24.04 e Docker dal repository ufficiale. La rete viene creata con docker network create proxy, poi si avvia il contenitore jc21/nginx-proxy-manager con volumi per dati e certificati. Mi è piaciuto che il pannello di amministrazione sulla porta 81 sia legato solo a 127.0.0.1 e si raggiunga tramite tunnel SSH.
Successivamente si configura un host proxy: nel campo Forward Hostname va il nome del contenitore, e il certificato SSL si collega dalla scheda SSL. Per i test si usa traefik/whoami. È trattato anche il caso in cui l'applicazione giri direttamente sull'host: l'indirizzo del gateway della rete Docker si ottiene con docker network inspect, e il firewall si configura in modo che non si possa raggiungere l'applicazione aggirando il proxy.
Ci sono anche alcune riserve. Gli esempi mescolano domini diversi e l'immagine usa il tag latest, il che può compromettere la riproducibilità nel tempo. Resta comunque un buon punto di partenza per chi vuole gestire più servizi in casa o su un VDS senza modificare a mano le configurazioni di nginx.
Fonte: Habr (blog di Selectel)
Il Self-Host Weekly di questa settimana, a cura di selfh.st, raccoglie notizie che chi ha un homelab farà bene a conoscere. Apprezzo questo tipo di riepilogo, perché fa risparmiare un sacco di tempo nella lettura dei feed.
La notizia principale è un pasticcio: una nuova suite di alternative open source ad Adobe è stata accusata di copiare progetti esistenti, in particolare il popolare Photopea, il cui sviluppatore è stato tra i primi a dare l'allarme. I due progetti al centro della vicenda, PhotoSuite e PhotoCraft, sembrano collegati e la cronologia è difficile da seguire. Il bollettino consiglia di stare alla larga finché non dimostreranno di essere qualcosa di più di un'opera derivata.
Altre notizie degne di nota: Let's Encrypt ha annunciato che da febbraio 2027 ridurrà la durata dei certificati SSL gratuiti da 90 a 64 giorni, il che rende ancora più importante un rinnovo automatico affidabile per chi gestisce un reverse proxy in casa. Nabu Casa rinominerà Home Assistant Cloud in Home Assistant Link, a causa della connotazione negativa che oggi ha la parola «cloud». Il progetto di condivisione di segreti cifrati Hemmelig è stato archiviato su GitHub, e la NVIDIA Shield TV, una scatola per lo streaming di sette anni molto amata dagli appassionati di homelab, è rincarata di 100 dollari, un aumento attribuito all'inflazione dell'hardware causata dall'IA.
L'autore ha inoltre lanciato il Sondaggio sugli utenti Self-Host 2026, con 45 domande su hardware, software, sistemi operativi, dati demografici e IA. Il sondaggio dell'anno scorso ha raccolto poco più di 4.000 risposte, quello di quest'anno ne ha già 2.000 in soli due giorni. Resterà aperto fino al 31 ottobre e i risultati dovrebbero arrivare a inizio novembre.
Personalmente, la modifica sui certificati è la notizia più pratica: se la tua configurazione di rinnovo è un po' fragile, questo è un buon momento per testarla.
Fonte: selfh.st
RedesZone risponde a un dubbio molto diffuso tra chi monta un server in casa: il NAS va riavviato di tanto in tanto oppure può restare acceso sempre?
La risposta breve è sì, può restare acceso 24 ore su 24. Un NAS è pensato per funzionare in modo continuo, usa unità di archiviazione specifiche per questo scopo e serve per i backup, per liberare spazio su altri dispositivi o per condividere file di grandi dimensioni. Ovviamente consuma energia, come un router o una telecamera di sorveglianza, ma questi apparecchi sono progettati per consumare poco quando sono in standby. Anche dopo mesi di uso continuo non c'è un motivo obbligatorio per riavviarlo, a parte il voler risparmiare energia o il fatto che non ne abbia bisogno.
Ci sono però situazioni in cui conviene riavviarlo: dopo un aggiornamento del sistema operativo, del firmware o di alcuni pacchetti, anche se il dispositivo non lo chiede; quando ci sono problemi di software, come un'app che smette di funzionare, un servizio lento, un'interfaccia web che si comporta male o errori in qualche sezione; dopo una modifica dell'hardware e dopo ogni cambiamento importante nel funzionamento. A volte un processo si blocca o un programma non si chiude correttamente, e un riavvio riporta tutto alla normalità.
Mi sembra un consiglio sensato e senza allarmismi. Per un laboratorio domestico, la regola pratica è lasciare il NAS al lavoro e riavviarlo in modo consapevole, dopo un aggiornamento o quando qualcosa si comporta in modo strano, invece di farlo per abitudine.
Fonte: RedesZone
Quando si fanno girare applicazioni open source su un server domestico, spesso serve inviare email per registrazioni o reimpostazioni della password. Inviare posta direttamente da casa, però, richiede un server SMTP e la configurazione di un dominio mittente, e il lavoro è più di quanto si pensi. Questo articolo, trovato su Qiita, risolve il problema in modo pratico usando Mailpit e Discord.
Mailpit nasce come strumento per testare l'invio di email. Può funzionare come server SMTP e include anche un'API di test. Configurando un webhook, può richiamare un'applicazione esterna non appena arriva un messaggio. L'articolo sfrutta questa funzione per costruire un sistema che inoltra il contenuto delle email ricevute su Discord.
La struttura è semplice: due container avviati con Docker Compose, Mailpit e un webhook-handler. Il webhook-handler è una piccola applicazione Python scritta con FastAPI. Riceve i webhook da Mailpit, formatta mittente e destinatario e li inoltra a un webhook di Discord. La notifica può anche includere un link all'interfaccia web di Mailpit, per consultare il messaggio quando serve. Le impostazioni, come l'URL del webhook, sono raccolte in un file .env separato.
Anche senza inviare alcuna email all'esterno, sapere subito che è arrivata un'email di reimpostazione della password è molto comodo. Per chi gestisce più app in un homelab, raccogliere tutta la posta in un unico punto dovrebbe semplificare parecchio la gestione. L'articolo è dell'agosto 2026.
Fonte: Qiita
Una piccola storia, ma che merita una riflessione per chiunque gestisca da sé la propria rete domestica. Secondo GenK, un utente di X di nome @NomadsGalaxy stava controllando il Wi-Fi dei genitori quando ha scoperto che una macchina da caffè Keurig aveva generato circa 1 TB di upload e quasi 10 GB di download in appena 10 giorni.
Se n'è accorto guardando il sistema di rete UniFi in casa dei genitori. Quel volume anomalo aveva sovraccaricato uno dei punti di accesso Wi-Fi. Invece di indagare sulla causa, ha staccato la spina alla macchina e ha comprato ai genitori un altro prodotto. Secondo l'articolo, la maggior parte del traffico sembrava restare nella rete interna senza uscire verso Internet, quindi per ora non ci sono prove che il dispositivo abbia inviato i dati della famiglia a server esterni. La causa più probabile è un bug del software o un guasto nella comunicazione di rete, e un riavvio potrebbe aver risolto il problema.
L'articolo guarda anche al quadro generale della casa intelligente: più dispositivi connessi ci sono, maggiori sono le probabilità di guasti, falle di sicurezza o interruzioni del servizio. I dispositivi IoT possono diventare una porta d'ingresso per gli attacchi se il produttore non aggiorna regolarmente il software, e alcuni prodotti perdono gran parte delle funzioni quando l'azienda chiude i propri server.
Per me la lezione pratica è avere uno strumento che monitori il traffico per dispositivo nella rete di casa e valutare di separare i dispositivi IoT in una rete dedicata. Senza numeri è molto difficile accorgersi di cosa stia facendo una macchina da caffè.
Fonte: GenK
Chi gestisce una rete domestica o un piccolo homelab conosce bene il suffisso .lan: compare nei pannelli dei router, nei server DNS interni e negli indirizzi che usiamo per raggiungere dispositivi senza un dominio registrato. IlSoftware.it segnala che una candidatura presentata a ICANN potrebbe trasformarlo in un dominio Internet accessibile globalmente.
La richiesta per il TLD .lan è stata presentata da Coffee Danger, società statunitense, ed è ancora in fase di Pre-Evaluation Processing. Questo significa che il dominio non è approvato e non può ancora essere usato per registrare indirizzi pubblici. La candidatura si inserisce nella nuova tornata di assegnazione dei domini di primo livello avviata da ICANN nel 2026, che ha coinvolto centinaia di aziende: tra i richiedenti ci sono Google con .browser, OpenAI con .openai e .chatgpt, Meta con .facebook e l'italiana Aruba con domini come .pec, .vps, .lab, .roma e .ciao. Tutte le richieste restano soggette a valutazione.
Il punto delicato è che .lan non è un nome come gli altri: moltissimi tecnici lo usano da tempo, per esempio nas.lan, router.lan o camera.lan. Se un nome considerato interno entra nel DNS pubblico, il rischio è di avere malfunzionamenti, interrogazioni DNS che escono dalla rete e comunicazioni che potrebbero raggiungere destinazioni diverse da quelle previste.
Da appassionato di reti casalinghe trovo la notizia un buon promemoria: per i nomi interni conviene usare suffissi pensati per questo scopo e non affidarsi a convenzioni di fatto. Per ora non c'è nessuna decisione, ma vale la pena tenerla d'occhio.
Fonte: IlSoftware.it
Korben torna su un comando di Cloudflare che molti sviluppatori usano già: cloudflared tunnel --url. Pubblica un server in esecuzione sulla propria macchina a un indirizzo trycloudflare.com, senza account, senza nome di dominio e soprattutto senza aprire alcuna porta sul router. Per chi ospita servizi in casa è un modo semplice per mostrare un progetto a qualcuno durante un test.
La novità più recente è l'opzione --allowed-mail. Prima chiunque avesse il link poteva collegarsi al servizio. Ora l'accesso può essere riservato a pochi indirizzi e-mail scelti da te, con un codice monouso inviato tramite Cloudflare Access.
Il tutorial parte da un piccolo server web locale sulla porta 8080, che serve una pagina di prova tramite Python. cloudflared è il connettore open source che apre la connessione in uscita verso la rete di Cloudflare. Su Mac si installa con Homebrew. Su Debian o Ubuntu bisogna usare il repository ufficiale di Cloudflare, la cui chiave di firma è cambiata di recente, quindi l'autore consiglia di seguire i comandi attuali e non quelli dei tutorial più vecchi.
Un dettaglio mi ha colpito: se fai lavorare agenti IA con questo strumento, Cloudflare consiglia un hook PreToolUse che blocchi qualsiasi comando senza --allowed-mail, per evitare che un agente esponga per errore un tunnel pubblico.
Per un homelab è un'alternativa leggera all'apertura di porte o a una VPN, purché ci si ricordi che un tunnel pubblico resta un'esposizione su Internet, anche se temporanea.
Fonte: Korben
