Una sera di gennaio, casa di Calcinaia, fuori sette gradi e umido. Sono in macchina di ritorno da una riunione a Pisa, esco dal casello e apro Google Calendar al volo per controllare l’agenda di domani. Mia moglie ha bloccato un appuntamento dal pediatra alle 8:30, quindi resta a casa dopo le 22:30, niente palestra di gruppo. Trenta secondi dopo, mentre sono ancora in tangenziale, il termostato di casa parte da solo: Home Assistant ha letto il calendario condiviso, ha visto che alle 22:30 saremo entrambi a casa, ha calcolato che con sette gradi esterni servono circa quaranta minuti per portare il salotto da 17 a 21 gradi, e ha acceso la caldaia. Quando entro alle 22:25, casa è alla temperatura giusta. Niente app aperta, niente comando vocale, niente assistente cloud che ascolta. Solo tre servizi self-hosted che parlano tra loro su una rete che possiedo io. Negli altri post di Workshop racconto altre scelte tecniche di Romiltec. Qui parlo dei tre che, fuori dall’ufficio, mi tengono autonomo.
Premessa metodologica. Non è un articolo “10 self-hosted che devi provare”. I servizi self-hosted scaricabili da GitHub sono migliaia. La domanda interessante non è “quale provo”, è “quale uso davvero da almeno un anno, in produzione personale e di team, senza tornare al SaaS equivalente?”. Su questo metro, dei trenta che ho provato negli ultimi anni, ne sono rimasti tre. Sono questi.
Vaultwarden: le password stanno sul device, il server le sincronizza
Vaultwarden è un’implementazione open-source del backend Bitwarden, scritta in Rust, leggera, compatibile con i client ufficiali (browser extension, app iOS/Android, desktop). Lo trovi sul progetto upstream dani-garcia/vaultwarden. Gira in un container Docker da circa 50 MB di RAM in idle, con un volume persistente per il database SQLite dove tiene le password cifrate.
La domanda che mi è stata fatta più spesso, quando ho iniziato a raccontarlo: perché non Bitwarden cloud direttamente? La risposta tecnica, non polemica, è duplice. Primo, sovranità del dato: le password della mia famiglia e del team Romiltec stanno su un container che gira su una mia LXC in casa, non su un servizio gestito da terzi in giurisdizioni che non controllo. Secondo, costo prevedibile: il piano Bitwarden Families costa una cifra annuale per dieci utenti, Vaultwarden costa il consumo elettrico del Pi su cui gira, ovvero cinque-otto euro l’anno.
Il dettaglio tecnico più importante, che chi non si è mai fermato a leggere la documentazione del modello Bitwarden non sa, è questo: le password stanno sul device, non sul server. Il client (browser, app) tiene un vault locale cifrato con una chiave derivata dalla master password via PBKDF2. Il server Vaultwarden riceve solo blob cifrati, non vede mai nulla in chiaro, e il suo unico ruolo è sincronizzare quei blob tra i device dello stesso utente. Se il server muore, non perdo le password: sono sui miei tre device. Il backup del server è un nice-to-have, non un single point of failure.
Il setup operativo l’ho fatto via uno script LXC della community Proxmox, di quelli che trovi su community-scripts.github.io/ProxmoxVE/scripts, eredi del lavoro di tteck. Una riga di shell sul nodo Proxmox, due minuti di download, quattro-cinque domande di setup (utente admin, dominio, certificato), e Vaultwarden è up. Davanti ho messo un Caddy come reverse proxy con TLS DNS-01 via Cloudflare, e l’accesso interno passa da Tailscale: niente esposizione del Vaultwarden su internet pubblico, l’accesso è solo da device che hanno la chiave Tailscale del mio tenant.
Il compromesso onesto. Vaultwarden non ha l’organizzazione enterprise pulita di Bitwarden Teams: i ruoli, le policy di password complexity gestite da admin, le integrazioni SSO con identity provider sono o assenti o semplificate. Per cinque persone che si fidano vicendevolmente e operano sotto un’unica policy informale, va benissimo. Per un’azienda da cinquanta persone con compliance ISO27001 dichiarata, probabilmente la versione cloud gestita da Bitwarden con SLA è la scelta giusta. Self-hosted non è il default per tutti: è il default per chi ha la sensibilità tecnica e la dimensione operativa giusta.
Un episodio reale di degradazione. L’estate scorsa la mia connessione fibra di casa è andata su una rete temporanea (lavori in strada, redirect su una linea backup) e Vaultwarden è diventato sostanzialmente irraggiungibile dall’esterno per quattro ore. Per quattro ore non ho potuto sincronizzare un nuovo segreto su un device. I device che già avevano il vault locale hanno continuato a funzionare normalmente, solo l’accesso alle password salvate ha continuato a girare. Lì ho capito a livello operativo cosa significa “le password stanno sul device”: il blackout del server è un fastidio di sincronizzazione, non un’emergenza. Da lì ho aggiunto un secondo backup del database Vaultwarden via restic verso B2, in modo che anche un wipe del nodo Proxmox principale fosse recuperabile in minuti.
n8n: il workflow di onboarding cliente che era quattro step manuali
n8n (github.com/n8n-io/n8n) è un workflow automation engine self-hosted, alternativa diretta a Zapier e Make. Gira in container, ha un editor visuale a nodi, supporta webhook in ingresso, integrazioni native con un paio di centinaia di servizi, scripting JavaScript dentro i nodi, e usa Postgres o SQLite come storage dei workflow e degli execution log.
Sono arrivato a n8n perché avevo accumulato quattro automazioni piccole su Make e Zapier, ognuna su un account diverso, ognuna a un costo mensile basso ma fastidioso, e nessuna documentata bene. Il caso d’uso che ha forzato la migrazione è stato l’onboarding di un nuovo cliente editoriale a Romiltec. Il flusso, prima, era: il commerciale (cioè io) riceveva la conferma firmata, apriva un task su Linear, creava il repo GitLab del progetto, generava le credenziali iniziali su Vaultwarden, mandava la welcome mail al cliente con i link giusti. Quattro step manuali, dieci minuti se andava liscio, mezz’ora se ne saltavo uno e dovevo tornare indietro.
Il workflow n8n che lo gestisce oggi è un singolo grafo a sette nodi: webhook in ingresso da un form Tally compilato dal cliente, validazione dei campi via JavaScript, chiamata API a Linear per creare il progetto, chiamata API a GitLab per il repo, chiamata API a Vaultwarden via il suo bw cli per generare un’organization e un set di credenziali, scrittura su Postgres di una riga di tracciamento, mail SMTP via il nostro server di posta interno con i link a tutto. Il commerciale (sempre io) riceve a quel punto solo una notifica Mattermost che il cliente è onboardato, e devo solo controllare che sia tutto corretto.
Il tempo sceso da dieci minuti a zero non è quello che mi interessa di più. Quello che mi interessa è che il flusso è documentato, ed è il workflow stesso a essere la documentazione: il grafo dei nodi è leggibile, ogni nodo ha il suo contesto, gli execution log mostrano esattamente dove un’esecuzione è fallita e con quale payload. Quando ho dovuto passare il workflow a un dev junior del team perché modificasse uno step, gli ho mandato il link al canvas n8n e lui ha capito tutto in venti minuti. Su Make o Zapier, la stessa operazione richiedeva un walkthrough video.
Il compromesso onesto. n8n self-hosted ha alcuni rough edge che la versione cloud commerciale non ha: i template della community non sono curati come quelli ufficiali, alcuni connector hanno dipendenze native (per esempio Puppeteer per scraping) che vanno installate a parte nell’immagine, gli upgrade tra versioni minor occasionalmente cambiano il formato di nodi specifici e ti tocca riconfigurarli. Niente di drammatico, ma serve disciplina di backup pre-upgrade e di leggere il changelog. Su Zapier o Make queste cose sono trasparenti perché paghi per non vederle.
Le integrazioni con webhook + Postgres sono il caso d’uso dove n8n brilla davvero. Per chi ha già un Postgres in casa (e chiunque abbia un’infrastruttura WordPress decente ne ha uno o due), n8n diventa il livello di orchestrazione naturale tra eventi web e logica applicativa, senza dover scrivere un piccolo backend Node a parte. È esattamente lo stesso pattern che ho insegnato al team interno: prima di scrivere un microservizio per orchestrare due API, valuta se un workflow n8n con i due connector e un nodo Code basta. Nove volte su dieci basta.
Home Assistant: domotica, presenza, voice assistant locale
Home Assistant è il sistema operativo della mia casa da fine 2018. Gira su Home Assistant OS dentro una VM Proxmox da 4 GB di RAM e 32 GB di disco, ha integrato circa una sessantina di entità (luci, termostato, sensori temperatura per stanza, sensori di apertura porte e finestre, presenza Bluetooth dei device di famiglia, calendario condiviso, meteo locale), e gestisce una ventina di automazioni che hanno coperto tutta la mia casa.
Le tre automazioni che uso davvero, fuori da quella iniziale del termostato:
La prima: presenza basata su Bluetooth + GPS dei telefoni di famiglia. Quando l’ultimo telefono lascia la zona “casa” definita su mappa, Home Assistant aspetta cinque minuti di buffer (per evitare falsi positivi sul GPS), poi spegne tutte le luci, abbassa il termostato di tre gradi, attiva la modalità “casa vuota” sul sistema di allarme. Quando il primo telefono rientra in zona, dieci minuti prima dell’arrivo stimato accende le luci dell’ingresso e riporta il termostato in modalità comfort. Niente app, niente comando, niente cloud.
La seconda: integrazione calendario per le routine di scuola dei miei figli. Su un calendario condiviso “scuola” ho gli appuntamenti di prelievo e accompagnamento. Home Assistant li legge, e se vede che alle 7:45 c’è un evento “scuola figlia 1”, alle 7:00 alza le tapparelle in cameretta, alle 7:15 accende le luci del bagno, alle 7:30 alza la temperatura del soggiorno di un grado e mezzo. Niente sveglia rotta, niente discussioni la mattina su chi alza le tapparelle.
La terza, che è quella che mi ha portato a riscriverne mezza dopo l’arrivo dell’AI on-premise: voice assistant locale via Whisper. Whisper è il modello di speech-to-text di OpenAI, il modello standard pesa quattro GB, ha un’accuratezza superiore al 99% sull’italiano e altre lingue principali. L’ho integrato in Home Assistant via la pipeline Assist con un piccolo modello di intent recognition (tre miliardi di parametri, gira sulla CPU del nodo Proxmox in cui sta Home Assistant) e ho un voice assistant da cucina che capisce comandi in italiano, esegue automazioni locali, non manda mai una sola sillaba a server esterni. Confrontato con Alexa di tre anni fa è notte e giorno: capisce meglio l’italiano regionale, è offline, non monetizza la mia voce.
Il compromesso onesto. Home Assistant è un sistema in cui devi entrare. La curva iniziale è ripida: YAML per le automazioni avanzate, Lovelace per le dashboard, gestione dei device via integrazioni che ogni tanto cambiano breaking. Le prime due settimane di setup richiedono cinque-dieci ore di letture e configurazione. È il prezzo di avere un sistema che ti appartiene davvero. Per chi vuole “accendi luce con l’app del produttore” e basta, Home Assistant è troppo. Per chi vuole costruire una casa che si adatta alla propria vita, è esattamente quello che serve.
Una cosa che ho imparato sul voice assistant: Whisper ha un costo computazionale nontrivale ma costante, mentre i piccoli LLM per l’intent recognition vanno scelti con cura. Un modello da sette miliardi di parametri sulla CPU del nodo Proxmox aspirava troppo. Sono sceso a un modello da tre miliardi quantizzato, ho perso un po’ di accuratezza sui comandi complessi, ma ho recuperato latenza accettabile (~800 ms tra fine voce e azione). Il punto chiave, lo stesso del talk al meetup di Pisa: il modello deve girare in modo fluido sulle risorse che hai, non vicino al limite. Se gira al limite, il sistema diventa instabile alla prima richiesta in più.
La filosofia: self-hosted non è anti-SaaS, è opt-in al SaaS
C’è una posizione diffusa in certi ambienti tech che mette self-hosted e SaaS come opposti morali. Self-hosted = libertà, SaaS = lock-in. Non è la mia posizione, e dopo dieci anni di entrambi posso dirlo con tranquillità.
Self-hosted ha senso quando hai la sensibilità tecnica per gestirlo, quando il TCO totale (tempo tuo incluso) è inferiore al SaaS equivalente, e quando il dato che custodisce ha un valore di sovranità reale per te. Vaultwarden custodisce le password della famiglia: il valore di sovranità è massimo. n8n orchestra l’onboarding clienti: il valore di sovranità è alto perché tocca dati cliente. Home Assistant gestisce la presenza fisica della mia famiglia in casa: il valore di sovranità è enorme.
SaaS ha senso quando il tempo tuo costa più della tariffa, quando la complessità operativa è oltre la sensibilità tecnica del tuo team, e quando il dato non ha valore di sovranità particolare. Per la fatturazione elettronica uso Aruba FE: non self-hosto un sistema di emissione fatture, sarebbe assurdo. Per il commercialista uso Fatture in Cloud: non sviluppo un ERP. Per la gestione progetti del team uso Linear: non sostituisco con un OpenProject self-hosted, perché il tempo che salvo non vale la cura.
Self-hosted non è un’ideologia. È un mestiere. Uno dei tre o quattro mestieri che un piccolo team tech deve avere se vuole tenere autonomia tecnica vera. Senza, il team è un assemblatore di servizi gestiti da terzi, e la sua sopravvivenza dipende dalle decisioni di altri.
Cosa porto a casa
Tre cose, anche qui.
Una. I tre servizi self-hosted che mi sono rimasti dopo cinque anni di tentativi sono quelli che gestiscono dati con valore di sovranità alto e che hanno un costo operativo basso. Non è coincidenza: è il filtro corretto per decidere cosa self-hostare.
Due. Il setup iniziale di un servizio self-hosted è il 20% del lavoro. L’80% sta nel mantenimento: backup, snapshot, upgrade, monitoring. Senza disciplina di mantenimento, un servizio self-hosted in due anni diventa un debito tecnico privato. Con la disciplina, diventa infrastruttura propria, prevedibile, autonoma.
Tre. Self-hosted bene fatto restituisce due cose a un piccolo team: autonomia tecnica concreta (sai cosa gira, sai cosa fa, sai dove sta il dato) e un piano di costi prevedibile (consumi elettrici stabili, niente sorprese di pricing change al rinnovo annuale). Sono due asset che valgono più del piccolo premio operativo che paghi rispetto a un SaaS gestito.
La caldaia adesso è ancora accesa, sono le 23:10, casa è a 21 gradi, mia moglie sta leggendo, le bambine dormono. Tre servizi che girano in silenzio, su tre macchine in cantina e in salotto, e una sera normale di gennaio che funziona come ti aspetti. È quello che si chiama “infrastruttura che fa il suo lavoro”, e la sera in cui non ci pensi più è la sera in cui ha smesso di essere un progetto e ha iniziato a essere casa tua.