Auto-héberger Vaultwarden sur un VPS avec Docker Compose

14 min de lecture·Matthieu·self-hostingfail2bansecuritypassword-managerdocker-composedockervaultwarden|

Déployez un gestionnaire de mots de passe Vaultwarden durci sur votre VPS. Docker Compose avec conteneurs en lecture seule, fail2ban, SMTP pour la 2FA, sauvegarde et restauration, et accès d'urgence.

Vaultwarden stocke l'ensemble de vos mots de passe. Un déploiement bâclé est pire que pas de déploiement du tout. Ce tutoriel met en place Vaultwarden sur un VPS avec des conteneurs Docker durcis, fail2ban, SMTP pour l'authentification à deux facteurs, et une procédure de sauvegarde et restauration.

On part du principe que Docker Engine et un reverse proxy (Nginx ou Caddy) tournent déjà sur votre serveur. Si ce n'est pas le cas, commencez par Docker en production sur un VPS : ce qui casse et comment corriger et Configurer Nginx comme reverse proxy.

Qu'est-ce que Vaultwarden et en quoi diffère-t-il de Bitwarden ?

Vaultwarden est une réimplémentation en Rust de l'API serveur Bitwarden. Il tourne dans un seul conteneur Docker, utilise SQLite par défaut, consomme environ 50 Mo de RAM au repos, et reste entièrement compatible avec tous les clients officiels Bitwarden (extensions navigateur, applications mobiles, bureau, CLI). Le déploiement auto-hébergé officiel de Bitwarden nécessite plus de 11 conteneurs et au moins 4 Go de RAM.

Vaultwarden Bitwarden auto-hébergé
Langage Rust C# (.NET)
Conteneurs 1 11+
RAM (repos) ~50 Mo ~2-4 Go
Base de données SQLite (défaut), MySQL, PostgreSQL MSSQL (obligatoire)
Clients Bitwarden Compatibilité totale Compatibilité totale
SSO (OpenID Connect) Depuis la version 1.35.0 Plan Enterprise uniquement
Support officiel Communauté Bitwarden Inc.
Licence AGPL-3.0 Propriétaire (SSPL pour le serveur)

Vaultwarden s'appelait auparavant bitwarden_rs. Si vous croisez ce nom dans d'anciens guides, il s'agit du même projet.

Comment déployer Vaultwarden avec Docker Compose sur un VPS ?

Créez une arborescence pour les données et la configuration de Vaultwarden. Toutes les données persistantes se trouvent dans un seul répertoire que vous sauvegarderez par la suite.

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

Générez un jeton d'administration haché en argon2. Ne stockez jamais le jeton admin en clair.

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

La commande demande un mot de passe deux fois, puis affiche une chaîne 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'

Conservez cette chaîne. Vous en aurez besoin dans le fichier d'environnement.

Créez le fichier de secrets avec des permissions restreintes :

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

Éditez /opt/vaultwarden/.env avec vos valeurs :

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 empêche la fuite d'indices à quiconque connaît un nom d'utilisateur. IP_HEADER=X-Real-IP indique à Vaultwarden de lire l'IP du client depuis l'en-tête de votre reverse proxy, ce qui est nécessaire pour que fail2ban bannisse la bonne adresse.

Créez maintenant le fichier Compose.

Comment durcir le conteneur Docker de Vaultwarden ?

Le fichier Compose ci-dessous fixe la version de l'image, supprime toutes les capabilities Linux, active un système de fichiers racine en lecture seule, bloque l'escalade de privilèges et définit des limites mémoire. Ce sont les réglages par défaut de ce guide, pas des ajouts optionnels.

