Auto-héberger Vaultwarden : créer un coffre de mots de passe sécurisé

Auto-héberger Vaultwarden : créer un coffre de mots de passe sécurisé
Auto-héberger Vaultwarden consiste à installer sur son serveur un gestionnaire de mots de passe compatible avec les applications Bitwarden. La méthode la plus accessible repose sur Docker, un nom de domaine, un mandataire inverse HTTPS et des sauvegardes testées. Le point critique n’est pas le démarrage du conteneur : c’est la protection durable du serveur Vaultwarden.
Ce tutoriel détaille un déploiement Docker progressif, puis les choix à effectuer pour sécuriser Vaultwarden, connecter un téléphone et un navigateur, bloquer les inscriptions publiques, sauvegarder les données et maintenir le service. Les méthodes Debian, NAS Synology et hébergement géré sont présentées à part pour éviter de mélanger les parcours.
En bref
🔒 Vaultwarden est un serveur de coffre-fort de mots de passe auto-hébergé compatible avec l’écosystème Bitwarden. Il n’existe pas d’application mobile Vaultwarden officielle : les clients Bitwarden sont utilisés pour les navigateurs et les téléphones.
⚙️ Le parcours recommandé utilise Docker Compose, avec un volume persistant pour les données et la commande docker compose up -d pour lancer le service. Un reverse proxy gère ensuite l’accès HTTPS.
💾 Une instance exposée à Internet doit combiner HTTPS, inscriptions désactivées, jeton d’administration Argon2, mises à jour et sauvegardes restaurables. Sans cette discipline, l’auto-hébergement ajoute plus de risques qu’il n’en retire.
Vaultwarden est-il adapté à un gestionnaire de mots de passe personnel ?
Vaultwarden est un serveur open source écrit en Rust qui implémente la compatibilité avec l’écosystème Bitwarden. Vaultwarden convient à une personne, un foyer ou une petite équipe capable d’administrer un serveur, de surveiller les mises à jour et de restaurer une sauvegarde. Un gestionnaire de mots de passe personnel auto-hébergé donne davantage de contrôle, mais transfère aussi la responsabilité de disponibilité et de sécurité.
Vaultwarden, Bitwarden et les clients compatibles
La différence Vaultwarden Bitwarden doit être comprise avant l’installation : Bitwarden fournit notamment les applications officielles et son propre service hébergé, tandis que Vaultwarden est un serveur communautaire compatible avec les clients Bitwarden. L’extension de navigateur Bitwarden, l’application mobile Bitwarden et les applications de bureau Bitwarden peuvent être configurées en mode auto-hébergé avec l’adresse de votre serveur Vaultwarden.
Ce que l’auto-hébergement apporte réellement
Un serveur Vaultwarden permet de conserver les données chiffrées sur une infrastructure choisie par l’utilisateur, à domicile, sur un serveur privé virtuel ou sur un NAS. Le gain de contrôle ne remplace jamais les tâches d’exploitation : mises à jour, sauvegardes, certificat HTTPS et supervision restent à votre charge.
- Choix de l’emplacement de stockage et de la stratégie de sauvegarde.
- Compatibilité avec les clients Bitwarden pour les appareils courants.
- Possibilité de désactiver les inscriptions et de limiter les utilisateurs autorisés.
- Accès distant possible avec un nom de domaine et HTTPS correctement configurés.
Les limites à accepter avant de commencer
Un serveur Vaultwarden indisponible empêche la synchronisation des nouveaux éléments et peut compliquer l’accès depuis un nouvel appareil. Un serveur mal exposé peut aussi devenir une cible, car il héberge un service lié aux identifiants. L’auto-hébergement d’un gestionnaire de mots de passe reste donc un projet d’administration système, même si l’installation initiale prend peu de temps.
Un coffre de mots de passe auto-hébergé n’est fiable que si son exploitation est aussi sérieuse que son installation.
Quelle méthode choisir pour installer Vaultwarden ?
Docker est le choix le plus simple pour un serveur Linux polyvalent, car le déploiement est regroupé dans un fichier docker-compose.yml. Un NAS Synology convient si Container Manager est déjà maîtrisé, tandis qu’une installation APT sur Debian reste une variante pour les administrateurs qui préfèrent systemd. Un hébergement géré réduit la charge d’administration mais réduit aussi le contrôle sur l’infrastructure.
| Méthode | Usage adapté | Atout principal | Limite à prévoir |
|---|---|---|---|
| Docker Compose | Serveur Linux ou VPS | Déploiement lisible et reproductible | Docker, HTTPS et sauvegardes à administrer |
| Paquet APT Debian | Administrateur Debian à l’aise avec systemd | Intégration au service système | Dépôt communautaire non officiel à évaluer |
| NAS Synology et Container Manager | Foyer déjà équipé d’un NAS | Interface graphique et stockage local | Configuration réseau et sauvegarde du NAS |
| Hébergement géré | Besoin d’éviter l’administration serveur | Déploiement plus rapide | Coût et contrôle d’infrastructure variables |
Le parcours ci-dessous privilégie Docker Compose, car cette méthode reste portable entre un mini-PC, un Raspberry Pi compatible, un NAS capable d’exécuter Docker et un serveur privé virtuel. La documentation officielle de Docker doit servir de référence pour l’installation du moteur Docker et du plugin Compose sur votre système d’exploitation.
Préparer le serveur Vaultwarden avant le déploiement
Un serveur Vaultwarden doit disposer d’un système maintenu, de Docker Compose fonctionnel, d’un espace de stockage persistant et d’un accès d’administration protégé. Un nom de domaine est nécessaire si l’instance doit être utilisée hors du réseau local, car les clients Bitwarden doivent rejoindre une adresse HTTPS stable.

Pré requis techniques
La procédure suppose un serveur Linux déjà administrable, un compte disposant des droits nécessaires pour exécuter Docker et un reverse proxy déjà installé ou prévu. Le guide n’impose pas une distribution précise, car les commandes d’installation de Docker et de pare-feu varient selon Debian, Ubuntu, Fedora ou d’autres systèmes.
- Un serveur Linux, un NAS compatible Docker ou une machine dédiée maintenue.
- Docker Engine et Docker Compose installés depuis la documentation officielle Docker.
- Un nom de domaine, si l’accès à Vaultwarden à distance est prévu.
- Un reverse proxy tel que Nginx ou Traefik pour gérer le trafic HTTPS.
- Un emplacement de sauvegarde distinct du serveur qui exécute Vaultwarden.
Préparer le réseau sans exposer inutilement le service
Un reverse proxy reçoit habituellement les connexions HTTP et HTTPS sur les ports 80 et 443, puis transmet les requêtes au conteneur Vaultwarden. Le conteneur Vaultwarden utilise le port 80 en interne, mais le choix d’exposition côté hôte dépend de l’architecture retenue. Une instance uniquement domestique peut rester accessible sur le réseau local ; une instance distante demande un HTTPS valide et une surface d’exposition limitée.
Un service auto-hébergé peut compléter un environnement personnel plus large, par exemple un cloud privé Nextcloud sur serveur personnel. Les deux services doivent toutefois conserver des sauvegardes séparées et des mises à jour indépendantes : regrouper plusieurs outils sur la même machine ne supprime pas le risque de panne commune.
Comment installer Vaultwarden avec Docker étape par étape ?
Pour installer Vaultwarden avec Docker, créez un dossier persistant, rédigez un fichier Compose minimal, démarrez le conteneur puis vérifiez son état. Cette première installation doit rester locale ou protégée par le reverse proxy tant que HTTPS et les réglages d’administration ne sont pas finalisés.
Étape 1 : créer le répertoire persistant
Créez un dossier de projet dédié à Vaultwarden et un sous-dossier de données. Le dossier monté dans le conteneur doit survivre à une mise à jour ou à une recréation du conteneur ; il contient notamment la base SQLite utilisée par défaut et les données nécessaires au service.
- Connectez-vous au serveur avec le compte d’administration habituel.
- Créez un répertoire de projet, par exemple
vaultwarden, dans un emplacement sauvegardé. - Créez le sous-répertoire
dataqui sera monté dans le conteneur sous/data. - Vérifiez que le compte utilisé par Docker peut lire et écrire dans ce répertoire.
Le résultat attendu est un emplacement persistant clairement identifié pour la sauvegarde Vaultwarden. Ne placez pas les données dans un dossier temporaire ou dans un répertoire personnel oublié : une mise à jour réussie n’a aucune valeur si les données ne sont pas récupérables après incident.
Étape 2 : rédiger le fichier docker-compose.yml
Dans le dossier du projet, créez un fichier nommé docker-compose.yml. Le fichier suivant déploie l’image officielle publiée pour Vaultwarden, conserve les données dans ./data et bloque les inscriptions publiques. Le port n’est pas publié directement dans cet exemple : le reverse proxy devra rejoindre le service via le réseau Docker configuré dans votre environnement.
services:
vaultwarden:
image: vaultwarden/server:latest
container_name: vaultwarden
restart: unless-stopped
environment:
SIGNUPS_ALLOWED: "false"
volumes:
- ./data:/data
La variable SIGNUPS_ALLOWED: "false" empêche la création libre de nouveaux comptes. Une instance accessible depuis Internet ne doit pas accepter les inscriptions publiques sans besoin explicite et sans contrôle des utilisateurs créés.
Étape 3 : démarrer le conteneur et contrôler son état
Exécutez la commande suivante depuis le dossier qui contient le fichier Compose. Docker Compose télécharge l’image si nécessaire, crée le conteneur et le lance en arrière-plan.
docker compose up -d
Vérifiez ensuite l’état avec docker compose ps et consultez les journaux avec docker compose logs si le conteneur ne reste pas actif. Le résultat attendu est un conteneur Vaultwarden en fonctionnement ; l’interface web ne doit pas encore être considérée comme prête pour un accès public sans HTTPS.

Comment activer HTTPS et sécuriser l’accès extérieur ?
Vaultwarden HTTPS est indispensable dès qu’un téléphone ou un navigateur se connecte hors du réseau local. Un mandataire inverse comme Nginx ou Traefik reçoit les connexions publiques, présente le certificat TLS et transmet les requêtes vers Vaultwarden. Traefik peut gérer des certificats Let’s Encrypt selon sa configuration ; Nginx peut aussi être utilisé avec un certificat valide.
Étape 4 : relier Vaultwarden au reverse proxy
Connectez le conteneur Vaultwarden au réseau Docker utilisé par votre reverse proxy, puis créez une règle pour le sous-domaine choisi, par exemple coffre.exemple.fr. La syntaxe exacte varie selon Traefik, Nginx Proxy Manager ou Nginx ; suivez la documentation officielle de l’outil retenu plutôt qu’un extrait générique incompatible avec votre installation.
Un reverse proxy doit envoyer les requêtes vers le service Vaultwarden sans publier une interface d’administration distincte sur Internet. Le certificat doit correspondre au nom de domaine configuré dans les applications Bitwarden, faute de quoi les clients peuvent refuser la connexion ou afficher une alerte de sécurité.
Étape 5 : vérifier le certificat avant de connecter les appareils
Ouvrez l’URL HTTPS dans un navigateur depuis un réseau extérieur au serveur et contrôlez le certificat affiché par le navigateur. Vérifiez aussi que le renouvellement automatique du certificat est prévu par votre reverse proxy. Un certificat expiré bloque rapidement l’accès aux nouveaux appareils et crée un risque d’acceptation imprudente d’alertes de sécurité.
HTTPS protège le transport entre le client Bitwarden et le serveur ; il ne dispense ni de sauvegarder les données, ni de maintenir le serveur.
Effectuer la première configuration de Vaultwarden
La première configuration Vaultwarden consiste à créer le premier compte depuis l’interface HTTPS, à enregistrer quelques éléments de test et à connecter les clients Bitwarden en mode auto-hébergé. Le mot de passe maître doit être long, unique et conservé selon une méthode de récupération choisie avant tout usage quotidien.
Étape 6 : créer le premier compte et vérifier le coffre
Ouvrez l’adresse HTTPS de Vaultwarden dans un navigateur et créez le premier compte seulement si les inscriptions sont temporairement autorisées dans un environnement contrôlé. Désactivez ensuite les inscriptions, ou conservez SIGNUPS_ALLOWED à false et utilisez le mécanisme d’invitation approprié à votre configuration. Ajoutez un élément de test, déconnectez-vous puis reconnectez-vous afin de vérifier que le coffre est bien synchronisé.
Étape 7 : connecter le navigateur et le téléphone
Installez les clients officiels Bitwarden depuis leurs canaux officiels, puis choisissez l’option d’environnement auto-hébergé dans l’écran de connexion. Saisissez l’URL HTTPS complète de votre serveur Vaultwarden avant de vous authentifier. La même adresse doit être utilisée sur l’extension navigateur, l’application de bureau et l’application mobile afin d’éviter de créer des coffres distincts par erreur.
Étape 8 : protéger l’administration
L’interface d’administration Vaultwarden doit être protégée par un jeton d’administration stocké sous forme de hash Argon2. Sur Linux, les paquets argon2 et openssl peuvent être installés pour préparer ce jeton ; la génération et le format du hash doivent suivre la documentation officielle de Vaultwarden correspondant à la version déployée.
Ajoutez uniquement le hash obtenu dans la variable d’environnement prévue pour l’administration, puis redémarrez le service avec Docker Compose. Restreignez également l’accès à l’interface d’administration au réseau local ou à une liste d’adresses IP lorsque le reverse proxy le permet. Ne publiez jamais un jeton réel dans un fichier partagé, un dépôt Git ou une capture d’écran.
Comment renforcer la sécurité de Vaultwarden ?
Sécuriser Vaultwarden demande de traiter les comptes, le serveur et le réseau comme un ensemble. Les clients Bitwarden doivent utiliser un mot de passe maître unique et une double authentification lorsque celle-ci est disponible. Le serveur doit recevoir les correctifs, limiter les services ouverts et conserver des journaux consultables en cas d’incident.
Réduire les accès inutiles
Le pare-feu du serveur ne doit autoriser que les flux nécessaires à votre architecture, généralement ceux du reverse proxy et de l’administration système. L’interface Vaultwarden ne doit pas être exposée directement si le reverse proxy assure déjà l’accès HTTPS. Une restriction par réseau local ou liste blanche IP constitue une couche supplémentaire utile pour l’administration.
Activer la double authentification
La double authentification réduit le risque lié au vol d’un mot de passe maître, sans supprimer les autres risques. Vaultwarden peut être configuré avec des options compatibles avec certains dispositifs matériels, dont YubiKey, selon les variables documentées par le projet et les identifiants obtenus auprès de Yubico. Vérifiez la procédure de récupération avant d’activer une méthode de double authentification sur tous les comptes.
Protéger aussi le serveur hôte
Le serveur qui héberge Vaultwarden doit recevoir ses mises à jour de sécurité, utiliser un accès administrateur robuste et éviter les services inutiles. Un compte SSH protégé, des clés d’accès conservées hors du serveur et une supervision minimale sont plus utiles qu’un empilement de réglages décoratifs. Une compromission du serveur hôte peut annuler les protections ajoutées au conteneur.
Sauvegarder Vaultwarden et tester une restauration
Une sauvegarde Vaultwarden doit couvrir le dossier persistant monté dans /data, car ce dossier contient les données du service, y compris la base SQLite utilisée par défaut. Une copie stockée sur le même disque ou le même NAS protège mal contre une panne matérielle, une erreur de manipulation ou un chiffrement malveillant.
Étape 9 : mettre en place une sauvegarde hors du serveur
Planifiez une sauvegarde régulière du dossier data vers un stockage distinct et chiffré. Sur Synology, Hyper Backup peut être utilisé vers une destination externe selon l’architecture choisie. Le calendrier dépend du volume de modifications, mais la règle opérationnelle reste simple : la fréquence de sauvegarde doit correspondre à la quantité de données que vous acceptez de perdre.
- Identifiez le dossier persistant monté dans
/data. - Créez une tâche de sauvegarde vers un emplacement distinct du serveur principal.
- Conservez plusieurs versions pour limiter l’impact d’une suppression ou d’une corruption tardivement détectée.
- Protégez l’accès au stockage de sauvegarde avec des identifiants distincts.
- Documentez la procédure de restauration dans un emplacement accessible hors du coffre.
Étape 10 : tester la restauration avant une panne
Une sauvegarde non restaurée est une hypothèse, pas une garantie. Testez la restauration dans un environnement séparé, avec une copie des données et sans exposer l’instance de test sur Internet. Le résultat attendu est la réapparition des comptes et des éléments de coffre dans une instance temporaire, sans écraser le serveur de production.

Mettre à jour Vaultwarden sans perdre les données
Mettre à jour Vaultwarden consiste à récupérer l’image plus récente, à recréer le conteneur et à conserver le volume de données intact. La commande exacte dépend du fichier Compose, mais le répertoire data ne doit jamais être supprimé pendant l’opération. Consultez les notes de version du projet avant toute mise à jour importante.
Étape 11 : appliquer une mise à jour contrôlée
Commencez par vérifier que la sauvegarde récente est disponible et que le conteneur fonctionne normalement. Téléchargez ensuite l’image prévue par votre fichier Compose, recréez le service et contrôlez les journaux. Une mise à jour doit être faite pendant une période où une brève indisponibilité est acceptable, surtout pour un coffre utilisé par plusieurs personnes.
docker compose pull
docker compose up -d
docker compose ps
Le résultat attendu est un conteneur actif avec les mêmes données persistantes qu’avant l’opération. Si un comportement anormal apparaît, consultez les journaux et restaurez uniquement après avoir compris si le problème vient de l’image, de la configuration ou du reverse proxy.
Erreurs fréquentes lors de l’auto-hébergement de Vaultwarden
Les difficultés les plus courantes ne viennent pas de Vaultwarden lui-même, mais d’un chaînage incomplet entre Docker, le nom de domaine, HTTPS et les sauvegardes. Chaque erreur ci-dessous peut être évitée par une vérification précise avant de rendre le coffre accessible à tous les appareils.
- Exposer Vaultwarden sans HTTPS : le navigateur ou les clients peuvent signaler une connexion non fiable. Utilisez un reverse proxy et un certificat valide avant tout accès distant.
- Laisser les inscriptions ouvertes : une instance publique peut recevoir des comptes non souhaités. Définissez
SIGNUPS_ALLOWEDàfalseaprès la création contrôlée des comptes. - Oublier le dossier persistant : une recréation du conteneur peut alors faire disparaître les données. Montez systématiquement un volume vers
/data. - Utiliser le même serveur pour la production et l’unique sauvegarde : une panne unique peut toucher les deux copies. Préparez une destination séparée.
- Configurer les applications sur le service Bitwarden public : les appareils ne verront pas le coffre auto-hébergé. Sélectionnez le mode auto-hébergé et saisissez l’URL HTTPS de votre serveur.
Vaultwarden, Bitwarden hébergé ou KeePassXC : que choisir ?
Vaultwarden convient lorsque le contrôle du serveur et la synchronisation multi-appareils justifient une charge d’administration régulière. Le service Bitwarden hébergé convient lorsque la priorité est de déléguer l’infrastructure. KeePassXC répond à un autre modèle, davantage centré sur un fichier de coffre local synchronisé par vos propres moyens.
| Solution | À privilégier si | Arbitrage principal |
|---|---|---|
| Vaultwarden auto-hébergé | Vous administrez déjà un serveur et voulez contrôler l’hébergement | Maintenance, sécurité et disponibilité à votre charge |
| Bitwarden hébergé | Vous cherchez une synchronisation gérée sans serveur personnel | Moins de contrôle sur l’infrastructure |
| KeePassXC | Vous préférez un coffre local sous forme de fichier | Synchronisation et accès mobile à organiser séparément |
Un hébergement géré peut représenter une option intermédiaire. Alwaysdata proposait une offre Small Vaultwarden à 6 € HT par mois en 2024 selon sa page commerciale ; ce tarif historique ne doit pas être considéré comme un prix actuel. Vérifiez toujours les conditions, la localisation des données, la sauvegarde incluse et le coût réel avant de déléguer le service.
À retenir
- 🔒 Vaultwarden reste compatible avec les clients officiels Bitwarden, pas avec une application Vaultwarden dédiée.
- ⚙️ Docker Compose simplifie le déploiement, mais n’automatise ni HTTPS ni la sécurité.
- 🌐 Un accès distant exige un domaine stable, un certificat valide et un reverse proxy.
- 💾 Le dossier
/datadoit être sauvegardé hors du serveur principal et restauré en test. - 🔄 Les mises à jour régulières et les inscriptions désactivées réduisent la surface d’exposition.
Questions fréquentes sur Vaultwarden
Vaultwarden est-il sécurisé ?
Vaultwarden peut constituer une solution robuste si le serveur est maintenu, protégé par HTTPS, sauvegardé et administré avec prudence. Vaultwarden ne garantit pas une sécurité absolue : la qualité du mot de passe maître, du serveur hôte et de la configuration réseau reste déterminante.

Peut-on auto-héberger Vaultwarden sur un NAS Synology ?
Vaultwarden peut être déployé sur un NAS Synology avec Container Manager et l’image vaultwarden/server. Le NAS doit disposer d’un stockage persistant, d’une sauvegarde externe et d’une configuration HTTPS adaptée si l’accès est ouvert hors du réseau local.
Comment utiliser Vaultwarden sur un téléphone ?
Vaultwarden utilise les applications officielles Bitwarden compatibles avec les serveurs auto-hébergés. Dans l’application Bitwarden, sélectionnez l’environnement auto-hébergé, saisissez l’URL HTTPS du serveur Vaultwarden, puis connectez-vous avec votre compte.
Que se passe-t-il si le mot de passe maître est oublié ?
Le mot de passe maître protège le coffre et ne doit pas être considéré comme récupérable par un administrateur de serveur. Préparez une méthode personnelle et sécurisée de conservation ou de récupération avant de confier des identifiants importants au coffre.
Faut-il utiliser SQLite, MySQL ou PostgreSQL avec Vaultwarden ?
Vaultwarden utilise SQLite par défaut et peut aussi être configuré avec MySQL ou PostgreSQL. SQLite reste cohérent pour un usage personnel ou de petite équipe ; un changement de base de données doit être préparé, sauvegardé et vérifié selon la documentation du projet.