Self-hosting: quando conviene (e quando no)

Introduzione

Self-hosting significa far girare tu i servizi che di solito paghi a qualcun altro. File, password, siti, automazioni. Sul tuo VPS, sul NAS in cantina, su un mini PC in ufficio.

Il vantaggio è controllo. I dati stanno dove decidi tu. Niente rincaro improvviso del piano. Niente "abbiamo dismesso la feature".

Il costo vero non è l'hardware. È il tempo. Aggiornamenti. Backup che devono funzionare. Un disco che muore di sabato. Un certificato scaduto. Un attacco banale su una porta che avevi lasciato aperta.

Questa guida serve a decidere, non a venderti l'idea.

• quando il controllo vale la pena
• VPS, NAS in casa, cloud gestito: differenze che contano
• cosa la gente self-hosta (e la posta, che è un caso a parte)
• baseline di sicurezza: SSH, firewall, update, backup, Docker
• quando è più onesto pagare qualcuno

La domanda giusta non è "posso?"

Quasi tutto si può self-hostare. Nextcloud gira. Vaultwarden gira. Un sito statico gira. Una stack Docker con dieci container gira.

La domanda è: chi si alza alle 3 se non gira più?

Se la risposta è "io, e mi sta bene", vai avanti. Se la risposta è "nessuno, ma voglio comunque i file dell'azienda lì", stai costruendo un singolo punto di fallimento con la tua faccia sopra.

Controllo

Hai le chiavi. Decidi versione, plugin, dove stanno i dischi, chi accede. Nessun vendor che legge i file "per migliorare il prodotto". Nessun lock-in su un export mal documentato.

Serve se tratti dati che non vuoi dare in pasto a un SaaS, o se il SaaS ti limita (quote, API, prezzi a posto).

Non serve se l'alternativa gestita è noiosa, stabile, e ti costa meno delle ore che ci spenderesti.

Costo

Un VPS piccolo sta in una cifra mensile bassa. Un NAS lo paghi una volta, più corrente e dischi. Un piano cloud gestito per posta + file + password manager, sommato, può superare entrambi.

Conta le ore. Setup iniziale. Aggiornamenti. Il pomeriggio in cui il volume Docker si corrompe. Se la tua ora vale, il VPS "economico" diventa il più caro.

Backup

Se self-hosti senza backup, non stai risparmiando. Stai aspettando il giorno in cui perdi tutto.

Il 3-2-1 vale qui più che sul PC di casa: tre copie, due supporti, una fuori sede. La guida è in backup 3-2-1. Un NAS in salotto con un solo disco non è un backup. È il dato originale in un involucro più bello.

Aggiornamenti

Ogni servizio è una superficie. Nextcloud, il reverse proxy, Postgres, Docker, il kernel. Se non aggiorni, resti con CVE note. Se aggiorni senza snapshot, a volte rompi l'upgrade.

Il ritmo minimo: sistema ogni settimana, applicazioni quando esce una patch di sicurezza, snapshot prima. Non "quando ho tempo".

I guasti alle 3

Disco, alimentatore, ISP di casa, certificato Let's Encrypt che non si rinnova, container che non riparte dopo un reboot. Di giorno è noioso. Di notte, se ci gira la posta o il gestionale, è un incidente.

VPS, NAS in casa, cloud gestito

Tre famiglie. Si mescolano (NAS + offsite su un object storage, VPS + backup a casa). La scelta di partenza cambia il tipo di problema.

VPS

Un server in affitto. Debian o Ubuntu, un firewall, Docker se ti serve. Va bene per siti, Vaultwarden, un reverse proxy, bot, staging.

Non è "il cloud che si scala da solo". È una macchina. Se si riempie il disco, si ferma. Se perdi le chiavi SSH e non hai console, sei fuori.

Scegli un provider con snapshot e backup a pagamento. Lo snapshot non sostituisce un backup offsite, ma ti salva da un apt andato male.

NAS in casa

Utile per foto, share di ufficio, target dei backup dei PC. Pessimo come unico posto per un servizio esposto su internet, se non sai cosa stai aprendo.

L'errore classico: "metto Nextcloud sul NAS, apro 443 sul router, via". Il NAS diventa raggiungibile dal mondo. I firmware dei NAS sono un bersaglio noto. VPN verso casa, o un tunnel in uscita, è un altro mestiere. Se non lo vuoi imparare, non esporre.

Cloud gestito

Google Workspace, Microsoft 365, un password manager SaaS, un host che ti fa il sito e i backup. Paghi. Dormi di più. Accetti i loro limiti e i loro contratti.

Ha senso per posta, collaborazione, e per tutto ciò che deve stare in piedi mentre sei in ferie. Self-hostare "perché è più figo" e poi chiedere a un collega di guardare i log non è strategia.

Cosa si self-hosta (e cosa no)

La posta è difficile

Dillo chiaro: la posta in self-hosting è difficile. Non è "installo Mailcow e via".

Devi fare i conti con:

• reputazione IP (un VPS nuovo è spesso in blacklist)
• SPF, DKIM, DMARC, allineati e monitorati
• coda, bounce, quarantena
• spam in ingresso e in uscita (se ti compromettono la box, spammano a nome tuo)
• deliverability verso Gmail e Microsoft, che non ti devono niente
• storage che cresce, backup consistenti, restore di una casella
• pec, se sei in Italia e ti serve: è un altro mondo, non lo improvvisi

Puoi farla. Gente brava la fa. Se è la prima cosa che self-hosti, fallirai in modo invisibile: la mail parte, e finisce in spam. I clienti non te lo dicono. Smettono di risponderti.

Nextcloud

File, calendario, contatti, a volte onlyoffice. È il sostituto più gettonato di un drive commerciale. Funziona. È anche una applicazione PHP + database + cron + storage. Va aggiornata. I plugin si rompono. I client desktop a volte litigano.

Ha senso se i file devono stare da te e accetti di farne manutenzione. Non ha senso se ti serve solo "una cartella in sync" e già paghi 365.

Vaultwarden

Compatibile con i client Bitwarden. Leggero. Perfetto su un VPS piccolo. È il posto dove stanno le password. Se cade, o se lo perdi senza backup, perdi l'accesso a tutto il resto.

Trattalo come infrastruttura critica: HTTPS, aggiornamenti, backup cifrati offsite, accesso amministrativo stretto. Non esporlo "tanto è piccolo".

Siti

Sito statico, blog, landing. È il self-hosting più semplice. Un Caddy o Nginx, un certificato, rsync o CI che pubblica. Poco da rompere. Backup: i file e la config. Se usi un CMS (WordPress), torni nel mondo plugin + database + update.

Un sito vetrina su un VPS da 5 euro è ragionevole. Dieci WordPress senza aggiornamenti sullo stesso VPS è un incidente in preparazione.

Baseline di sicurezza (il minimo, non il bonus)

Se salti questo blocco, non stai self-hostando. Stai lasciando una macchina accesa.

SSH con chiavi, non con password

Password su porta 22 è un invito. Chiavi, utente senza login root diretto, PermitRootLogin no, fail2ban o equivalente se vuoi. Come si fanno le chiavi è in chiavi SSH.

# Sul server: niente password per SSH, solo chiavi
# (sshd_config: PasswordAuthentication no)
sudo systemctl reload sshd

Tieni una via di uscita: console del provider, o una seconda chiave su un altro PC. Altrimenti un laptop perso ti chiude fuori dal VPS.

Firewall

Aperto solo ciò che deve esserlo. Su un VPS tipico: 22 (o una porta SSH non standard, che non è sicurezza vera ma riduce il rumore), 80 e 443 se c'è un sito. Niente Postgres, niente Redis, niente pannelli Docker sulla rete pubblica.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status