Créez /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" exécute le processus en tant qu'utilisateur non-root à l'intérieur du conteneur. Vous devez aligner les permissions du répertoire de données : chown -R 1000:1000 /opt/vaultwarden/data.
  • cap_drop: ALL supprime toutes les capabilities Linux. Vaultwarden n'en a besoin d'aucune car il écoute sur le port 80 à l'intérieur du conteneur (un port non privilégié dans ce contexte puisque Docker gère le mapping).
  • read_only: true empêche le conteneur d'écrire où que ce soit sauf dans les volumes montés et le tmpfs. Si quelque chose exploite Vaultwarden, il ne peut pas écrire sur le système de fichiers du conteneur.
  • ports: "127.0.0.1:8080:80" ne lie le port qu'à localhost. Le reverse proxy gère le trafic externe. N'exposez jamais Vaultwarden directement sur Internet.
  • deploy.resources.limits.memory: 512M empêche un processus emballé de consommer toute la RAM du serveur. Vaultwarden utilise environ 50 Mo au repos et 100-150 Mo en charge. 512 Mo laissent une large marge.

Corrigez les permissions du répertoire de données et démarrez le conteneur :

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

[+] Running 1/1
 ✔ Container vaultwarden  Started

Vérifiez l'état du conteneur :

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

Le statut (healthy) signifie que le healthcheck est passé. Consultez les logs pour d'éventuelles erreurs au démarrage :

docker compose logs --tail 20

Les logs montrent Vaultwarden démarrant sur le port 80 à l'intérieur du conteneur, sans erreurs.

Configuration du reverse proxy

Votre reverse proxy transfère le trafic HTTPS vers 127.0.0.1:8080. Voici un bloc serveur Nginx minimal :

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 autorise l'envoi de pièces jointes jusqu'à la limite Bitwarden. server_tokens off masque la version de Nginx dans les réponses, car la divulgation de version aide les attaquants à cibler des vulnérabilités connues.

Depuis Vaultwarden 1.29.0, le trafic WebSocket est servi sur le même port que le HTTP. Aucun chemin proxy séparé /notifications/hub n'est nécessaire. Si vous voyez WEBSOCKET_ENABLED dans d'anciens tutoriels, ignorez-le. Cette variable a été dépréciée en 1.29.0 et supprimée en 1.31.0.

Pour les détails de configuration Nginx, voir Configurer Nginx comme reverse proxy et Configurer Let's Encrypt SSL/TLS pour Nginx sur Debian 12 et Ubuntu 24.04.

Comment configurer le SMTP pour Vaultwarden ?

Vaultwarden a besoin du SMTP pour envoyer les codes de vérification par e-mail, les e-mails de configuration 2FA, les invitations d'organisation et les notifications d'accès d'urgence. Sans SMTP, des fonctionnalités comme l'inscription par invitation, la 2FA par e-mail et l'accès d'urgence ne fonctionnent pas.

Les variables d'environnement principales sont SMTP_HOST, SMTP_PORT, SMTP_SECURITY, SMTP_USERNAME, SMTP_PASSWORD et SMTP_FROM. Utilisez SMTP_PORT=587 avec SMTP_SECURITY=starttls pour la plupart des fournisseurs, ou SMTP_PORT=465 avec SMTP_SECURITY=force_tls pour le TLS implicite.

Ces variables figurent déjà dans le fichier .env ci-dessus. Après le démarrage du conteneur, testez l'envoi d'e-mails en vous connectant au coffre-fort web à https://vault.example.com, en créant votre compte, puis dans Settings > Security > Two-step Login, activez la 2FA par e-mail. Si vous recevez le code de vérification, le SMTP fonctionne.

Consultez les logs si l'envoi échoue :

docker compose logs | grep -i smtp

Problèmes fréquents :

  • Échec d'authentification : vérifiez SMTP_USERNAME et SMTP_PASSWORD. Les caractères spéciaux dans le mot de passe peuvent nécessiter des guillemets simples dans le fichier .env.
  • Connexion refusée sur le port 587 : certains fournisseurs VPS bloquent les ports sortants 25 et 587 par défaut. Vérifiez auprès de votre fournisseur ou essayez le port 465 avec force_tls.
  • Erreur de certificat : le certificat TLS du serveur SMTP doit être valide. Les certificats auto-signés nécessitent SMTP_ACCEPT_INVALID_CERTS=true (déconseillé en production).
