Come installare Bitwarden su Ubuntu passo dopo passo

Se vuoi portare Bitwarden su Ubuntu senza trasformare l’installazione in un esercizio di archeologia, la strada più solida è quella ufficiale con Docker e Docker Compose. Funziona bene su un server dedicato o su una VM con risorse decenti, ed è la scelta più sensata quando ti serve un vault password gestito in casa, con accesso web, API e servizi accessori già impacchettati in modo coerente.

Qui l’obiettivo non è solo “farlo partire”, ma farlo partire in modo controllabile: hostname corretto, HTTPS, persistenza dei dati, aggiornamenti ordinati e rollback possibile. Se uno di questi pezzi manca, Bitwarden diventa fragile molto in fretta. Il punto più importante è semplice: prima sistemi l’infrastruttura minima, poi fai girare l’applicazione.

Prerequisiti da verificare prima di installare Bitwarden

Bitwarden self-hosted non è un pacchetto “installo e dimentico”. Prima di lanciare lo script ufficiale, controlla questi punti:

• Ubuntu aggiornato, meglio una LTS recente.
• Un nome host pubblico o comunque risolvibile, ad esempio vault.example.it.
• Accesso amministrativo al server.
• Porta 80 e 443 raggiungibili dall’esterno, se vuoi usare Let’s Encrypt.
• Almeno qualche GB di RAM libera e spazio disco sufficiente per dati, log e database.

Se il server è dietro NAT o proxy, verifica in anticipo che il traffico in ingresso venga inoltrato correttamente. Un errore classico è installare tutto su un host che dall’esterno non è raggiungibile, poi inseguire certificati e callback che non potranno mai funzionare.

Per capire lo stato della macchina, puoi partire da verifiche banali ma utili:

lsb_release -a
hostname -f
free -h
df -h
ss -tulpn | grep -E ':(80|443)\s'

Se hostname -f non restituisce il nome FQDN previsto, fermati: Bitwarden userà quell’identità per costruire URL, certificati e link interni. Correggere dopo si può, ma costa tempo e aumenta il rischio di incongruenze.

Installazione di Docker su Ubuntu

La documentazione Bitwarden si appoggia a Docker. Su Ubuntu conviene installarlo dai repository ufficiali di Docker, non da pacchetti vecchi del sistema, così eviti versioni datate e incompatibilità strane con Compose.

Sequenza tipica:

sudo apt update
sudo apt install -y ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Verifica che Docker risponda e che il plugin Compose sia disponibile:

docker version
docker compose version

Se vuoi evitare di usare sempre sudo, puoi aggiungere il tuo utente al gruppo docker. È comodo, ma va trattato come un privilegio serio: chi può parlare con il demone Docker, di fatto, ha capacità amministrative molto ampie sul sistema.

sudo usermod -aG docker $USER

Disconnettiti e rientra nella sessione, poi controlla con groups. Se il server è condiviso o hardenizzato, valuta di lasciare l’uso di sudo invece di allargare i permessi inutilmente.

Scaricare lo script ufficiale di Bitwarden

Bitwarden mette a disposizione uno script di installazione che prepara i file necessari, crea la struttura dei container e guida la configurazione iniziale. È il metodo più lineare per una installazione self-hosted standard.

In una directory di lavoro, scarica l’installer:

mkdir -p /opt/bitwarden
cd /opt/bitwarden
curl -Lso bitwarden.sh https://func.bitwarden.com/api/dl/?app=self-host&platform=linux

Rendi eseguibile lo script e avvialo in modalità installazione:

chmod +x bitwarden.sh
./bitwarden.sh install

A questo punto ti verranno chiesti alcuni dati fondamentali, in particolare il dominio. Inserisci il nome pubblico con cui vuoi raggiungere il servizio, ad esempio vault.example.it. Questo valore va pensato bene, perché influenza URL, certificati e configurazione generale.

