Identità self-hosted con Zitadel: sovranità del dato e costi contro Auth0 e Okta

Il modello di prezzo di un identity provider gestito ha una caratteristica che lo rende insidioso da valutare: è quasi gratis quando lo provi e diventa la voce che nessuno aveva previsto quando funziona. Si paga per utente attivo mensile, e l'utente attivo mensile è esattamente la metrica che cresce se il tuo prodotto va bene. Chi valuta lo fa quando gli utenti sono duecento, e la cifra è irrilevante; il conto arriva quando sono cinquemila, cioè nel momento in cui il progetto ha avuto successo e cambiare fornitore di identità è l'ultima cosa che vuoi fare.

Nei primi due articoli di questa serie ho spiegato il modello con cui Zitadel organizza identità e autorizzazioni e perché l'ho scelto al posto di Keycloak. Entrambi davano per scontata una decisione che invece va motivata, ed è quella che affronto qui: perché self-hostare l'identity provider invece di comprarlo come servizio. È l'ultimo dei tre articoli introduttivi; dal prossimo si entra nel codice e nell'infrastruttura.

Metto le mani avanti su una cosa, perché gli articoli su questo tema sono quasi sempre partigiani: il self-hosting non è gratis e non è per tutti. Ha un costo, è composto di voci diverse da quelle di un abbonamento, e in alcuni scenari perde nettamente il confronto. Alla fine dell'articolo c'è una sezione su quando comprare è la scelta corretta, e non è una concessione di cortesia.

Perché il costo di un identity provider si scopre sempre troppo tardi?

Perché la metrica di fatturazione è disaccoppiata dal valore che ricevi. Paghi per utenti attivi mensili, ma il lavoro che l'identity provider fa per te è lo stesso a duecento e a cinquemila utenti: verifica credenziali, emette token, applica il secondo fattore. Il costo cresce linearmente con il tuo successo mentre il servizio reso resta costante, e questo crea uno scarto che si allarga nel tempo.

C'è poi una seconda ragione, meno ovvia e più costosa: al momento della valutazione stai confrontando le cose sbagliate. Confronti il canone del gestito con il prezzo di un server, dimenticando le ore, oppure confronti il canone con zero, dimenticando che quel canone comprende anche l'aggiornamento, il monitoraggio e la reperibilità di qualcuno alle tre di notte. Il confronto corretto ha tre voci per parte e va fatto su un orizzonte di tre anni, perché è la vita utile realistica di una scelta di questo tipo.

I prezzi di listino, alla data in cui scrivo

Comincio dai numeri del gestito, verificati sulle pagine ufficiali e non a memoria, perché è un campo in cui i listini cambiano e citare a memoria significa pubblicare una cifra falsa.

Auth0 (listino ufficiale) resta gratuito fino a 25.000 utenti attivi mensili, che è una soglia generosa e copre interamente molti progetti. Sopra quella soglia, il piano Essentials parte da 35 USD al mese per 500 utenti attivi nel profilo B2C e da 150 USD nel profilo B2B; il piano Professional, che è quello che serve quando ti occorrono cose come l'autenticazione multi-fattore avanzata o i domini personalizzati, parte da 240 USD al mese in B2C e da 800 USD in B2B. La fatturazione annuale corrisponde a undici mensilità, quindi un mese in omaggio se ti impegni per l'anno.

Okta (listino ufficiale) ha un impianto diverso, orientato all'azienda: la linea Workforce va da 6 a 17 USD per utente al mese a seconda dei moduli, con un minimo contrattuale di 1.500 USD l'anno; la linea Customer Identity nella versione Enterprise parte da 3.000 USD al mese. È un prodotto che non punta alla PMI e il listino lo dichiara apertamente.

Tutti questi valori sono in dollari, sono al netto delle imposte e sono rilevati alla data di questo articolo: vanno riverificati prima di costruirci sopra un business case, perché è materiale che invecchia in fretta.

Il ragionamento che ne esce, per una PMI italiana con qualche centinaio di utenti interni e qualche migliaio di clienti finali, è meno banale di quanto sembri: sotto i 25.000 utenti attivi Auth0 può costare zero, e chiunque ti dica che il gestito è sempre caro non ha guardato il listino. La cifra diventa significativa quando superi la soglia gratuita o quando ti servono funzionalità che stanno solo nei piani alti, e a quel punto la crescita è rapida.