Variable Rôle Exemple
SMTP_HOST Nom d'hôte du serveur mail smtp.example.com
SMTP_PORT Port de connexion 587
SMTP_SECURITY Méthode TLS starttls ou force_tls
SMTP_FROM Adresse expéditeur vault@example.com
SMTP_USERNAME Identifiant d'authentification vault@example.com
SMTP_PASSWORD Mot de passe d'authentification (stocké dans .env, chmod 600)
SMTP_AUTH_MECHANISM Type d'authentification (optionnel) Login

Comment sécuriser le panneau d'administration de Vaultwarden ?

Le panneau d'administration accessible à /admin permet de gérer les utilisateurs, consulter la configuration et modifier les paramètres. Il est protégé par le ADMIN_TOKEN que vous avez généré plus tôt. Le hachage argon2 signifie que le jeton brut n'est jamais stocké dans votre fichier .env. Même si quelqu'un lit le fichier, il n'obtient qu'un hash, pas le mot de passe.

Après la configuration initiale (création de votre compte, configuration SMTP, désactivation des inscriptions), deux options s'offrent à vous :

Option 1 : Désactiver entièrement le panneau d'administration. Supprimez ou commentez ADMIN_TOKEN dans .env et redémarrez :

docker compose down && docker compose up -d

Sans ADMIN_TOKEN défini, le point d'accès /admin renvoie une 404. C'est l'option la plus sûre pour les déploiements mono-utilisateur.

Option 2 : Restreindre l'accès via le reverse proxy. Gardez le panneau d'administration actif mais bloquez l'accès externe :

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;
}

Accédez au panneau d'administration via un tunnel SSH en cas de besoin :

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

Puis ouvrez https://127.0.0.1:8888/admin dans votre navigateur.

Désactiver l'inscription publique

Une fois votre compte créé, désactivez les inscriptions ouvertes. Éditez /opt/vaultwarden/.env :

SIGNUPS_ALLOWED=false

Redémarrez le conteneur :

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

Les nouveaux utilisateurs peuvent toujours rejoindre via les invitations d'organisation si INVITATIONS_ALLOWED=true. Cela vous permet d'ajouter des membres d'équipe sans ouvrir l'inscription à tout le monde.

Comment configurer fail2ban pour Vaultwarden dans Docker ?

Fail2ban surveille le fichier de logs de Vaultwarden à la recherche de tentatives de connexion échouées et bannit les IP fautives. Comme Vaultwarden tourne dans Docker, la règle de bannissement doit cibler la chaîne iptables DOCKER-USER. Les règles de la chaîne INPUT standard n'affectent pas le trafic routé par Docker.

