30 marzo 2026 · 6 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.
2 nodi, 3 subnet, 14 container LXC. Tutta la mia rete Proxmox raggiungibile da qualsiasi posto in 12 minuti netti, cronometro alla mano. Tailscale fuori, NetBird dentro. E il piano Business non mi costa un euro.
Ho usato Tailscale per oltre un anno. Funzionava, non lo nego. Ma quando un progetto open source con 24.000 stelle su GitHub ti offre lo stesso servizio con controllo completo, API REST documentata e un Business plan gratuito, la domanda non riguarda la lealtà verso il vecchio strumento. Riguarda quanto tempo stai perdendo a non provarlo.
Se hai già letto come ho risolto il CGNAT con Tailscale Peer Relays, sai che il mio homelab dipende dalla VPN per l'accesso remoto. Cambiare overlay network non è una decisione che prendi a cuor leggero. Questa è la cronaca di come l'ho fatto, cosa ho guadagnato, e cosa ho perso.
Tailscale ha un problema che non è tecnico. È strutturale. Il control plane è proprietario. Le ACL si scrivono in un formato JSON inventato da loro. E il piano gratuito — 3 utenti, 100 dispositivi — funziona finché sei solo tu con il tuo portatile. Appena vuoi condividere l'accesso con qualcuno, le opzioni sono due: pagare $6/utente/mese (piano Starter) oppure accettare che la persona usi il tuo account.
NetBird ribalta l'equazione. Il client è open source sotto licenza BSD-3, management e signal server sotto AGPLv3. Puoi self-hostare tutto — dal relay alla dashboard — oppure usare il cloud gestito. Il piano gratuito copre 5 utenti e 100 macchine. Il Business plan aggiunge SSO, audit log, posture check e activity monitoring.
Il mio setup: Fedora come workstation, Proxmox VE su Ryzen 7 1800X con 14 container LXC distribuiti su tre subnet — 10.0.10.0/24 (management), 10.10.10.0/24 (backend), 10.20.20.0/24 (Docker). Il gateway è un Raspberry Pi che fa da router/firewall con AIWALL, l'IDS che ho costruito con un LLM.
Su PVE (root, Debian):
curl -fsSL https://pkgs.netbird.io/install.sh | bash
netbird up --setup-key 64AF895E-xxxx-xxxx-xxxx-xxxxxxxxxxxxRisposta: Connected. Nessuna domanda, nessun browser da aprire, nessun OAuth flow. La setup key si genera dal dashboard in 3 click. Su Fedora, stesso script. Due nodi connessi in peer-to-peer con WireGuard in meno di 90 secondi.
Confronto diretto: Tailscale richiede tailscale up che apre un URL nel browser per l'autenticazione. Se sei su un server headless via SSH, devi copiare l'URL, aprirlo su un altro dispositivo, autenticarti, tornare al terminale. NetBird con la setup key elimina questo passaggio completamente.
Qui viene il bello. Con Tailscale usavo --advertise-routes per esporre le subnet del Proxmox. Funzionava, ma dovevi anche approvare le route dal pannello admin. Con NetBird, le network routes si configurano via API REST.
Ho creato 3 network, assegnato le subnet come resource, e impostato PVE come routing peer con masquerade attivo. Tutto via curl — nessun click sul dashboard:
# Crea la network
curl -X POST "https://api.netbird.io/api/networks" \
-H "Authorization: Token ${NB_TOKEN}" \
-H "Content-Type: application/json" \
-d '{"name":"PVE Management","description":"vmbr0"}'
# Aggiungi la subnet come resource
curl -X POST "https://api.netbird.io/api/networks/${NET_ID}/resources" \
-H "Authorization: Token ${NB_TOKEN}" \
-H "Content-Type: application/json" \
-d '{"address":"10.0.10.0/24","name":"management","type":"subnet"}'
# Imposta PVE come router
curl -X POST "https://api.netbird.io/api/networks/${NET_ID}/routers" \
-H "Authorization: Token ${NB_TOKEN}" \
-H "Content-Type: application/json" \
-d '{"peer":"${PVE_PEER_ID}","masquerade":true}'Risultato sul client Fedora:
$ netbird routes list
Available Networks:
- ID: management-subnet
Network: 10.0.10.0/24
Status: Selected
- ID: vmbr1-subnet
Network: 10.10.10.0/24
Status: Selected
- ID: vmbr2-subnet
Network: 10.20.20.0/24
Status: SelectedLe route compaiono automaticamente su tutti i peer del gruppo. Non devi approvarle una per una. Non devi riavviare nulla.
Ping dal portatile (Fedora, fuori dalla LAN del Proxmox) verso PVE attraverso il tunnel NetBird:
$ ping -c 3 100.70.87.58
64 bytes from 100.70.87.58: icmp_seq=2 ttl=64 time=1.32 ms
64 bytes from 100.70.87.58: icmp_seq=3 ttl=64 time=3.21 ms
$ ping -c 2 10.0.10.200 # PVE via network route
64 bytes from 10.0.10.200: icmp_seq=1 ttl=64 time=1.21 ms
64 bytes from 10.0.10.200: icmp_seq=2 ttl=64 time=3.04 ms
$ curl -o /dev/null -w '%{http_code}' http://10.0.10.103:3000
302 # Grafana risponde attraverso la routeLatenza media sotto i 3 ms in connessione peer-to-peer sulla stessa LAN. In condizioni normali, la connessione P2P si stabilisce direttamente — il relay (hosted da NetBird su Francoforte) interviene solo se il NAT traversal fallisce. Nel mio caso, connessione diretta al primo tentativo.
Non è tutto rose. Tailscale ha MagicDNS integrato — scrivi pve.tailedac2b.ts.net e raggiungi il nodo. NetBird ha introdotto Custom DNS Zones nella v0.63, ma la configurazione è meno immediata. Tailscale ha anche Funnel per esporre servizi pubblicamente; NetBird ha risposto con un reverse proxy integrato nella v0.65, ma per ora solo self-hosted.
Il vantaggio killer di NetBird per un homelabber? Le network routes via API. Ho automatizzato l'intera configurazione delle 3 subnet con uno script bash. Se domani aggiungo una quarta VLAN su Proxmox, la espongo in 30 secondi con un curl. Con Tailscale, --advertise-routes richiede un restart del daemon e l'approvazione manuale dal pannello.
Una volta verificato che tutto funziona via NetBird, rimuovere Tailscale è banale:
# Su ogni nodo
tailscale logout
systemctl stop tailscaled
systemctl disable tailscaledHo controllato che i miei script di deploy e il pipeline di pubblicazione del blog (che fa SSH su 10.0.10.200) funzionassero ancora. Tutto ok — usavano già l'IP LAN, non quello Tailscale.
Un'alternativa per chi non ha un server fisico: Pangolin fa qualcosa di simile su WireGuard per esporre servizi self-hosted. E se non vuoi gestire nemmeno il tunnel, servizi come PikaPods ti permettono di hostare le stesse app (Vaultwarden, Uptime Kuma, Grafana) senza hardware — NetBird + PikaPods copre lo scenario zero-infrastruttura.
NetBird fa tutto quello che Tailscale fa nel mio homelab, con tre vantaggi che per me sono decisivi: open source completo, API REST per automatizzare tutto, e un modello di licensing che non ti punisce quando aggiungi un utente. La migrazione da Tailscale ha richiesto 12 minuti. Non ho perso un singolo servizio. L'unica cosa che mi manca è MagicDNS, e ci metteranno una pezza. Per chi gestisce un homelab Proxmox con subnet multiple, NetBird VPN è la scelta giusta oggi.
Fonti: NetBird GitHub, NetBird March 2026 Newsletter, Tailscale Pricing, NetBird vs Tailscale — birdhost.de, NetBird Network Routes Docs, XDA — NetBird for first-time homelabbers