Quanto costa la macchina che regge l'alternativa

Dall'altra parte del confronto c'è un server. Zitadel dichiara requisiti bassi per un'istanza standard, nell'ordine di circa 512 MB di RAM e meno di un core, perché il binario è stateless e tutto lo stato vive in PostgreSQL; per un cluster in alta disponibilità il riferimento sale a tre nodi da 4 core e 16 GB. Sono numeri che vale la pena tradurre in listino reale, con la precisione che questo tipo di affermazione richiede.

Sul listino europeo di Hetzner rilevato il 25 luglio 2026, IVA esclusa, per le location tedesche e finlandesi, una CX23 costa 5,49 EUR al mese e una CX33 8,49 EUR; salendo alle Arm64, una CAX21 costa 10,49 EUR e una CAX31 20,99 EUR. Una singola istanza Zitadel con il suo PostgreSQL su una macchina di fascia bassa sta comodamente dentro le prime due righe.

Un avvertimento che vale più della cifra: Hetzner ha applicato un repricing pesante il 15 giugno 2026, con aumenti che sulle linee a vCPU dedicata arrivano al 169 per cento, e i prezzi che ricordi da un articolo dell'anno scorso sono semplicemente falsi. Una CCX13, che prima stava a 15,99 EUR, oggi è a 42,99 EUR al mese. E i listini sono separati per zona: gli stessi piani nelle region statunitensi o a Singapore hanno prezzi diversi ed espressi in dollari. Se stai costruendo un business case, prendi i numeri dal configuratore nel giorno in cui lo scrivi.

Per un'infrastruttura cloud europea self-managed con un buon rapporto fra prezzo e prestazioni e con i dati che restano in datacenter dell'Unione, Hetzner resta il riferimento che uso più spesso, con le location di Falkenstein, Norimberga e Helsinki. Vale però la regola che applico a ogni fornitore: il prezzo va letto sul configuratore alla data in cui firmi, non su un articolo.

Anche prendendo la fascia più prudente, con due macchine per la ridondanza e un database gestito separatamente, si resta in un ordine di grandezza di poche decine di euro al mese. Confrontata con 240 USD al mese di un piano Professional, la macchina è rumore di fondo. Ed è precisamente qui che la maggior parte delle analisi si ferma, dichiarando vittoria. È anche il punto in cui diventano sbagliate.

La voce che manca in tutti i confronti

Il costo vero del self-hosting non è il server: sono le ore. E le ore hanno una tariffa.

Vanno messe a bilancio l'installazione iniziale, che è un lavoro finito e ben delimitato; gli aggiornamenti, che per Zitadel seguono un ritmo di una major ogni tre mesi e che vanno applicati, non accumulati; il monitoraggio, perché un identity provider che non risponde blocca l'accesso a tutto il resto e devi accorgertene tu prima dei clienti; i backup e, cosa che quasi nessuno fa, la prova periodica di ripristino, perché un backup mai ripristinato non è un backup ma una speranza. E va messa a bilancio la voce più scomoda, cioè la reperibilità: qualcuno deve saper intervenire quando succede, e se quel qualcuno è una persona sola hai un problema di continuità che nessun contratto di manutenzione risolve.

Se metti tutto questo in un modello a tre anni, la conclusione cambia forma. Il self-hosting non vince sul costo assoluto: vince sulla prevedibilità del costo. Un abbonamento per utente attivo cresce con il successo del tuo prodotto in modo che non controlli; un server più qualche ora al mese è una cifra che conosci in anticipo e che non si muove se domani raddoppi gli utenti. Per una PMI che deve fare un budget, la seconda è spesso più preziosa della prima anche quando l'importo è simile, e questo è un argomento che ho visto convincere direttori finanziari molto più di qualunque considerazione tecnica.

C'è poi un beneficio che non compare in nessun foglio di calcolo e che nell'esperienza pesa: quando l'identity provider è tuo, il tempo di risoluzione di un problema dipende da te. Nell'integrazione da cui viene questa serie, per un operatore di posta elettronica gestita multi-tenant, la possibilità di aggiungere una seconda applicazione al progetto e provare un flusso in dieci minuti, senza aprire un ticket e senza aspettare una finestra di supporto, ha accorciato l'intero progetto in modo che non saprei quantificare ma che chiunque abbia atteso tre giorni una risposta di secondo livello riconoscerà.

