Self-hosting di Vaultwarden su un VPS con Docker Compose

13 min di lettura·Matthieu·self-hostingfail2bansecuritypassword-managerdocker-composedockervaultwarden|

Distribuisci un password manager Vaultwarden blindato sul tuo VPS. Docker Compose con container in sola lettura, fail2ban, SMTP per la 2FA, backup e ripristino, e accesso di emergenza.

Vaultwarden conserva tutte le password che possiedi. Un deployment trascurato è peggio di nessun deployment. Questo tutorial configura Vaultwarden su un VPS con container Docker blindati, fail2ban, SMTP per l'autenticazione a due fattori e una procedura di backup e ripristino.

Diamo per scontato che Docker Engine e un reverse proxy (Nginx o Caddy) siano già in esecuzione sul tuo server. In caso contrario, inizia con Docker in produzione su un VPS: cosa si rompe e come risolvere e Come configurare Nginx come reverse proxy.

Cos'è Vaultwarden e come si differenzia da Bitwarden?

Vaultwarden è una reimplementazione in Rust dell'API server di Bitwarden. Gira come singolo container Docker, usa SQLite di default, consuma circa 50 MB di RAM a riposo ed è pienamente compatibile con tutti i client ufficiali Bitwarden (estensioni browser, app mobile, desktop, CLI). Il deployment self-hosted ufficiale di Bitwarden richiede più di 11 container e almeno 4 GB di RAM.

Vaultwarden Bitwarden Self-Hosted
Linguaggio Rust C# (.NET)
Container 1 11+
RAM (riposo) ~50 MB ~2-4 GB
Database SQLite (default), MySQL, PostgreSQL MSSQL (obbligatorio)
Supporto client Bitwarden Completo Completo
SSO (OpenID Connect) Dalla versione 1.35.0 Solo piano Enterprise
Supporto ufficiale Community Bitwarden Inc.
Licenza AGPL-3.0 Proprietaria (SSPL per il server)

Vaultwarden si chiamava precedentemente bitwarden_rs. Se incontri quel nome in guide più vecchie, si tratta dello stesso progetto.

Come faccio il deploy di Vaultwarden con Docker Compose su un VPS?

Crea una struttura di directory per i dati e la configurazione di Vaultwarden. Tutti i dati persistenti risiedono in un'unica directory di cui farai il backup successivamente.

mkdir -p /opt/vaultwarden/data
cd /opt/vaultwarden

Genera un token di amministrazione con hash argon2. Non conservare mai il token admin in chiaro.

docker run --rm -it vaultwarden/server:1.35.4 /vaultwarden hash

Il comando richiede una password due volte, poi stampa una stringa PHC argon2id:

Generate an Argon2id PHC string using the 'bitwarden' preset:

Password:
Confirm Password:
ADMIN_TOKEN='$argon2id$v=19$m=65540,t=3,p=4$S2mMOA8VnTtIOb3J8Gj9Jw$9cZ0YIKmGxfWEqSMKFMbORkBiW7hMGCls3SXAFXSIVE'

Salva quella stringa. Ti servirà nel file di ambiente.

Crea il file dei segreti con permessi ristretti:

touch /opt/vaultwarden/.env
chmod 600 /opt/vaultwarden/.env

Modifica /opt/vaultwarden/.env con i tuoi valori:

DOMAIN=https://vault.example.com
ADMIN_TOKEN='$argon2id$v=19$m=65540,t=3,p=4$your-hash-here'

SIGNUPS_ALLOWED=true
INVITATIONS_ALLOWED=true
EMERGENCY_ACCESS_ALLOWED=true
ORG_CREATION_USERS=all

SHOW_PASSWORD_HINT=false
IP_HEADER=X-Real-IP
LOG_FILE=/data/vaultwarden.log
LOG_LEVEL=warn

SMTP_HOST=smtp.example.com
SMTP_FROM=vault@example.com
SMTP_PORT=587
SMTP_SECURITY=starttls
SMTP_USERNAME=vault@example.com
SMTP_PASSWORD=your-smtp-password

SHOW_PASSWORD_HINT=false impedisce la fuga di suggerimenti a chiunque conosca un nome utente. IP_HEADER=X-Real-IP dice a Vaultwarden di leggere l'IP del client dall'header del reverse proxy, necessario affinché fail2ban blocchi l'indirizzo giusto.

Ora crea il file Compose.

Come blindo il container Docker di Vaultwarden?

