Come eseguire il self-hosting di Vaultwarden nel 2026: domini, SMTP e backup sicuri

Esistono due versioni del “mettere in esecuzione Vaultwarden”: esiste un container oppure il servizio completa davvero il proprio lavoro. Solo la seconda conta. La verifica consiste nell'accedere da un'estensione del browser, creare un elemento, sincronizzare un secondo client, caricare un allegato e recuperare un Send dopo un riavvio.

Vaultwarden serve proprio a questo: un server compatto per le password compatibile con Bitwarden. Il deployment deve preservare i componenti alla base di questo comportamento; una porta, un volume e un certificato sono input, non il risultato.

I volumi sono solo il primo livello di ripristino

L'insieme dei dati necessari per un ripristino affidabile comprende il database, gli allegati, i Send, le chiavi e la configurazione in /data. Monta /data prima del bootstrap, scrivi dati di esempio innocui e sostituisci il container per verificare che quel percorso sia realmente persistente. Un volume protegge i dati dalla sostituzione del container, ma non dalla perdita dell'host, dalla cancellazione accidentale o dalla corruzione a livello applicativo.

Esegui backup che tengano conto della sorgente dei dati: quando necessario, usa dump logici per i database attivi e copia i file solo da uno stato coerente. Conserva una copia crittografata lontano dall'host di Vaultwarden. Il criterio di accettazione per un ripristino è specifico: gli elementi del vault, gli allegati, i Send e l'appartenenza all'organizzazione devono sincronizzarsi correttamente con un client pulito dopo il ripristino. La guida ai backup verificati tramite ripristino spiega perché il solo esito positivo del job non è sufficiente.

Avviare Vaultwarden senza nascondere i componenti

Avvia Vaultwarden in modo da mantenere privata la route fino al completamento del bootstrap.

docker run -d \
  --name vaultwarden \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v vaultwarden-data:/data \
  -e ADMIN_TOKEN=replace-with-a-long-random-value \
  vaultwarden/server:latest

Se il processo entra in un loop, confronta l'utente previsto dall'immagine con il proprietario di ogni percorso montato. Se rimane attivo, verifica localmente la porta 80 e passa subito al workflow: accedi da un'estensione del browser, crea un elemento, sincronizza un secondo client, carica un allegato e recupera un Send dopo un riavvio. Fissa la versione dell'immagine solo dopo che questo controllo end-to-end è andato a buon fine e registra la configurazione esatta accanto al servizio.

Definire il perimetro di runtime di Vaultwarden

Definisci tre confini attorno a Vaultwarden: l'ingress verso la porta 80, lo stato persistente e i requisiti di supporto. Il container è sostituibile, ma gli altri due elementi devono avere proprietari espliciti. Il requisito esterno di Vaultwarden è un SMTP funzionante se sono necessarie le email per gli inviti e l'accesso di emergenza. Verifica il DNS in uscita, il TLS e il comportamento del provider senza pubblicare un altro servizio in ingresso.

Il diagramma è completo quando un client pulito riesce ad accedere da un'estensione del browser, creare un elemento, sincronizzare un secondo client, caricare un allegato e recuperare un Send dopo un riavvio. Raccogli dati su tempi e risorse relativi al volume degli allegati, alla contesa di scrittura di SQLite o ai limiti del connection pool del database, oltre alla latenza SMTP durante gli inviti. Se la transazione fallisce, il primo confine che non si comporta come documentato indica se occorre analizzare il routing, la capacità locale o un servizio di supporto.

Distinguere correttamente gli URL interni da quelli esterni

Evita di usare origini pubbliche temporanee e definitive per Vaultwarden. Imposta invece DOMAIN sull'origine HTTPS esterna esatta, punta il nome DNS scelto alla route della piattaforma e fai proxy solo verso la porta 80.

Esegui questa operazione dall'esterno dell'host: accedi da un'estensione del browser, crea un elemento, sincronizza un secondo client, carica un allegato e recupera un Send dopo un riavvio. Se l'ingress fallisce, la guida alla risoluzione dei problemi 502 tratta gli errori relativi a porte e listener. Se Vaultwarden riceve la richiesta ma DOMAIN è HTTP mentre il browser richiede un'origine sicura per le funzionalità del vault, gli elementi raccolti indicano ora un problema oltre il proxy.

Verifica di accettazione in produzione per Vaultwarden

Un gate di produzione per Vaultwarden deve poter essere eseguito da una persona che non ha realizzato il deployment. Fornisci a questa persona la versione fissata, un account di test non sensibile e questa attività: accedere da un'estensione del browser, creare un elemento, sincronizzare un secondo client, caricare un allegato e recuperare un Send dopo un riavvio. Se le istruzioni richiedono un accesso shell non documentato, il servizio non è ancora pronto dal punto di vista operativo.

Ripeti il gate dopo aver sostituito solo il container. Poi ripristina il database, gli allegati, i Send, le chiavi e la configurazione in /data su un'infrastruttura vuota e dimostra che gli elementi del vault, gli allegati, i Send e l'appartenenza all'organizzazione si sincronizzano correttamente con un client pulito dopo il ripristino. Misura il volume degli allegati, la contesa di scrittura di SQLite o i limiti del connection pool del database e la latenza SMTP durante gli inviti in entrambe le esecuzioni riuscite; differenze inattese spesso rivelano una cache, un indice, un worker o un mount dei dati mancanti.