I servizi interni stanno in VPN, o su localhost dietro il proxy. "Lo lascio aperto un attimo" è come resta per mesi.

Aggiornamenti

sudo apt update
sudo apt upgrade

Unattended-upgrades per le patch di sicurezza, se sei su Debian/Ubuntu. Riavvii quando c'è un kernel nuovo. I container si ricostruiscono, non si "lasciano perché girano da un anno".

Backup

Prima di innamorarti dello stack: dove va la copia, quanto è fresca, come la ripristini. Il pezzo operativo è in backup 3-2-1.

Per un VPS: snapshot del provider e dump/rsync verso un altro account o un object storage. Per un NAS: un disco non basta; ti serve una copia fuori da quella stanza (incendio, furto, cryptolocker sul share).

Prova il restore. Un backup non provato è un file che occupa spazio.

Docker

Molti stack self-hosted sono Compose: un file, volumi, un proxy. Va bene. Non è un recinto magico. Root sul socket Docker è root sulla macchina. Le immagini si pinnano a un digest o a una versione, non a latest al buio. I volumi si backuppano, i container no.

Se Docker lo stai ancora imparando, leggi Docker per principianti prima di copiare un compose.yml da internet e esporlo.

Quando pagare qualcuno (o un servizio)

Paga un SaaS quando il danno di un'ora di down supera il canone annuo. Posta. Identità. Il gestionale. Tutto ciò che un cliente tocca e tu non vuoi spiegare.

Paga un sistemista (noi, o un altro) quando:

• il servizio è di lavoro, non un lab
• non hai tempo di aggiornare ogni settimana
• ti serve un disegno (rete, backup, accessi) non un container
• sei già sotto e stai googling l'errore con i clienti che aspettano

Non pagare per "mettere Nextcloud" se poi nessuno lo aggiorna. Stai comprando un problema con una fattura.

Problemi comuni

"Costa meno del cloud"

Conta tre anni: hardware o VPS, corrente, il tuo tempo, un restore, un incidente. A volte è vero. A volte stai confrontando un NAS da 300 euro con Microsoft 365 completo di posta e compliance. Non sono lo stesso prodotto.

"Lo metto in casa, è più sicuro"

In casa è più vicino. Non è più sicuro. Linea consumer, router con UPnP, PC nella stessa rete, backup assenti. Un VPS in datacenter con firewall stretto e backup offsite batte un NAS esposto. Un NAS solo in LAN, più VPN, è un altro discorso.

"Docker è abbastanza"

Docker semplifica il deploy. Non ti dà update, policy di accesso, né backup. Un Compose senza volumi nominati e senza dump è un giocattolo.

"Poi lo metto a posto"

La finestra in cui il servizio è su internet e la baseline no è quella in cui arrivano gli scanner. La baseline è il giorno zero, non il giorno dopo.

Quando ha senso, in sintesi

Self-hosting conviene quando il controllo sui dati vale le ore, e quando qualcuno (tu) accetta i guasti. VPS per siti e servizi piccoli. NAS per i file e i backup, non come bersaglio su internet. Cloud gestito per la posta e per ciò che deve restare in piedi senza di te.

La baseline non è opzionale: chiavi SSH, firewall, aggiornamenti, backup 3-2-1, Docker usato con testa. La posta, se non è il tuo mestiere, lasciala a chi la fa di mestiere. Se invece volete confrontare self-hosting e cloud sul vostro perimetro, il servizio è soluzioni cloud; lo stack che usiamo è in tecnologie / Docker.

Risorse utili (autorevoli):

• awesome-selfhosted - Elenco di software self-hostable, per categoria
• Debian Handbook — Security - Base di sicurezza su un server Debian
• Let's Encrypt - Certificati HTTPS, come funzionano e come si rinnovano
• CIS Benchmarks - Baseline di hardening, se ti serve un riferimento formale