Il file Compose qui sotto fissa la versione dell'immagine, rimuove tutte le capability Linux, abilita un filesystem root in sola lettura, blocca l'escalation dei privilegi e imposta limiti di memoria. Sono le impostazioni predefinite di questa guida, non aggiunte opzionali.

Crea /opt/vaultwarden/compose.yaml:

services:
  vaultwarden:
    image: vaultwarden/server:1.35.4
    container_name: vaultwarden
    restart: unless-stopped
    env_file: .env
    user: "1000:1000"
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    read_only: true
    tmpfs:
      - /tmp
    volumes:
      - ./data:/data
    ports:
      - "127.0.0.1:8080:80"
    deploy:
      resources:
        limits:
          memory: 512M
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:80/alive"]
      interval: 30s
      timeout: 5s
      retries: 3
  • user: "1000:1000" esegue il processo come utente non-root all'interno del container. Devi impostare la proprietà della directory dati in modo corrispondente: chown -R 1000:1000 /opt/vaultwarden/data.
  • cap_drop: ALL rimuove tutte le capability Linux. Vaultwarden non ne necessita perché ascolta sulla porta 80 all'interno del container (una porta non privilegiata in questo contesto dato che Docker gestisce il mapping).
  • read_only: true impedisce al container di scrivere ovunque tranne nei volumi montati esplicitamente e nel tmpfs. Se qualcosa compromette Vaultwarden, non può scrivere nel filesystem del container.
  • ports: "127.0.0.1:8080:80" si lega solo a localhost. Il reverse proxy gestisce il traffico esterno. Non esporre mai Vaultwarden direttamente a Internet.
  • deploy.resources.limits.memory: 512M impedisce a un processo fuori controllo di consumare tutta la RAM del server. Vaultwarden usa ~50 MB a riposo e ~100-150 MB sotto carico. 512 MB danno ampio margine.

Correggi la proprietà della directory dati e avvia il container:

chown -R 1000:1000 /opt/vaultwarden/data
docker compose up -d

[+] Running 1/1
 ✔ Container vaultwarden  Started

Controlla lo stato del container:

docker compose ps

NAME          IMAGE                       COMMAND       SERVICE       CREATED          STATUS                    PORTS
vaultwarden   vaultwarden/server:1.35.4   "/start.sh"   vaultwarden   Up 30 seconds (healthy)   127.0.0.1:8080->80/tcp

Lo stato (healthy) indica che l'healthcheck è passato. Controlla i log per eventuali errori all'avvio:

docker compose logs --tail 20

I log mostrano Vaultwarden in avvio sulla porta 80 all'interno del container, senza errori.

Configurazione del reverse proxy

Il tuo reverse proxy inoltra il traffico HTTPS a 127.0.0.1:8080. Ecco un blocco server Nginx minimale:

server {
    listen 443 ssl;
    http2 on;
    server_name vault.example.com;

    ssl_certificate /etc/letsencrypt/live/vault.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/vault.example.com/privkey.pem;

    client_max_body_size 525M;
    server_tokens off;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

client_max_body_size 525M consente l'upload di allegati fino al limite di Bitwarden. server_tokens off nasconde la versione di Nginx nelle risposte, perché rivelare la versione aiuta gli attaccanti a prendere di mira vulnerabilità note.

Da Vaultwarden 1.29.0, il traffico WebSocket è servito sulla stessa porta dell'HTTP. Non serve un percorso proxy separato per /notifications/hub. Se vedi WEBSOCKET_ENABLED in tutorial più vecchi, ignoralo. Quella variabile è stata deprecata in 1.29.0 e rimossa in 1.31.0.

Per i dettagli sulla configurazione Nginx, vedi Come configurare Nginx come reverse proxy e Configurare Let's Encrypt SSL/TLS per Nginx su Debian 12 e Ubuntu 24.04.

Come configuro l'email SMTP per Vaultwarden?

Vaultwarden ha bisogno di SMTP per inviare codici di verifica via email, email di configurazione 2FA, inviti per le organizzazioni e notifiche di accesso di emergenza. Senza SMTP, funzionalità come la registrazione tramite invito, la 2FA via email e l'accesso di emergenza non funzionano.

Le variabili di ambiente principali sono SMTP_HOST, SMTP_PORT, SMTP_SECURITY, SMTP_USERNAME, SMTP_PASSWORD e SMTP_FROM. Usa SMTP_PORT=587 con SMTP_SECURITY=starttls per la maggior parte dei provider, oppure SMTP_PORT=465 con SMTP_SECURITY=force_tls per TLS implicito.

Queste variabili sono già incluse nel file .env sopra. Dopo l'avvio del container, testa l'invio email: accedi alla cassaforte web su https://vault.example.com, crea il tuo account, vai su Settings > Security > Two-step Login e attiva la 2FA via email. Se ricevi il codice di verifica, SMTP funziona.

Controlla i log se l'invio fallisce:

docker compose logs | grep -i smtp

Problemi comuni:

  • Autenticazione fallita: ricontrolla SMTP_USERNAME e SMTP_PASSWORD. I caratteri speciali nella password potrebbero richiedere virgolette singole nel file .env.
  • Connessione rifiutata sulla porta 587: alcuni provider VPS bloccano le porte in uscita 25 e 587 di default. Verifica con il tuo provider o prova la porta 465 con force_tls.
  • Errore certificato: il certificato TLS del server SMTP deve essere valido. I certificati autofirmati richiedono SMTP_ACCEPT_INVALID_CERTS=true (sconsigliato in produzione).
Variabile Scopo Esempio
SMTP_HOST Hostname del server mail smtp.example.com
SMTP_PORT Porta di connessione 587
SMTP_SECURITY Metodo TLS starttls o force_tls
SMTP_FROM Indirizzo mittente vault@example.com
SMTP_USERNAME Username di autenticazione vault@example.com
SMTP_PASSWORD Password di autenticazione (salvata in .env, chmod 600)
SMTP_AUTH_MECHANISM Tipo di autenticazione (opzionale) Login

Come metto in sicurezza il pannello di amministrazione di Vaultwarden?

Il pannello di amministrazione su /admin permette di gestire utenti, visualizzare la configurazione e modificare le impostazioni. È protetto dall'ADMIN_TOKEN generato in precedenza. L'hash argon2 significa che il token grezzo non viene mai salvato nel file .env. Anche se qualcuno legge il file, ottiene un hash, non la password.

Dopo la configurazione iniziale (creazione account, configurazione SMTP, disabilitazione registrazioni), hai due opzioni:

Opzione 1: Disabilitare completamente il pannello di amministrazione. Rimuovi o commenta ADMIN_TOKEN in .env e riavvia:

docker compose down && docker compose up -d

Senza ADMIN_TOKEN impostato, l'endpoint /admin restituisce un 404. È l'opzione più sicura per deployment con un solo utente.

Opzione 2: Limitare l'accesso tramite il reverse proxy. Mantieni il pannello attivo ma blocca l'accesso esterno:

location /admin {
    allow 127.0.0.1;
    deny all;

    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

Accedi al pannello di amministrazione tramite un tunnel SSH quando necessario:

ssh -L 8888:127.0.0.1:443 user@your-vps

Poi apri https://127.0.0.1:8888/admin nel browser.

Disabilitare la registrazione pubblica

Una volta creato il tuo account, disabilita le registrazioni aperte. Modifica /opt/vaultwarden/.env:

SIGNUPS_ALLOWED=false

Riavvia il container:

cd /opt/vaultwarden && docker compose down && docker compose up -d

I nuovi utenti possono comunque unirsi tramite inviti dell'organizzazione se INVITATIONS_ALLOWED=true. Questo ti permette di aggiungere membri del team senza aprire la registrazione a tutti.

Come configuro fail2ban per Vaultwarden in Docker?

Fail2ban monitora il file di log di Vaultwarden alla ricerca di tentativi di login falliti e blocca gli IP incriminati. Poiché Vaultwarden gira in Docker, la regola di ban deve puntare alla catena iptables DOCKER-USER. Le regole della catena INPUT standard non hanno effetto sul traffico instradato da Docker.

Il container Vaultwarden scrive i log in /opt/vaultwarden/data/vaultwarden.log (mappato da /data/vaultwarden.log all'interno del container) perché abbiamo impostato LOG_FILE=/data/vaultwarden.log nell'ambiente.

Per una guida dettagliata all'installazione di fail2ban, consulta Installare e configurare Fail2Ban su un VPS Linux.

Filtro login

Crea /etc/fail2ban/filter.d/vaultwarden.local:

[INCLUDES]
before = common.conf

[Definition]
failregex = ^.*?Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$
ignoreregex =

Filtro pannello di amministrazione

Crea /etc/fail2ban/filter.d/vaultwarden-admin.local:

[INCLUDES]
before = common.conf

[Definition]
failregex = ^.*?Invalid admin token\. IP: <ADDR>.*$
ignoreregex =

Configurazione del jail

Crea /etc/fail2ban/jail.d/vaultwarden.local:

[vaultwarden]
enabled = true
port = http,https
filter = vaultwarden
action = iptables-allports[name=vaultwarden, chain=DOCKER-USER]
logpath = /opt/vaultwarden/data/vaultwarden.log
maxretry = 3
bantime = 14400
findtime = 14400
backend = pyinotify

[vaultwarden-admin]
enabled = true
port = http,https
filter = vaultwarden-admin
action = iptables-allports[name=vaultwarden-admin, chain=DOCKER-USER]
logpath = /opt/vaultwarden/data/vaultwarden.log
maxretry = 3
bantime = 14400
findtime = 14400
backend = pyinotify
Parametro Valore Perché
chain DOCKER-USER Docker bypassa la catena INPUT. Le regole devono andare in DOCKER-USER per influenzare il traffico dei container.
maxretry 3 Tre tentativi falliti attivano il ban. Un utente legittimo sbaglia raramente più di due volte.
bantime 14400 Ban di quattro ore. Abbastanza lungo per scoraggiare il brute-force, abbastanza corto per non bloccare permanentemente un utente legittimo che ha digitato male.
findtime 14400 Conta i fallimenti in una finestra di quattro ore.
backend pyinotify Monitoraggio log basato su file. Il backend systemd predefinito non può leggere i file di log dei container Docker.

Riavvia fail2ban e controlla il jail:

systemctl restart fail2ban
fail2ban-client status vaultwarden

Status for the jail: vaultwarden
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- File list:        /opt/vaultwarden/data/vaultwarden.log
`- Actions
   |- Currently banned: 0
   |- Total banned:     0
   `- Banned IP list:

Testa la regex contro il formato effettivo del log:

fail2ban-regex /opt/vaultwarden/data/vaultwarden.log /etc/fail2ban/filter.d/vaultwarden.local

Se non esistono ancora login falliti, l'output mostra 0 matched. È normale. Provoca un login fallito tramite la cassaforte web e riesegui per confermare che la regex corrisponde.

Come collego le estensioni del browser e le app mobile a Vaultwarden?

Tutti i client ufficiali Bitwarden funzionano con Vaultwarden. L'unica modifica è puntarli all'URL del tuo server invece che a bitwarden.com.

Estensione browser (Chrome, Firefox, Safari):

  1. Installa l'estensione Bitwarden dallo store del tuo browser
  2. Nella schermata di login, clicca sull'icona dell'ingranaggio (o "Self-hosted" nelle versioni più recenti)
  3. Imposta Server URL su https://vault.example.com
  4. Salva e accedi con le tue credenziali

App mobile (iOS, Android):

  1. Installa l'app Bitwarden dall'App Store o Google Play
  2. Prima di fare login, tocca l'icona dell'ingranaggio nella schermata di accesso
  3. Imposta Server URL su https://vault.example.com
  4. Salva e accedi

App desktop:

  1. Prima di fare login, clicca sull'icona dell'ingranaggio
  2. Imposta Server URL su https://vault.example.com

CLI:

bw config server https://vault.example.com
bw login

Tutti i client si sincronizzano tramite la tua istanza Vaultwarden. I dati della cassaforte non passano mai per i server di Bitwarden.

Come configuro l'accesso di emergenza in Vaultwarden?

L'accesso di emergenza permette a un contatto fidato di accedere alla tua cassaforte o di prenderne il controllo se diventi irreperibile. Richiede che SMTP sia configurato perché Vaultwarden invia email di notifica durante il processo.

Conferma che la funzionalità sia abilitata nel tuo .env:

EMERGENCY_ACCESS_ALLOWED=true

Configurare un contatto fidato:

  1. Accedi alla cassaforte web su https://vault.example.com
  2. Vai su Settings > Emergency Access
  3. Clicca su Add emergency contact
  4. Inserisci l'email della persona fidata (deve avere un account sulla tua istanza Vaultwarden)
  5. Scegli il livello di accesso:
    • View: il contatto può visualizzare gli elementi della tua cassaforte (sola lettura)
    • Takeover: il contatto può reimpostare la tua master password e prendere il pieno controllo
  6. Imposta il tempo di attesa (da 1 a 90 giorni). È il ritardo tra la richiesta di accesso del contatto e l'effettivo ottenimento. Ricevi una notifica via email e puoi rifiutare la richiesta durante questo periodo.
  7. Clicca su Save

Il contatto fidato riceve un'email di invito. Dopo l'accettazione, appare come contatto di emergenza in attesa. Il tempo di attesa funziona come un meccanismo di sicurezza: se non rispondi entro i giorni configurati, l'accesso viene concesso automaticamente.

Per una cassaforte personale, 7 giorni di attesa con accesso View è ragionevole. Per infrastruttura condivisa dal team, considera tempi più brevi.

Come faccio il backup e il ripristino di un'istanza Vaultwarden?

Vaultwarden conserva tutto nella directory /data: il database SQLite (db.sqlite3), gli allegati, la cache delle icone e la configurazione. Un backup corretto cattura tutto questo in modo coerente.

Il database SQLite va salvato con sqlite3 .backup, non copiando direttamente il file. Copiare un file SQLite attivo può produrre un backup corrotto se avviene una scrittura durante la copia. Il comando .backup crea uno snapshot coerente.

Cosa salvare Posizione Metodo Frequenza
Database SQLite /opt/vaultwarden/data/db.sqlite3 sqlite3 .backup Giornaliera
Allegati /opt/vaultwarden/data/attachments/ rsync o cp -a Giornaliera
Cache icone /opt/vaultwarden/data/icon_cache/ Saltare (rigenerata automaticamente) -
File di ambiente /opt/vaultwarden/.env cp Alla modifica
File Compose /opt/vaultwarden/compose.yaml cp Alla modifica

Script di backup

Per backup automatizzati, lo script utilizza age con un file chiave destinatario. Questo evita prompt interattivi per la passphrase, permettendo allo script di girare da cron.

Genera una coppia di chiavi (una volta sola):

apt install age
age-keygen -o /opt/vaultwarden/backup-key.txt
chmod 600 /opt/vaultwarden/backup-key.txt

Il comando stampa la chiave pubblica su stdout. Salvala in un file destinatario:

age-keygen -y /opt/vaultwarden/backup-key.txt > /opt/vaultwarden/backup-key.pub

Conserva una copia di backup-key.txt (la chiave privata) fuori dal server. Ti serve per decifrare i backup. Se perdi questa chiave, i tuoi backup crittografati saranno irrecuperabili.

Crea /opt/vaultwarden/backup.sh:

#!/bin/bash
set -euo pipefail

BACKUP_DIR="/opt/vaultwarden/backups"
DATA_DIR="/opt/vaultwarden/data"
DATE=$(date +%Y-%m-%d_%H%M)
BACKUP_FILE="${BACKUP_DIR}/vaultwarden-${DATE}.tar"
RECIPIENT="/opt/vaultwarden/backup-key.pub"

mkdir -p "${BACKUP_DIR}"

# Back up SQLite database consistently
sqlite3 "${DATA_DIR}/db.sqlite3" ".backup '${BACKUP_DIR}/db-${DATE}.sqlite3'"

# Package database + attachments + config
tar cf "${BACKUP_FILE}" \
  -C "${BACKUP_DIR}" "db-${DATE}.sqlite3" \
  -C "${DATA_DIR}" attachments/ \
  -C /opt/vaultwarden .env compose.yaml 2>/dev/null || true

# Encrypt with age recipient key (non-interactive)
age -R "${RECIPIENT}" -o "${BACKUP_FILE}.age" "${BACKUP_FILE}"

# Clean up unencrypted files
rm -f "${BACKUP_FILE}" "${BACKUP_DIR}/db-${DATE}.sqlite3"

# Remove backups older than 30 days
find "${BACKUP_DIR}" -name "*.age" -mtime +30 -delete

echo "Backup complete: ${BACKUP_FILE}.age"

chmod 700 /opt/vaultwarden/backup.sh

Per backup giornalieri automatizzati, aggiungi un cron job:

echo "0 3 * * * root /opt/vaultwarden/backup.sh >> /var/log/vaultwarden-backup.log 2>&1" > /etc/cron.d/vaultwarden-backup
chmod 644 /etc/cron.d/vaultwarden-backup

Per copie offsite, invia il backup crittografato a un server remoto o object storage:

rsync -az /opt/vaultwarden/backups/*.age backup-user@remote-server:/backups/vaultwarden/

Procedura di ripristino

Un backup che non hai mai ripristinato è un backup di cui non puoi fidarti. La procedura completa:

# Stop the container
cd /opt/vaultwarden && docker compose down

# Decrypt the backup
age -d -i /opt/vaultwarden/backup-key.txt -o /tmp/vaultwarden-restore.tar /opt/vaultwarden/backups/vaultwarden-2026-03-20_0300.tar.age

# Extract
mkdir -p /tmp/vaultwarden-restore
tar xf /tmp/vaultwarden-restore.tar -C /tmp/vaultwarden-restore

# Replace the database (delete WAL files first)
rm -f /opt/vaultwarden/data/db.sqlite3-wal /opt/vaultwarden/data/db.sqlite3-shm
cp /tmp/vaultwarden-restore/db-2026-03-20_0300.sqlite3 /opt/vaultwarden/data/db.sqlite3
chown 1000:1000 /opt/vaultwarden/data/db.sqlite3

# Restore attachments
rsync -a /tmp/vaultwarden-restore/attachments/ /opt/vaultwarden/data/attachments/
chown -R 1000:1000 /opt/vaultwarden/data/attachments/

# Start the container
docker compose up -d

# Clean up
rm -rf /tmp/vaultwarden-restore /tmp/vaultwarden-restore.tar

Devi eliminare i file WAL (Write-Ahead Log) e SHM prima del ripristino. Questi file appartengono al vecchio stato del database. Avviare Vaultwarden con un database ripristinato ma file WAL obsoleti corrompe i dati.

Dopo il ripristino, accedi alla cassaforte web e conferma che le tue voci siano presenti.

Come aggiorno Vaultwarden in sicurezza?

Fissa la tua immagine a un tag di versione specifico (abbiamo usato 1.35.4). Non usare mai :latest in produzione perché non puoi tracciare cosa è cambiato né fare rollback in modo affidabile.

Per aggiornare:

cd /opt/vaultwarden

# Back up first
./backup.sh

# Pull the new version
docker compose pull

# Recreate the container
docker compose up -d

Prima del pull, modifica compose.yaml per cambiare il tag dell'immagine alla nuova versione. Controlla le note di rilascio per eventuali breaking change.

docker compose logs --tail 30

Se l'aggiornamento crea problemi, ripristina dal backup:

# Revert compose.yaml to the old version tag
docker compose down
# Follow the restore procedure above
docker compose up -d

Qualcosa non funziona?

Il container si ferma immediatamente:

docker compose logs

Cerca errori di permessi. La direttiva user: 1000:1000 richiede proprietà corrispondente su /opt/vaultwarden/data. Esegui chown -R 1000:1000 /opt/vaultwarden/data e riprova.

Non riesci ad accedere alla cassaforte web:

Verifica che il reverse proxy stia inoltrando a 127.0.0.1:8080:

curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:8080/alive

Una risposta 200 significa che Vaultwarden è in esecuzione. Il problema è nella configurazione del reverse proxy.

Fail2ban non blocca:

fail2ban-regex /opt/vaultwarden/data/vaultwarden.log /etc/fail2ban/filter.d/vaultwarden.local

Se la regex non corrisponde a nessuna riga, verifica che LOG_FILE=/data/vaultwarden.log sia impostato in .env e che il file di log esista in /opt/vaultwarden/data/vaultwarden.log.

Le email non vengono inviate:

docker compose logs | grep -i "smtp\|mail\|email"

Verifica che il tuo VPS permetta connessioni in uscita sulla porta SMTP:

nc -zv smtp.example.com 587

Errori di database bloccato:

Questo può accadere se copi il file del database mentre Vaultwarden è in esecuzione. Usa sempre sqlite3 .backup per i backup e ferma sempre il container prima del ripristino.

Posizione dei log:

# Application logs
docker compose logs -f

# Log file (if LOG_FILE is set)
tail -f /opt/vaultwarden/data/vaultwarden.log

# Fail2ban logs
journalctl -u fail2ban -f

Per la sicurezza dei container Docker oltre quanto coperto da questo tutorial, vedi Sicurezza Docker: Rootless Mode, Seccomp e AppArmor su VPS. Per strategie di backup di tutti i tuoi servizi Docker, vedi Backup e ripristino dei volumi Docker su un VPS.

Copyright 2026 Virtua.Cloud. Tutti i diritti riservati. Questo contenuto è un'opera originale del team Virtua.Cloud. La riproduzione, ripubblicazione o redistribuzione senza autorizzazione scritta è vietata.

Pronto a provare?

Distribuisci il tuo server in pochi secondi. Linux, Windows o FreeBSD.

Vedi piani VPS
Self-hosting Vaultwarden su VPS con Docker Compose