Se non hai ancora un dominio correttamente puntato al server, non andare avanti a caso. Prima crea o correggi il record DNS, poi verifica la risoluzione con un controllo semplice:

dig +short vault.example.it

Il risultato atteso è l’IP pubblico del server. Se non coincide, il certificato non verrà emesso o comunque non sarà raggiungibile come previsto.

Configurazione del dominio e del certificato TLS

Per un vault password non ha senso esporre l’interfaccia in chiaro. La configurazione standard prevede HTTPS con certificato valido. Se il server è esposto direttamente su Internet e le porte 80 e 443 sono libere, l’installer può gestire Let’s Encrypt in modo abbastanza lineare.

Il controllo di base è questo: il dominio deve puntare all’host, il firewall deve lasciar passare il traffico, e nessun reverse proxy a monte deve riscrivere male gli header. Se hai già un proxy esterno, la configurazione cambia e va pensata in modo coerente con il resto dello stack.

Se usi UFW, consenti il traffico necessario:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status verbose

Attenzione al blast radius: aprire queste porte espone il servizio verso l’esterno. Il rollback è semplice, ma va fatto con criterio:

sudo ufw delete allow 80/tcp
sudo ufw delete allow 443/tcp

Se il certificato non viene emesso, la causa più frequente è una di queste: DNS sbagliato, porta 80 non raggiungibile, oppure hostname configurato in modo incoerente. In quel caso controlla i log dell’installer e la configurazione del dominio prima di insistere con riavvii a vuoto.

Struttura delle directory e persistenza dei dati

La persistenza è il punto che separa un’installazione seria da una prova temporanea. Bitwarden salva configurazione, database e dati applicativi in una directory locale del progetto. Se perdi quella directory, perdi la continuità del servizio.

In genere troverai una struttura simile sotto /opt/bitwarden o nella directory in cui hai lanciato l’installer. I punti da tenere d’occhio sono:

• file di configurazione generale;
• database e backup locali;
• certificati e chiavi TLS;
• log dei container;
• dati degli allegati e dei servizi accessori.

Prima di cambiare qualcosa, fai una copia della configurazione. È il minimo sindacale per avere un rollback pulito.

cp -a /opt/bitwarden /opt/bitwarden.backup.$(date +%F)

Se la directory è diversa, usa quella reale. Non dare per scontato il path: verifica con pwd e con il contenuto della cartella prima di toccare file importanti.

Avvio iniziale dei container Bitwarden

Dopo l’installazione, il passo successivo è il primo avvio. È qui che si capisce subito se rete, DNS, TLS e risorse locali sono allineati.

./bitwarden.sh start

Per controllare lo stato dei container usa Docker direttamente:

docker ps
docker compose ps

Il risultato atteso è una serie di container in stato Up. Se uno o più servizi escono subito, il problema è spesso visibile nei log. Non partire con modifiche casuali: leggi prima l’errore reale.

docker logs --tail=100 bitwarden

Se il container principale non è nominato esattamente bitwarden, usa i nomi effettivi restituiti da docker ps. L’importante è osservare l’errore, non indovinare il comando.

Verificare che l’interfaccia risponda correttamente

Quando il servizio è in piedi, il controllo più utile è una richiesta HTTP verso il dominio configurato. Non fermarti alla sola presenza dei container: verifica davvero il percorso utente.

curl -I https://vault.example.it

Il comportamento corretto è una risposta 200 o un redirect atteso verso la pagina di login. Se ottieni errore di certificato, 502, 503 o timeout, il problema è a monte o nel reverse proxy.

Se vuoi controllare anche il certificato presentato dal server:

openssl s_client -connect vault.example.it:443 -servername vault.example.it < /dev/null | openssl x509 -noout -subject -issuer -dates

Qui cerchi tre cose: soggetto corretto, issuer attendibile e date coerenti. Se il certificato è scaduto o non corrisponde al dominio, l’accesso sicuro va sistemato prima di coinvolgere gli utenti.