Se stai facendo questa valutazione per la tua azienda e vuoi che i numeri li metta insieme qualcuno che ha portato in produzione entrambe le architetture, nel mio profilo professionale trovi il percorso su infrastruttura self-managed, migrazioni e gestione di VPS in ambito europeo.

Il confronto messo in tabella, su tre anni

Le tabelle di costo mentono quasi sempre per omissione, quindi questa la costruisco dichiarando le ipotesi invece di nasconderle. Scenario: una PMI italiana con circa 3.000 utenti attivi mensili, secondo fattore obbligatorio per tutti, due applicazioni da federare, nessun requisito di certificazione esterna. Le ore sono valorizzate a una tariffa di consulenza esterna, che è l'ipotesi peggiore per il self-hosting: se hai un sistemista interno, il costo marginale è più basso.

La lettura corretta di questa tabella non è "quale colonna ha il totale più basso". È quale delle due righe in fondo pesa di più nel tuo contesto. Se il tuo vincolo è il budget prevedibile a tre anni o la collocazione del dato, la colonna di destra vince anche a parità di totale. Se il tuo vincolo è non avere nessuno da mettere sulla riga della reperibilità, la colonna di sinistra vince anche costando il doppio.

Il costo di uscita, che è l'unico che si paga due volte

C'è una voce che non sta in nessuna delle due colonne perché non è ricorrente, e che è la ragione per cui questa decisione va presa con attenzione anche quando gli importi sembrano piccoli: quanto costa cambiare idea.

Da un servizio gestito porti via gli utenti con i loro attributi, e questo di norma funziona. Non porti via due cose. La prima sono le password: sono hash, e il fornitore di destinazione deve saperli verificare con lo stesso algoritmo e gli stessi parametri, altrimenti la migrazione diventa un reset di massa, cioè una comunicazione a tremila persone e un picco di richieste all'assistenza concentrato in due giorni. Alcuni fornitori offrono una migrazione progressiva che riscrive l'hash al primo accesso riuscito, ed è l'unica strada indolore: verificare se c'è, prima di entrare, vale più di uno sconto sul canone.

La seconda cosa che non porti via sono i fattori di autenticazione registrati. Chi ha configurato un'applicazione di codici temporanei o una chiave hardware deve rifare l'operazione, e nel caso di una base utenti non tecnica questo è il vero costo del cambio: non è tecnico, è di supporto e di comunicazione.

C'è poi il pezzo che genera i bug silenziosi, ed è lo stesso che ho descritto parlando del passaggio fra due prodotti self-hosted: l'identificativo dell'utente cambia. Il claim che le tue applicazioni hanno salvato per legare l'identità esterna al record locale è generato dall'identity provider, e con il fornitore nuovo è un altro. Serve una tabella di corrispondenza fra una chiave che possiedi tu e il nuovo identificativo, applicata a ogni ambiente in modo coerente, che è esattamente il lavoro che descrivo nel pezzo sulla sincronizzazione delle identità fra ambienti. La contromisura costa poco e va presa il primo giorno: non usare mai l'identificativo dell'identity provider come chiave primaria applicativa.

La simmetria è la parte interessante. Questo costo esiste in entrambe le direzioni, e in misura molto simile: uscire da un gestito e abbandonare un self-hosted si somigliano più di quanto le due tifoserie ammettano. La differenza è che nel self-hosting il momento in cui te ne vai lo decidi tu, mentre con un fornitore può deciderlo lui, cambiando listino o ritirando un piano. Non è un argomento decisivo, ma è la cosa più onesta che si possa dire sul lock-in.

Sovranità del dato: cosa cambia davvero, al netto della retorica

Su questo punto si dicono molte cose vaghe, quindi provo a essere concreto su cosa cambia e cosa no.

Cosa non cambia: usare un fornitore statunitense non è di per sé illegittimo, e i meccanismi di trasferimento esistono. Chi ti racconta che il cloud americano è vietato ti sta vendendo qualcosa.

Cosa cambia davvero è la collocazione del dato più sensibile che hai. Nel database di un identity provider ci sono l'elenco completo delle persone che accedono ai tuoi sistemi, i loro indirizzi, gli hash delle password, i fattori di autenticazione registrati e lo storico di ogni accesso: nome, orario, indirizzo di provenienza. È una base dati che descrive comportamenti di persone fisiche, ed è materiale che in una valutazione d'impatto pesa più della maggior parte dei sistemi aziendali. Tenerla su una macchina che controlli, in una giurisdizione che conosci, semplifica quella valutazione invece di richiedere un capitolo dedicato.

Il secondo aspetto è la continuità. Un fornitore può cambiare listino, cambiare condizioni, essere acquisito, uscire da un mercato o interrompere un piano. Con un'istanza che ospiti tu il rischio non sparisce, si sposta: diventa il rischio che il progetto open source rallenti, che è più lento e più visibile. È una sostituzione di rischi, non un'eliminazione, ed è onesto presentarla così.

C'è infine il piano normativo, che per molte PMI italiane sta diventando la ragione principale. La direttiva NIS2 e il suo recepimento italiano hanno portato requisiti espliciti su controllo degli accessi e autenticazione a più fattori dentro il perimetro delle misure di base, con scadenze che stanno arrivando: le misure fondamentali vanno completate entro il 31 ottobre 2026, e dopo quella data l'Agenzia per la cybersicurezza nazionale entra nella fase ispettiva. Se non sai se la tua azienda rientra nel perimetro, il mio strumento di autovalutazione NIS2 risponde in sette domande, e la risposta cambia radicalmente il peso di questa sezione. Il rapporto fra secondo fattore, sistemi legacy e obblighi normativi è il tema del pezzo su 2FA e NIS2 applicati a un sistema di posta.

Quando comprare è la scelta giusta

Ci sono tre situazioni in cui consiglio il gestito senza esitazione, e le elenco perché una comparativa che conclude sempre a favore di una parte non è una comparativa.

Non hai chi lo gestisce, e non lo avrai. Se non c'è nessuno in azienda che possa applicare un aggiornamento e leggere un log, un identity provider self-hosted è un rischio, non un risparmio: diventerà una macchina non aggiornata che regge l'accesso a tutto, che è lo scenario peggiore in assoluto. Meglio un canone.

Sei sotto la soglia gratuita e ci resterai. Con meno di 25.000 utenti attivi mensili e requisiti ordinari, Auth0 costa zero e ti dà un servizio che funziona. Costruire infrastruttura per sostituire qualcosa che non paghi è una decisione che va motivata con argomenti diversi dal costo, e possono esserci, ma vanno detti.

Ti servono certificazioni che non puoi produrre. Se un tuo cliente enterprise ti chiede evidenza di conformità a uno schema specifico sull'infrastruttura di identità, comprare quella conformità da un fornitore che la ha già è più veloce ed economico che ottenerla su un impianto tuo. Vale la pena distinguere: la conformità della tua organizzazione resta tua in ogni caso, quello che compri è l'attestazione su un pezzo di infrastruttura, e su quel pezzo specifico un fornitore che serve migliaia di clienti ha economie di scala che tu non avrai mai.

L'identità non è il tuo mestiere e il progetto ha una scadenza. È il caso meno tecnico e il più frequente. Se devi consegnare un prodotto fra tre mesi e l'autenticazione è un requisito da spuntare, non il cuore di ciò che vendi, comprare tempo con un canone è una decisione di allocazione corretta. Il self-hosting si valuta al secondo giro, quando il prodotto esiste, i volumi sono noti e la scelta si può fare con dati invece che con stime. Cambiare in quel momento costa quello che ho descritto nella sezione precedente, ed è un costo che va messo in conto fin dall'inizio invece di scoprirlo dopo: se sai già che il self-hosting arriverà, tieni sottile lo strato di integrazione fin dal primo giorno e la migrazione sarà un fine settimana invece di un trimestre.

Fuori da questi tre casi, e in particolare quando hai già competenze sistemistiche in casa o un fornitore che le porta, il self-hosting di un identity provider moderno è oggi molto meno oneroso di quanto la sua reputazione suggerisca. Il prossimo articolo della serie mostra esattamente quanto: l'installazione in produzione su Debian, senza container, con le configurazioni reali e l'unità di sistema che regge un audit, che è il momento in cui la stima delle ore smette di essere un'ipotesi. Nell'esperienza che ho maturato la parte davvero impegnativa non è nemmeno quella: è decidere il modello prima di installare, ed è per questo che questa serie è partita da lì invece che dal comando di installazione. Se stai valutando la scelta adesso e vuoi un parere che parta dai tuoi numeri e non dai miei, scrivimi e ne parliamo.