Le conteneur Vaultwarden écrit ses logs dans /opt/vaultwarden/data/vaultwarden.log (mappé depuis /data/vaultwarden.log à l'intérieur du conteneur) car nous avons défini LOG_FILE=/data/vaultwarden.log dans l'environnement.

Pour un guide d'installation détaillé de fail2ban, consultez Installer et configurer Fail2Ban sur un VPS Linux.

Filtre de connexion

Créez /etc/fail2ban/filter.d/vaultwarden.local :

[INCLUDES]
before = common.conf

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

Filtre du panneau d'administration

Créez /etc/fail2ban/filter.d/vaultwarden-admin.local :

[INCLUDES]
before = common.conf

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

Configuration du jail

Créez /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
Paramètre Valeur Pourquoi
chain DOCKER-USER Docker contourne la chaîne INPUT. Les règles doivent aller dans DOCKER-USER pour affecter le trafic des conteneurs.
maxretry 3 Trois échecs déclenchent un bannissement. Un utilisateur légitime échoue rarement plus de deux fois.
bantime 14400 Bannissement de quatre heures. Assez long pour décourager le brute-force, assez court pour ne pas bloquer définitivement un utilisateur légitime qui a fait une faute de frappe.
findtime 14400 Compte les échecs sur une fenêtre de quatre heures.
backend pyinotify Surveillance de logs basée sur les fichiers. Le backend systemd par défaut ne peut pas lire les fichiers de logs des conteneurs Docker.

Redémarrez fail2ban et vérifiez le 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:

Testez la regex contre le format de log réel :

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

Si aucune tentative échouée n'existe encore, la sortie affiche 0 matched. C'est normal. Déclenchez un faux échec de connexion via le coffre-fort web et relancez pour confirmer que la regex correspond.

Comment connecter les extensions navigateur et les applications mobiles à Vaultwarden ?

Tous les clients officiels Bitwarden fonctionnent avec Vaultwarden. La seule modification consiste à les pointer vers l'URL de votre serveur au lieu de bitwarden.com.

Extension navigateur (Chrome, Firefox, Safari) :

  1. Installez l'extension Bitwarden depuis le magasin d'extensions de votre navigateur
  2. Sur l'écran de connexion, cliquez sur l'icône d'engrenage (ou << Self-hosted >> sur les versions récentes)
  3. Définissez Server URL sur https://vault.example.com
  4. Enregistrez et connectez-vous avec vos identifiants

Application mobile (iOS, Android) :

  1. Installez l'application Bitwarden depuis l'App Store ou Google Play
  2. Avant de vous connecter, appuyez sur l'icône d'engrenage sur l'écran de connexion
  3. Définissez Server URL sur https://vault.example.com
  4. Enregistrez et connectez-vous

Application de bureau :

  1. Avant de vous connecter, cliquez sur l'icône d'engrenage
  2. Définissez Server URL sur https://vault.example.com

CLI :

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

Tous les clients se synchronisent via votre instance Vaultwarden. Les données du coffre-fort ne transitent jamais par les serveurs de Bitwarden.

Comment configurer l'accès d'urgence dans Vaultwarden ?

L'accès d'urgence permet à un contact de confiance d'accéder à votre coffre-fort ou d'en prendre le contrôle si vous devenez indisponible. Le SMTP doit être configuré car Vaultwarden envoie des e-mails de notification pendant le processus.

Confirmez que la fonctionnalité est activée dans votre .env :

EMERGENCY_ACCESS_ALLOWED=true

Configurer un contact de confiance :

  1. Connectez-vous au coffre-fort web à https://vault.example.com
  2. Allez dans Settings > Emergency Access
  3. Cliquez sur Add emergency contact
  4. Entrez l'adresse e-mail de la personne de confiance (elle doit avoir un compte sur votre instance Vaultwarden)
  5. Choisissez le niveau d'accès :
    • View : le contact peut consulter les éléments de votre coffre-fort (lecture seule)
    • Takeover : le contact peut réinitialiser votre mot de passe maître et prendre le contrôle total
  6. Définissez le délai d'attente (1 à 90 jours). C'est le délai entre la demande d'accès du contact et l'obtention effective. Vous recevez une notification par e-mail et pouvez rejeter la demande pendant cette période.
  7. Cliquez sur Save

Le contact de confiance reçoit un e-mail d'invitation. Après acceptation, il apparaît comme contact d'urgence en attente. Le délai d'attente fonctionne comme un dispositif de sécurité : si vous ne répondez pas dans le nombre de jours configuré, l'accès est accordé automatiquement.

Pour un coffre-fort personnel, un délai de 7 jours avec un accès View est raisonnable. Pour une infrastructure d'équipe partagée, envisagez des délais plus courts.

Comment sauvegarder et restaurer une instance Vaultwarden ?

Vaultwarden stocke tout dans le répertoire /data : la base de données SQLite (db.sqlite3), les pièces jointes, le cache d'icônes et la configuration. Une sauvegarde correcte capture l'ensemble de manière cohérente.

La base de données SQLite doit être sauvegardée avec sqlite3 .backup, pas en copiant le fichier directement. Copier un fichier SQLite en cours d'utilisation peut produire une sauvegarde corrompue si une écriture survient pendant la copie. La commande .backup crée un instantané cohérent.

Quoi sauvegarder Emplacement Méthode Fréquence
Base de données SQLite /opt/vaultwarden/data/db.sqlite3 sqlite3 .backup Quotidienne
Pièces jointes /opt/vaultwarden/data/attachments/ rsync ou cp -a Quotidienne
Cache d'icônes /opt/vaultwarden/data/icon_cache/ Ne pas sauvegarder (régénéré automatiquement) -
Fichier d'environnement /opt/vaultwarden/.env cp À chaque modification
Fichier Compose /opt/vaultwarden/compose.yaml cp À chaque modification

Script de sauvegarde

Pour les sauvegardes automatisées, le script utilise age avec un fichier de clé de destinataire. Cela évite les invites de phrase de passe interactives pour que le script puisse tourner depuis cron.

Générez une paire de clés (une seule fois) :

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

La commande affiche la clé publique sur stdout. Enregistrez-la dans un fichier de destinataire :

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

Conservez une copie de backup-key.txt (la clé privée) en dehors du serveur. Vous en aurez besoin pour déchiffrer les sauvegardes. Si vous perdez cette clé, vos sauvegardes chiffrées seront irrécupérables.

Créez /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

Pour des sauvegardes quotidiennes automatisées, ajoutez une tâche cron :

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

Pour les copies hors site, envoyez la sauvegarde chiffrée vers un serveur distant ou un stockage objet :

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

Procédure de restauration

Une sauvegarde que vous n'avez jamais restaurée est une sauvegarde à laquelle vous ne pouvez pas faire confiance. La procédure complète :

# 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

Vous devez supprimer les fichiers WAL (Write-Ahead Log) et SHM avant de restaurer. Ces fichiers appartiennent à l'ancien état de la base de données. Démarrer Vaultwarden avec une base de données restaurée mais des fichiers WAL périmés corrompt les données.

Après la restauration, connectez-vous au coffre-fort web et confirmez que vos entrées sont bien présentes.

Comment mettre à jour Vaultwarden en toute sécurité ?

Fixez votre image sur un tag de version spécifique (nous avons utilisé 1.35.4). N'utilisez jamais :latest en production car vous ne pouvez pas suivre ce qui a changé ni revenir en arrière de manière fiable.

Pour mettre à jour :

cd /opt/vaultwarden

# Back up first
./backup.sh

# Pull the new version
docker compose pull

# Recreate the container
docker compose up -d

Avant de tirer l'image, éditez compose.yaml pour changer le tag de version. Consultez les notes de version pour les changements cassants.

docker compose logs --tail 30

Si la mise à jour pose problème, restaurez depuis votre sauvegarde :

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

Quelque chose ne fonctionne pas ?

Le conteneur s'arrête immédiatement :

docker compose logs

Cherchez les erreurs de permissions. La directive user: 1000:1000 nécessite des permissions correspondantes sur /opt/vaultwarden/data. Lancez chown -R 1000:1000 /opt/vaultwarden/data et réessayez.

Impossible d'accéder au coffre-fort web :

Vérifiez que le reverse proxy transfère bien vers 127.0.0.1:8080 :

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

Une réponse 200 signifie que Vaultwarden tourne. Le problème se situe dans la configuration de votre reverse proxy.

Fail2ban ne bannit pas :

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

Si la regex ne correspond à aucune ligne, vérifiez que LOG_FILE=/data/vaultwarden.log est défini dans .env et que le fichier de logs existe à /opt/vaultwarden/data/vaultwarden.log.

Les e-mails ne partent pas :

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

Vérifiez que votre VPS autorise les connexions sortantes sur le port SMTP :

nc -zv smtp.example.com 587

Erreurs de base de données verrouillée :

Cela peut arriver si vous copiez le fichier de base de données pendant que Vaultwarden tourne. Utilisez toujours sqlite3 .backup pour les sauvegardes et arrêtez toujours le conteneur avant de restaurer.

Emplacement des logs :

# 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

Pour la sécurisation des conteneurs Docker au-delà de ce tutoriel, voir Durcissement de la sécurité Docker : mode rootless, Seccomp et AppArmor sur un VPS. Pour les stratégies de sauvegarde de l'ensemble de vos services Docker, voir Sauvegarder et restaurer les volumes Docker sur un VPS.

Copyright 2026 Virtua.Cloud. Tous droits réservés. Ce contenu est une création originale de l'équipe Virtua.Cloud. Toute reproduction, republication ou redistribution sans autorisation écrite est interdite.

Prêt à essayer ?

Déployez votre serveur en quelques secondes. Linux, Windows ou FreeBSD.

Voir les offres VPS