Gestione degli aggiornamenti senza rompere il servizio

Gli aggiornamenti di Bitwarden vanno trattati come un change controllato, non come un click impulsivo. Prima leggi le note di rilascio, poi fai un backup, poi aggiorni. Saltare uno di questi passaggi è il modo più rapido per complicarsi la vita.

La sequenza prudente è questa:

1. Verifica lo stato attuale con docker ps e annota eventuali container già degradati.
2. Fai un backup della directory applicativa e, se presente, del database.
3. Avvia l’aggiornamento secondo la procedura ufficiale dello script Bitwarden.
4. Controlla i log del deploy e la raggiungibilità HTTPS.
5. Solo dopo valida l’accesso utente e le funzioni critiche.

Se qualcosa va storto, il rollback più pulito è ripristinare la directory salvata prima del cambio e riportare i container alla versione precedente. Il dettaglio preciso dipende dalla versione installata, ma il principio non cambia: senza backup non c’è rollback serio, solo speranza.

Backup e ripristino: la parte che conta davvero

Per un sistema che gestisce credenziali, il backup non è opzionale. Non basta copiare “qualche file”: devi sapere cosa contiene la tua installazione e come rimetterla in piedi in tempi ragionevoli.

La strategia minima è questa:

• snapshot o copia della directory Bitwarden;
• backup del database se separato;
• conservazione sicura dei certificati e della configurazione;
• test periodico del ripristino su un host di prova.

Un backup che non hai mai verificato è solo un file in più da archiviare. Se vuoi essere serio, prepara almeno un ambiente di test dove provare un restore parziale o completo. Anche una verifica di avvio con dati fittizi ti dice molto più di una semplice copia su disco.

Problemi frequenti e come leggerli in fretta

Quando Bitwarden non parte o non risponde, i colpevoli più comuni sono sempre gli stessi. L’ordine giusto di indagine evita di perdere tempo su ipotesi fantasiose.

1. DNS sbagliato: il dominio non punta al server. Falsifichi subito con dig +short vault.example.it.
2. Porta chiusa o firewall: il servizio è vivo ma irraggiungibile da fuori. Falsifichi con ss -tulpn e con un test da client esterno.
3. Certificato o TLS non coerenti: HTTPS va in errore o il browser segnala mismatch. Falsifichi con openssl s_client e controllando i log.
4. Container in crash: il servizio principale si riavvia in loop. Falsifichi con docker ps e docker logs.

La regola pratica è semplice: prima osserva, poi modifica. Riavviare tutto senza leggere i log spesso peggiora solo il rumore, non il problema.

Hardening minimo per un’installazione sensata

Una volta funzionante, il servizio va protetto. Non serve inventarsi un fortino, ma almeno alcune buone abitudini sono obbligatorie.

• Usa un account amministrativo forte e non condiviso.
• Limita l’esposizione esterna solo alle porte necessarie.
• Mantieni Ubuntu e Docker aggiornati con cadenza regolare.
• Controlla i log di accesso e i tentativi anomali.
• Se possibile, aggiungi un livello di protezione lato rete o VPN per l’accesso amministrativo al server.

Non lasciare credenziali, token o chiavi in chiaro in file di appunti o script improvvisati. Se devi documentare una procedura interna, redigi i segreti e conserva solo i riferimenti necessari al recupero sicuro.

Quando conviene fermarsi e ricontrollare la base

Se l’installazione non si comporta come previsto, non forzare il sistema a colpi di riavvio. Fermati e ricontrolla l’ordine delle dipendenze: DNS, rete, HTTPS, Docker, permessi, poi applicazione. È quasi sempre lì che si trova il punto debole.

In pratica, una installazione Bitwarden su Ubuntu ben fatta è una somma di dettagli noiosi, ma quelli giusti: nome host coerente, container stabili, backup presenti e aggiornamenti governati. Se questi elementi sono in ordine, il resto diventa manutenzione ordinaria, non emergenza continua.