Aggiungi un failure drill: nega temporaneamente il percorso di test usato dall'SMTP funzionante quando sono necessarie le email per gli inviti e l'accesso di emergenza. Vaultwarden dovrebbe produrre un errore utile, preservare lo stato esistente e recuperare quando la condizione valida torna disponibile. Salva i timestamp e le righe di log pertinenti, oscurando i segreti. Questa evidenza diventerà il riferimento per la successiva modifica dell'immagine o della configurazione.

Monitorare il workload, non solo il container

Un container in stato green è necessario, ma non sufficiente. L'indicatore a livello di servizio è il completamento riuscito di “accedere da un'estensione del browser, creare un elemento, sincronizzare un secondo client, caricare un allegato e recuperare un Send dopo un riavvio”, mentre i probabili segnali di pressione sono il volume degli allegati, la contesa di scrittura di SQLite o i limiti del connection pool del database e la latenza SMTP durante gli inviti.

Il change control è importante perché le migrazioni del database di Vaultwarden e la compatibilità dei client Bitwarden devono essere verificate insieme; la rotazione di ADMIN_TOKEN è una modifica all'accesso amministrativo, non una migrazione dei dati del vault. Conserva la vecchia immagine, testa le migrazioni su uno stato copiato e documenta se il rollback è supportato dopo lo spostamento dello schema. Se DOMAIN è HTTP mentre il browser richiede un'origine sicura per le funzionalità del vault, individua il primo confine che differisce dall'ambiente funzionante.

Chiudere l'accesso temporaneo alla configurazione

Un deployment sicuro di Vaultwarden inizia rimuovendo i privilegi. Evita di usare un admin token debole o di lasciare aperte le registrazioni; disabilita invece le registrazioni aperte al termine dell'enrollment, proteggi la pagina di amministrazione con un token forte e richiedi HTTPS per ogni client del vault.

Sostituisci immediatamente l'ADMIN_TOKEN di esempio, conservalo al di fuori dell'immagine e ruotalo come una credenziale amministrativa se viene esposto. Limita le route amministrative, usa un DNS privato per le dipendenze e controlla ogni bind mount. Quando i log vengono inviati centralmente, filtra i segreti e i contenuti privati prima che lascino il server.

Usare Dockup per il platform layer

Dockup elimina il lavoro manuale relativo al reverse proxy e al lifecycle attorno a Vaultwarden. Durante le sostituzioni, il servizio riceve una route HTTPS stabile verso la porta 80, la configurazione iniettata e lo storage persistente. Un server cliente collegato segue lo stesso modello del compute gestito da Dockup.

Dopo il lancio, soddisfa il contratto applicativo: imposta DOMAIN sull'origine HTTPS esterna esatta, consenti e verifica un SMTP funzionante quando sono necessarie le email per gli inviti e l'accesso di emergenza ed esegui questa verifica: accedi da un'estensione del browser, crea un elemento, sincronizza un secondo client, carica un allegato e recupera un Send dopo un riavvio. In questo modo l'esperienza one-click rimane utile senza appiattire i dettagli che rendono Vaultwarden ripristinabile e sicuro.

Domande frequenti

Di cosa ha bisogno Vaultwarden per un deployment in produzione?

Instrada il container Vaultwarden sulla porta 80 attraverso un'unica origine HTTPS. Il requisito esterno per la distribuzione è un SMTP funzionante quando sono necessarie le email per gli inviti e l'accesso di emergenza. Non considerare Vaultwarden pronto finché non riesci ad accedere da un'estensione del browser, creare un elemento, sincronizzare un secondo client, caricare un allegato e recuperare un Send dopo un riavvio.

Quali dati di Vaultwarden devono essere inclusi in un backup?

Rendi persistente /data e includi nel medesimo recovery manifest il database, gli allegati, i Send, le chiavi e la configurazione in /data. Un ripristino pulito di Vaultwarden è riuscito solo quando gli elementi del vault, gli allegati, i Send e l'appartenenza all'organizzazione si sincronizzano correttamente con un client pulito dopo il ripristino.

Vaultwarden richiede HTTPS dietro un reverse proxy?

Usa HTTPS per l'origine pubblica di Vaultwarden e mantieni la porta 80 sulla route interna. Applica correttamente l'impostazione di Vaultwarden: imposta DOMAIN sull'origine HTTPS esterna esatta. Per Vaultwarden, HTTPS protegge le credenziali o i contenuti degli utenti durante il transito e mantiene coerente il comportamento del client sensibile all'origine.

Come si deve testare un upgrade di Vaultwarden?

Ripristina lo stato corrente di Vaultwarden in un deployment isolato, applica la versione candidata e ripeti la transazione di accettazione. Presta particolare attenzione perché le migrazioni del database di Vaultwarden e la compatibilità dei client Bitwarden devono essere verificate insieme; la rotazione di ADMIN_TOKEN è una modifica all'accesso amministrativo, non una migrazione dei dati del vault. Conserva l'immagine precedente finché non avrai compreso il confine tra migrazione dei dati e rollback di Vaultwarden.