Pourquoi auto-héberger votre gestionnaire de mots de passe ?
Les gestionnaires de mots de passe cloud facturent par utilisateur et par mois, stockent votre coffre chiffré sur des serveurs que vous ne contrôlez pas, et peuvent disparaître ou augmenter leurs tarifs du jour au lendemain. Vaultwarden inverse ce modèle : un conteneur sur votre VPS, un volume Docker à sauvegarder, et un nombre sans limite de compte d'utilisateurs pour un coût d'infrastructure fixe. Comme Vaultwarden parle le protocole Bitwarden, chaque client Bitwarden — extension Chrome, module Firefox, iOS, Android, Windows, Linux, CLI — se connecte à votre instance auto-hébergée sans la moindre modification.
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
Il vous faut un VPS d'au moins 1 vCPU, 512 Mo de RAM, avec Docker installé (Ubuntu 22.04 LTS recommandé). Vous avez aussi besoin d'un nom de domaine pointant vers le VPS — les clients Bitwarden refusent les coffres non-HTTPS, HTTPS est donc obligatoire. Ouvrez les ports 80 et 443 dans votre pare-feu : ufw allow 80 && ufw allow 443.
Déployer Vaultwarden en 5 étapes
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.
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.
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.
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.
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).
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.
Compatibilité client/serveur et erreurs silencieuses
Les clients Bitwarden récents ont introduit un nouveau flux d'authentification initiale qui appelle l'endpoint /identity/accounts/prelogin/password. Les instances Vaultwarden figées sur une version antérieure à 1.36.0 ne connaissent pas cet endpoint et retournent une erreur 404 sans message explicite — le client affiche simplement un échec de connexion générique. Le piège est insidieux : les appareils déjà connectés avant la mise à jour du client continuent de fonctionner normalement, car leur session est déjà établie et ne passe pas par ce nouveau chemin d'authentification. Seuls les nouveaux appareils échouent. Si vous lancez curl https://votre-domaine.com/identity/accounts/prelogin/password -X POST -d '{"email":"[email protected]"}' -H 'Content-Type: application/json' et obtenez un 404, votre serveur est trop ancien.
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
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.
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.
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.
É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.0 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.
Piège SIGNUPS_ALLOWED=false : ne le posez qu'après le premier compte admin
Une erreur courante à l'installation : poser -e SIGNUPS_ALLOWED=false avant d'avoir créé le compte administrateur. Résultat — votre propre instance vous refuse la création de compte et vous ne pouvez plus vous connecter. L'ordre est impératif : (1) démarrez sans ce paramètre, (2) créez immédiatement votre compte admin via l'interface web, (3) puis seulement relancez le conteneur avec SIGNUPS_ALLOWED=false. Si vous avez déjà verrouillé et que vous êtes bloqué, la sortie de secours est d'activer le panneau d'administration via -e ADMIN_TOKEN=$(openssl rand -base64 48) et d'inviter l'utilisateur admin depuis /admin.
Des sauvegardes quotidiennes en une ligne cron
Ajoutez ceci au crontab de root (crontab -e) : 0 3 * * * docker run --rm -v vaultwarden:/data -v /backup:/out busybox tar czf /out/vaultwarden-$(date +%F).tar.gz /data. Exécutez-le tous les jours à 3 h du matin — l'intégralité du coffre (fichier SQLite + pièces jointes) atterrit dans /backup sous forme d'archive horodatée. Envoyez ce répertoire vers S3 ou Backblaze B2 avec rclone pour une protection hors-site.
La documentation officielle
Pour la configuration avancée et les options propres à l'outil, référez-vous à la documentation officielle de Vaultwarden. Ce guide couvre la mise en ligne sur VPS ; la doc éditeur reste la référence pour les réglages fins, les mises à jour majeures et les cas d'usage spécifiques.
