Vaultwarden self-hosted con Docker: installazione, sicurezza e migrazione da Chrome
Guida pratica a Vaultwarden self-hosted con Docker: come scegliere tra VPN e Nginx Proxy Manager, proteggere e salvare il vault e migrare le password da Chrome.
Vaultwarden è un server open source non ufficiale compatibile con le app e le estensioni Bitwarden. Lo uso in Docker per gestire il mio vault su un’infrastruttura che controllo, raggiungibile tramite VPN oppure tramite HTTPS con Nginx Proxy Manager.
Il self-hosting non rende automaticamente un password manager più sicuro: offre più controllo, ma trasferisce a chi lo gestisce la responsabilità di aggiornamenti, TLS, accessi, backup e ripristino. In questa guida mostro la mia configurazione reale, spiego quando ha senso adottarla e come migrare le password da Google Password Manager senza saltare i controlli più importanti.
Che cos’è Vaultwarden e in cosa differisce da Bitwarden
Vaultwarden implementa in modo leggero le API usate dai client Bitwarden. Questo significa che posso usare le estensioni browser e le app ufficiali Bitwarden, indicando però l’URL del mio server.
Non è il server ufficiale Bitwarden e non va confuso con Bitwarden Cloud. È un progetto indipendente, molto diffuso negli homelab e adatto a chi accetta di occuparsi dell’intero ciclo operativo: installazione, aggiornamenti, disponibilità, protezione della rete e recovery.
Vaultwarden, Bitwarden Cloud o Google Password Manager?
Non esiste una soluzione migliore in assoluto:
- Google Password Manager è integrato con Chrome e con l’account Google, cifra le credenziali e offre controlli sulle password compromesse, come descritto nella documentazione di Google Password Manager. È comodo e richiede poca manutenzione.
- Bitwarden Cloud offre client multipiattaforma e un servizio gestito: non devo mantenere personalmente il server.
- Vaultwarden self-hosted mi permette di scegliere dove risiedono i dati e come rendere raggiungibile il servizio, ma ogni errore di configurazione o backup è responsabilità mia.
Ho scelto Vaultwarden per il controllo e per l’integrazione con il mio ambiente self-hosted, non perché Chrome sia privo di protezioni.
Quando scegliere il self-hosting — e quando evitarlo
| Scenario | Scelta da valutare | Perché |
|---|---|---|
| Sai mantenere un servizio e vuoi più controllo | Vaultwarden | Ottieni controllo in cambio di responsabilità |
| Non vuoi gestire aggiornamenti e restore | Un servizio gestito | Riduci il carico operativo |
| Accetti una rete privata sui dispositivi | Vaultwarden via VPN | Riduci la superficie esposta pubblicamente |
| Vuoi raggiungibilità diretta da più dispositivi | Vaultwarden via HTTPS | Più comodità, ma più disciplina sull’esposizione |
| Non hai un backup ripristinabile | Rimanda la migrazione | Il controllo senza recovery diventa un rischio |
Se non sai ancora come recuperare il vault dopo la perdita del server, fermati qui: prima costruisci e prova il backup, poi rendi Vaultwarden il tuo password manager principale.
La mia architettura reale
Il flusso è semplice:
Client Bitwarden → VPN oppure HTTPS/Nginx Proxy Manager → container Vaultwarden → /opt/vaultwarden/vw-data
Vaultwarden gira in Docker. La directory persistente sul server è /opt/vaultwarden/vw-data, le registrazioni sono disabilitate e l’accesso avviene attraverso una rete privata oppure un dominio HTTPS pubblicato con Nginx Proxy Manager.
VPN e reverse proxy risolvono problemi diversi:
- con la VPN il servizio resta raggiungibile soltanto dai dispositivi autorizzati;
- con Nginx Proxy Manager il servizio può essere raggiunto tramite un URL HTTPS, con maggiore comodità ma anche maggiore esposizione.
Anche quando uso una VPN, preferisco un endpoint HTTPS valido: il web vault usa API crittografiche del browser che richiedono un contesto sicuro.
Prerequisiti e checklist prima di iniziare
Prima del deploy verifico di avere:
- Docker e Docker Compose funzionanti;
- una directory persistente fuori dal container;
- l’URL definitivo del vault;
- una password principale lunga, unica e non riutilizzata;
- un secondo fattore pronto per essere attivato;
- un accesso VPN oppure un reverse proxy HTTPS configurabile;
- un backup esterno al server e una procedura di ripristino;
- una finestra periodica per controllare e applicare gli aggiornamenti.
Installare Vaultwarden con Docker Compose
1. Creare la directory persistente
sudo mkdir -p /opt/vaultwarden/vw-data
cd /opt/vaultwarden
La directory vw-data verrà montata come /data nel container. È qui che Vaultwarden conserva database, allegati e chiavi necessarie al funzionamento.
2. Creare il file Compose
Questa è una base vicina alla mia configurazione:
services:
vaultwarden:
image: vaultwarden/server:latest
container_name: vaultwarden
restart: unless-stopped
ports:
- '10.10.0.5:8080:80'
volumes:
- /opt/vaultwarden/vw-data:/data
environment:
DOMAIN: 'https://vault.example.com'
SIGNUPS_ALLOWED: 'false'
Sostituisci 10.10.0.5 con l’IP privato del server e vault.example.com con il nome realmente usato dai client. Non pubblicare la porta 8080 su Internet: deve essere raggiungibile soltanto dalla VPN o dal reverse proxy.
Se Nginx Proxy Manager gira sullo stesso host puoi legare la porta a 127.0.0.1. Se gira su un altro host o in un LXC separato, usa un IP privato e limita con il firewall le sorgenti autorizzate.
Uso latest, che per Vaultwarden identifica la release stabile corrente, ma non aggiorno il container alla cieca. Prima controllo le note di rilascio e il backup; poi eseguo il pull in una finestra di manutenzione. Chi vuole massima prevedibilità può fissare una versione esplicita e aggiornarla consapevolmente.
3. Avviare e controllare il container
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=100 vaultwarden
Prima di procedere verifico che il container sia Up, che il volume sia montato e che i log non mostrino errori di database, permessi o configurazione.
4. Creare il primo account e chiudere le registrazioni
SIGNUPS_ALLOWED: 'false' impedisce la registrazione autonoma di nuovi utenti. Per il primo avvio la sequenza più semplice è:
- mantenere il servizio accessibile soltanto dalla rete fidata o dalla VPN;
- impostare temporaneamente
SIGNUPS_ALLOWED: 'true'; - avviare Vaultwarden e creare il primo account;
- riportare immediatamente il valore a
'false'; - ricreare il container e controllare che il collegamento di registrazione non sia più disponibile.
docker compose up -d
docker compose logs --tail=100 vaultwarden
Non lascio mai le registrazioni aperte su un endpoint pubblico “per comodità”. Vaultwarden consente anche inviti e gestione amministrativa, ma l’area /admin va abilitata solo se serve e protetta con un token forte, meglio ancora con una restrizione di rete aggiuntiva.
Accesso privato tramite VPN
È l’opzione che riduce maggiormente l’esposizione: il vault è raggiungibile solo dopo aver connesso il dispositivo alla rete privata.
I compromessi sono chiari:
- devo installare e attivare la VPN su ogni dispositivo;
- DNS e routing devono funzionare anche da remoto;
- se la VPN è indisponibile, non posso sincronizzare nuove modifiche;
- devo comunque usare TLS valido per il web vault e proteggere il server.
Per capire come valuto rete e prestazioni puoi leggere la mia configurazione WireGuard su Proxmox.
Accesso HTTPS tramite Nginx Proxy Manager
Se voglio usare il vault senza attivare prima una VPN, pubblico un dominio HTTPS tramite reverse proxy. In Nginx Proxy Manager imposto:
- il dominio usato in
DOMAIN; - uno SSL Certificate valido e il reindirizzamento a HTTPS;
- come destinazione l’IP privato e la porta interna di Vaultwarden;
- il supporto WebSocket, se richiesto dalla versione in uso;
- accesso alla dashboard NPM separato e protetto;
- regole firewall che impediscano di raggiungere direttamente la porta del container da Internet.
La mia architettura di riferimento è descritta nella configurazione di Nginx Proxy Manager in LXC.
Esporre correttamente HTTPS non significa aver concluso il lavoro: devo ancora aggiornare Vaultwarden e il proxy, controllare i certificati, proteggere gli account e verificare i backup.
Quale dei due scegliere?
Scelgo la VPN se il vault è personale, i dispositivi sono pochi e accetto un passaggio aggiuntivo per collegarmi. Scelgo il reverse proxy HTTPS se la raggiungibilità immediata è importante o se devo semplificare l’uso su più dispositivi.
Esiste anche una via intermedia: usare Nginx Proxy Manager per terminare TLS, ma rendere il dominio raggiungibile soltanto dalla rete privata o dalla VPN. In questo modo il web vault ha HTTPS senza essere necessariamente pubblico.
Hardening essenziale
La mia checklist minima comprende:
- password principale lunga, unica e memorizzata con attenzione;
- autenticazione a due fattori sul vault;
- registrazioni disabilitate;
- area amministrativa disabilitata se non necessaria, oppure protetta con token forte e filtro di rete;
- porte esposte soltanto sulle interfacce necessarie;
- immagini e componenti aggiornati in modo controllato;
- log controllati dopo deploy e aggiornamenti;
- account email e dispositivi protetti, perché fanno parte della catena di recupero.
La 2FA è importante, ma non elimina phishing, furto di sessione o errori operativi: ho raccolto questi limiti nell’approfondimento sulle difese della 2FA.
Backup: copiare i dati non basta
Con il database SQLite predefinito, Vaultwarden salva la maggior parte dello stato in db.sqlite3, mentre allegati e Send risiedono in directory separate. Nella stessa /data sono presenti anche le chiavi RSA usate per firmare i token.
Per creare una copia coerente del database uso il comando di backup integrato:
docker exec vaultwarden /vaultwarden backup
La documentazione ufficiale sul backup di Vaultwarden chiarisce però che il database non contiene ogni dato. Il backup prodotto nella directory dati non basta da solo: copio fuori dal server l’intera struttura necessaria, includendo il database salvato, attachments, sends, le chiavi rsa_key.* e l’eventuale configurazione. La cache delle icone è ricostruibile e non ha lo stesso valore dei dati del vault.
Conservo almeno una copia cifrata su un sistema differente. Uno snapshot del solo container, senza volume persistente o senza consistenza del database, non è un piano di recovery.
Come verificare un ripristino
Almeno periodicamente provo il restore in un ambiente isolato:
- preparo una nuova istanza non esposta;
- arresto Vaultwarden prima di sostituire i file in
/data; - ripristino database, allegati, Send e chiavi dello stesso set di backup;
- se il backup contiene
db.sqlite3creato con il comando integrato, rimuovo eventuali file WAL preesistenti della nuova istanza; - avvio il container e verifico login, elementi del vault e allegati;
- documento data ed esito della prova.
Non considero riuscito il backup finché non ho verificato almeno un ripristino.
Migrare le password da Chrome a Vaultwarden
Esportare da Google Password Manager
Secondo la procedura ufficiale di esportazione da Chrome, su desktop:
- apro Password e compilazione automatica → Google Password Manager;
- entro in Impostazioni;
- accanto a Esporta password seleziono Scarica file;
- salvo temporaneamente il CSV in una posizione protetta.
Il file CSV contiene credenziali leggibili: chi può aprirlo può vedere le password. Google stessa raccomanda di eliminarlo dopo l’uso. Non lo invio via email, non lo lascio in una cartella sincronizzata e non lo conservo come backup ordinario.
Importare e verificare il risultato
Nel web vault collegato al mio server apro gli strumenti di importazione, scelgo Chrome (CSV) come formato e carico il file, seguendo i formati supportati nella guida Bitwarden all’importazione.
Bitwarden non elimina automaticamente i duplicati durante l’importazione. Per questo:
- importo una sola volta;
- controllo un campione di siti importanti;
- verifico URL, username, note e caratteri speciali;
- cerco eventuali duplicati;
- provo login e sincronizzazione da almeno due client.
Solo dopo questi controlli disattivo l’offerta di salvataggio nel vecchio gestore, se voglio usare esclusivamente Vaultwarden.
Eliminare in sicurezza il CSV
Dopo la verifica elimino il CSV e svuoto il cestino. Controllo anche download recenti, copie temporanee e cartelle sincronizzate. Su supporti moderni con snapshot o sincronizzazione cloud, la semplice eliminazione può non cancellare immediatamente tutte le copie: per questo evito fin dall’inizio di creare duplicati del file.
Configurare estensioni browser e app mobili
Installo le app o le estensioni ufficiali Bitwarden. Prima del login apro le impostazioni dell’ambiente self-hosted e inserisco l’URL completo, incluso https://, come richiesto dalla guida Bitwarden per i client self-hosted, per esempio:
https://vault.example.com
Uso lo stesso endpoint in tutti i client, poi effettuo il login e una sincronizzazione manuale. Verifico che un elemento creato su un dispositivo compaia sull’altro.
Secondo la documentazione Bitwarden sull’uso offline, un’app già sbloccata può consultare il vault in sola lettura anche senza connessione. Offline non posso aggiungere o modificare elementi, allegati o Send, né importare dati: questa possibilità non sostituisce la disponibilità del server o il backup.
FAQ su Vaultwarden
Che cos’è Vaultwarden e in cosa differisce da Bitwarden?
Vaultwarden è un server non ufficiale, leggero e compatibile con i client Bitwarden. Bitwarden Cloud e il server self-hosted ufficiale sono invece gestiti e sviluppati da Bitwarden.
Vaultwarden è sicuro?
Può essere configurato in modo robusto, ma non è automaticamente sicuro perché self-hosted. Sicurezza e affidabilità dipendono anche da TLS, password principale, 2FA, aggiornamenti, rete, backup e capacità di ripristino.
È meglio usare una VPN o Nginx Proxy Manager?
La VPN riduce l’esposizione pubblica ma richiede un client connesso. Nginx Proxy Manager rende l’accesso più diretto tramite HTTPS, ma richiede maggiore attenzione a proxy, certificati, firewall e aggiornamenti.
Posso usare Vaultwarden senza esporlo su Internet?
Sì. Puoi renderlo raggiungibile soltanto tramite LAN o VPN. Per usare il web vault serve comunque un contesto HTTPS valido; un reverse proxy può terminare TLS anche su un dominio disponibile solo internamente.
Come disabilito le registrazioni dopo il primo account?
Imposta SIGNUPS_ALLOWED: 'false' nel file Compose e ricrea il container con docker compose up -d. Prima verifica che l’account iniziale esista e che tu riesca ad accedere.
Dove vengono salvati i dati di Vaultwarden?
Nel container vengono salvati sotto /data. In questa configurazione /data è montata sulla directory host /opt/vaultwarden/vw-data.
Come faccio il backup e verifico il ripristino?
Crea un backup SQLite coerente, copia anche allegati, Send e chiavi fuori dal server e prova periodicamente il ripristino su un’istanza isolata.
Posso importare le password da Chrome?
Sì. Esporta il CSV da Google Password Manager, importalo scegliendo il formato Chrome, controlla risultati e duplicati, quindi elimina tutte le copie del CSV.
Quali app ed estensioni posso usare?
Puoi usare le app mobili, desktop e le estensioni browser Bitwarden configurando l’URL del tuo server Vaultwarden.
Cosa succede se il server Vaultwarden non è raggiungibile?
Un’app già sbloccata può consultare offline il vault sincronizzato in sola lettura. Non posso aggiungere o modificare elementi finché il server non torna raggiungibile.
Conclusione: controllo e responsabilità
Vaultwarden mi offre un password manager self-hosted compatibile con browser e smartphone, inserito nella mia infrastruttura Docker e accessibile tramite VPN o HTTPS.
Il vantaggio reale non è una sicurezza “automatica”, ma la possibilità di decidere dove risiedono i dati e come viene raggiunto il servizio. In cambio devo mantenere aggiornamenti, accessi, backup e ripristino: è questo equilibrio, più del semplice deploy, a determinare se Vaultwarden è la scelta giusta.
Per una consulenza o una verifica della tua situazione: