Déployer Vaultwarden sur un VPS : mots de passe auto-hébergés

Pourquoi auto-héberger votre gestionnaire de mots de passe ?

Principaux avantages

• 100 % compatible avec tous les clients Bitwarden officiels — pas de fork, pas d'application maison, rien à réapprendre
• Chiffrement AES-256 de bout en bout : votre mot de passe maître ne quitte jamais votre appareil
• Moins de 50 Mo de RAM au repos — tourne sans peine sur un VPS de 512 Mo aux côtés d'autres services
• Utilisateurs et coffres d'organisation sans limite de comptes, avec partage chiffré et accès selon les rôles
• Authentificateur TOTP intégré : remplacez Google Authenticator par une alternative auto-hébergée
• Accès d'urgence — accordez à un contact de confiance un accès en lecture après un délai d'attente configurable

Prérequis

Déployer Vaultwarden en 5 étapes

1. 01

   Installer Docker

   Si Docker n'est pas déjà installé : curl -fsSL https://get.docker.com | sh && systemctl enable --now docker. Vérifiez avec docker --version.

2. 02

   Démarrer Vaultwarden

   Lancez le conteneur : docker run -d --name vaultwarden --restart=always -v vaultwarden:/data -p 127.0.0.1:8000:80 -e WEBSOCKET_ENABLED=true vaultwarden/server:latest. Le serveur démarre en moins d'une seconde et écoute sur le port 8000 en localhost.

3. 03

   Configurer HTTPS avec Caddy

   Installez Caddy : apt install -y caddy. Créez /etc/caddy/Caddyfile avec : passwords.votre-domaine.com { reverse_proxy localhost:8000 }. Rechargez Caddy : systemctl reload caddy. Un certificat TLS Let's Encrypt est provisionné automatiquement et renouvelé indéfiniment — zéro configuration.

4. 04

   Créer votre compte

   Ouvrez https://passwords.votre-domaine.com dans votre navigateur. Cliquez sur « Create Account », choisissez un mot de passe maître robuste (il chiffre tout localement avant que quoi que ce soit ne soit envoyé au serveur), et votre coffre est actif immédiatement.

5. 05

   Verrouiller les inscriptions

   Une fois tous les comptes créés, arrêtez le conteneur et relancez-le en ajoutant -e SIGNUPS_ALLOWED=false à la commande docker run. Votre instance est désormais accessible sur invitation uniquement. Pour la gestion continue des utilisateurs, activez le panneau d'administration en ajoutant -e ADMIN_TOKEN=$(openssl rand -base64 48).

6. 06

   Se connecter la première fois

   À la première ouverture de l'URL, Vaultwarden affiche le coffre web Bitwarden : cliquez sur « Créer un compte » et définissez vous-même votre e-mail et votre mot de passe maître (il n'est récupérable par personne, pas même par nous). Faites-le IMMÉDIATEMENT : l'inscription est ouverte.

Configurer le SMTP et la 2FA par e-mail

Configurer SMTP correctement

1. 07

   Choisir port et sécurité selon votre fournisseur

   Consultez la documentation de votre relais SMTP (Gmail, Brevo, Postmark, SendGrid…). Règle pratique : si votre fournisseur indique le port 465 → SMTP_SECURITY=force_tls ; s'il indique le port 587 → SMTP_SECURITY=starttls. Ne mélangez pas les deux.

2. 08

   Passer les variables SMTP au conteneur

   Relancez le conteneur avec les variables nécessaires :

   docker run -d --name vaultwarden --restart=always \
     -v vaultwarden:/data \
     -p 127.0.0.1:8000:80 \
     -e SMTP_HOST=smtp.votre-fournisseur.com \
     -e [email protected] \
     -e SMTP_PORT=587 \
     -e SMTP_SECURITY=starttls \
     -e SMTP_USERNAME=votre_login \
     -e SMTP_PASSWORD=votre_mot_de_passe \
     vaultwarden/server:latest

3. 09

   Tester l'envoi depuis le panneau admin

   Ouvrez https://passwords.votre-domaine.com/admin, faites défiler jusqu'à la section SMTP Email Settings et utilisez le bouton Send test email. Si l'e-mail n'arrive pas dans les 60 secondes, vérifiez les logs du conteneur : docker logs vaultwarden 2>&1 | grep -i smtp. Un message Connection refused indique un mauvais port ; TLS handshake error indique une incompatibilité de sécurité.

4. 10

   Activer la 2FA par e-mail seulement après avoir validé l'envoi

   N'activez _ENABLE_EMAIL_2FA=true qu'une fois l'envoi de test confirmé. Si vous l'activez avant, les utilisateurs dont le client demande un code ne reçoivent rien et se retrouvent bloqués. Pour débloquer un compte verrouillé : ouvrez /admin, localisez l'utilisateur et cliquez Deactivate TOTP pour désactiver temporairement la 2FA.

Compatibilité client/serveur et erreurs silencieuses

Symptômes d'un mismatch de version client/serveur

• Connexion impossible sur un nouvel appareil ou navigateur, alors que les appareils existants fonctionnent normalement
• Message d'erreur générique sans indication de cause ("An error has occurred" ou "Invalid username or password")
• L'extension Chrome ou Firefox fraîchement installée échoue, mais la version identique sur un autre poste fonctionne
• Le coffre web Bitwarden hébergé sur votre instance répond 404 sur /identity/accounts/prelogin/password
• Aucune erreur dans les logs Vaultwarden côté serveur — l'endpoint n'existe pas, il n'y a rien à logger
• Le problème est apparu après une mise à jour automatique du client Bitwarden sur le nouvel appareil

Diagnostiquer et résoudre le mismatch

1. 11

   Vérifier la version de votre serveur

   Interrogez l'endpoint de version : curl https://votre-domaine.com/api/version. Si la réponse affiche une version antérieure à 1.36.0, votre serveur ne supporte pas le nouveau flux d'authentification des clients récents.

2. 12

   Mettre à jour vers la dernière image

   La solution la plus sûre est d'utiliser systématiquement vaultwarden/server:latest et de maintenir l'image à jour. Pour mettre à jour : docker pull vaultwarden/server:latest && docker stop vaultwarden && docker rm vaultwarden, puis relancez la même commande docker run qu'à l'installation. Vaultwarden preserve les données dans le volume — aucune migration manuelle n'est nécessaire.

3. 13

   Vérifier que la mise à jour a pris effet

   Après redémarrage, interrogez à nouveau curl https://votre-domaine.com/api/version et confirmez que la version est 1.36.0 ou supérieure. Testez ensuite la connexion depuis un nouvel onglet de navigation privée.

4. 14

   Épingler une version si la stabilité prime

   Si vous préférez contrôler manuellement les mises à jour, utilisez un tag versionné : vaultwarden/server:1.37.2 par exemple. Dans ce cas, surveillez les releases sur GitHub et mettez à jour dès qu'une nouvelle version client Bitwarden est déployée — les deux sont couplés.

Coffre vide après la mise à jour des clients Bitwarden 2026.8.0 : diagnostic et parade

Symptômes de ce défaut de compatibilité

• Connexion acceptée, mais coffre vide ou qui ne se charge pas après la synchronisation
• Pas de suggestions d'auto-remplissage, application de bureau qui plante ou extension qui affiche « failed to fetch »
• Dans la console du navigateur, l'erreur RangeError: Invalid time value dans toSdkPolicyView (relevée dans le ticket #7612)
• Aucune erreur dans les journaux du serveur Vaultwarden
• Cas rapportés surtout sur des comptes membres d'une organisation qui a au moins une politique configurée, même désactivée ; l'interface web servie par Vaultwarden fonctionne

Diagnostiquer et réparer un coffre vide

1. 15

   Vérifier la version du serveur

   Ouvrez /admin/diagnostics ou lancez docker exec vaultwarden /vaultwarden --version. Il faut 1.37.2 au minimum pour les clients 2026.8.0+. Assurez-vous aussi qu'une seule instance tourne : un fichier compose en double a déjà causé des symptômes identiques.

2. 16

   Mettre le serveur à jour si besoin

   Utilisez la même procédure que pour toute mise à jour (récupérer l'image, recréer le conteneur sur le même volume). Visez directement la dernière version : voir la section sur la 1.37.4 plus bas.

3. 17

   Nettoyer l'état local du client

   Déconnectez-vous complètement puis reconnectez-vous. Si le coffre reste vide, vider le stockage de l'extension (les entrées policies) ou la désinstaller puis la réinstaller règle la plupart des cas. Sur macOS, certains utilisateurs ont dû supprimer les données du conteneur de l'application de bureau avant de se reconnecter.

4. 18

   Contrôler l'environnement avant de rétrograder

   Consultez /admin/diagnostics pour les en-têtes manquants (une erreur de TOTP a été corrigée ainsi), gardez l'administration et le coffre sur le même domaine, et testez en désactivant les bloqueurs de publicités. En dernier recours seulement, repassez les clients en 2026.7.0, version qui fonctionnait pour les premiers rapporteurs, en attendant la mise à jour du serveur.

Mise à jour 1.37.4 : sept correctifs de sécurité et ruptures à connaître

Les sept avis de sécurité de la 1.37.4

• Révocation de membres d'une organisation : gravité haute, 8.1 (GHSA-69q9-v8p6-xvx3)
• Authentification à deux facteurs : gravité moyenne, 6.8 (GHSA-7jg8-8m5x-6j9r)
• Invitations d'organisation : gravité moyenne, 6.8 (GHSA-v576-3wvq-xh3c)
• Pièces jointes : gravité moyenne, 6.5 (GHSA-q5x6-grh5-fqgc)
• Journaux d'événements d'organisation : gravité moyenne, 4.3 (GHSA-64mc-4p6f-r7x9)
• Partage d'éléments : gravité moyenne, 4.3 (GHSA-7ccc-c43j-4p36)
• Clé d'API d'organisation : gravité basse, 3.8 (GHSA-qwx4-wcv4-mpcv)

Avant de passer en 1.37.4 : ce qui peut casser

1. 19

   Reverse proxy et IP du client

   Avec IP_HEADER=X-Forwarded-For, l'adresse retenue est désormais l'adresse la plus à droite qui ne figure pas dans IP_HEADER_TRUSTED_PROXIES (avant : la plus à gauche). Si plusieurs proxies se suivent devant Vaultwarden, listez-les tous dans IP_HEADER_TRUSTED_PROXIES, sinon vos journaux et limites de débit verront la mauvaise adresse.

2. 20

   Sends et CLI

   bw send receive ne fonctionne plus avec le CLI 2026.4.2 et antérieur. Créer et gérer des Sends reste possible avec tous les clients : mettez à jour le CLI si vous recevez des Sends en ligne de commande.

3. 21

   MariaDB ou MySQL sans TLS

   Si votre serveur de base ne gère pas les connexions TLS natives, l'image Alpine peut échouer à s'y connecter. Ajoutez MARIADB_TLS_DISABLE_PEER_VERIFICATION=1 à l'environnement de Vaultwarden. Avec SQLite, par défaut dans ce guide, vous n'êtes pas concerné.

4. 22

   Options et points d'accès retirés

   Plusieurs drapeaux expérimentaux (par exemple ssh-agent ou mutual-tls) ont été supprimés : s'ils figurent encore dans EXPERIMENTAL_CLIENT_FEATURE_FLAGS, le démarrage journalise un avertissement et l'enregistrement des réglages du panneau d'administration échoue tant qu'ils n'en sont pas retirés. DUO_USE_IFRAME est supprimée et ignorée. Les anciens points d'accès POST /identity/accounts/register et POST /api/accounts/prelogin sont retirés ; les notes indiquent qu'aucun client actuel ne les utilise.

5. 23

   Faire pivoter la clé d'API d'organisation

   Avant cette version, les administrateurs d'une organisation pouvaient aussi consulter sa clé d'API. Si certains ne sont pas entièrement de confiance, faites pivoter la clé après la mise à jour (console d'administration, Paramètres, Faire pivoter la clé d'API).

Bitwarden passe en double licence : ce qui change, ce qui ne change pas

Ce qui change et ce qui ne change pas pour Vaultwarden

• Ne change pas : Bitwarden indique qu'il n'y a aucun changement pour l'auto-hébergement ; le serveur Vaultwarden est un projet indépendant, sous licence AGPL-3.0, qui n'est pas concerné par la licence des clients
• Ne change pas : les fonctionnalités actuelles restent disponibles dans les deux versions des clients, offre gratuite comprise ; aucune action n'est demandée aux utilisateurs existants
• À surveiller : Bitwarden prévient que certains composants futurs ne seront publiés que sous licence commerciale, et que chaque nouvelle fonctionnalité sera jugée au cas par cas ; les clients des boutiques et la version GPLv3 pourraient diverger
• À surveiller : si une fonctionnalité future n'existe que dans le build commercial, rien ne garantit qu'elle fonctionne avec un serveur tiers ; testez chaque mise à jour de client sur un compte secondaire avant de la généraliser
• Si vous voulez rester sur le code GPLv3, vous pouvez compiler les clients depuis le dépôt GitHub, au prix d'un entretien à votre charge