Comment auto-héberger Vaultwarden en 2026 : domaines, SMTP et sauvegardes sécurisées

Il existe deux façons de « faire fonctionner Vaultwarden » : un conteneur existe, ou le service remplit réellement sa mission. Seule la seconde compte. Ici, la preuve consiste à se connecter depuis une extension de navigateur, créer un élément, synchroniser un second client, importer une pièce jointe et récupérer un Send après un redémarrage.

Vaultwarden répond à ce besoin : un serveur de mots de passe compact et compatible avec Bitwarden. Le déploiement doit préserver les éléments qui permettent ce fonctionnement ; un port, un volume et un certificat sont des prérequis, pas le résultat.

Les volumes ne constituent que la première couche de récupération

L’ensemble durable à récupérer comprend la base de données, les pièces jointes, les Sends, les clés et la configuration dans /data. Montez /data avant le bootstrap, écrivez des données d’exemple sans risque, puis remplacez le conteneur pour vérifier que ce chemin est réellement persistant. Un volume protège les données contre le remplacement du conteneur, mais pas contre la perte de l’hôte, une suppression accidentelle ou une corruption au niveau de l’application.

Effectuez des sauvegardes adaptées à la source de données : utilisez des dumps logiques pour les bases de données actives lorsque cela est nécessaire et ne copiez les fichiers qu’à partir d’un état cohérent. Conservez une copie chiffrée hors de l’hôte Vaultwarden. Le critère d’acceptation d’une restauration est précis : les éléments du coffre, les pièces jointes, les Sends et l’appartenance à l’organisation doivent se synchroniser correctement avec un client vierge après la restauration. Le guide des sauvegardes dont la restauration a été testée explique pourquoi la réussite d’un job ne suffit pas à elle seule.

Démarrer Vaultwarden sans masquer les composants

Démarrez Vaultwarden de manière à garder la route privée jusqu’à la fin du bootstrap.

docker run -d \
  --name vaultwarden \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v vaultwarden-data:/data \
  -e ADMIN_TOKEN=replace-with-a-long-random-value \
  vaultwarden/server:latest

Si le processus redémarre en boucle, comparez l’utilisateur attendu par l’image avec le propriétaire de chaque chemin monté. S’il reste actif, testez localement le port 80, puis passez directement au workflow : connectez-vous depuis une extension de navigateur, créez un élément, synchronisez un second client, importez une pièce jointe et récupérez un Send après un redémarrage. Ne fixez la version de l’image qu’après la réussite de cette vérification de bout en bout, et consignez la configuration exacte à côté du service.

Définir la frontière d’exécution de Vaultwarden

Définissez trois frontières autour de Vaultwarden : l’ingress vers le port 80, l’état durable et les prérequis de support. Le conteneur peut être remplacé, mais les deux autres éléments doivent avoir des responsables clairement définis. Le prérequis externe de Vaultwarden est un SMTP opérationnel si les invitations et les e-mails d’accès d’urgence sont nécessaires. Testez le DNS sortant, TLS et le comportement du fournisseur sans publier un autre service entrant.

Le schéma est complet lorsqu’un client vierge peut se connecter depuis une extension de navigateur, créer un élément, synchroniser un second client, importer une pièce jointe et récupérer un Send après un redémarrage. Collectez les données de temps et de ressources relatives au volume des pièces jointes, à la contention des écritures SQLite ou aux limites du pool de connexions à la base de données, ainsi qu’à la latence SMTP lors des invitations. Si la transaction échoue, la première frontière qui ne se comporte pas comme documenté indique s’il faut examiner le routage, la capacité locale ou un service de support.

Distinguer les URL internes et externes

Évitez d’utiliser des origines publiques temporaires et permanentes pour Vaultwarden. Définissez plutôt DOMAIN sur l’origine HTTPS externe exacte, dirigez le nom DNS choisi vers la route de la plateforme et faites suivre les requêtes uniquement vers le port 80.

Effectuez cette opération depuis l’extérieur de l’hôte : connectez-vous depuis une extension de navigateur, créez un élément, synchronisez un second client, importez une pièce jointe et récupérez un Send après un redémarrage. En cas d’échec de l’ingress, le guide de dépannage des erreurs 502 couvre les erreurs de port et de listener. Si Vaultwarden reçoit la requête, mais que DOMAIN utilise HTTP alors que le navigateur exige une origine sécurisée pour les fonctionnalités du coffre, les éléments disponibles indiquent désormais un problème situé au-delà du proxy.

Procédure d’acceptation de Vaultwarden en production

La validation de production de Vaultwarden doit pouvoir être exécutée par une personne qui n’a pas réalisé le déploiement. Fournissez-lui la version figée, un compte de test non sensible et cette tâche : se connecter depuis une extension de navigateur, créer un élément, synchroniser un second client, importer une pièce jointe et récupérer un Send après un redémarrage. Si les instructions exigent un accès shell non documenté, le service n’est pas encore prêt sur le plan opérationnel.

Répétez la validation après avoir remplacé uniquement le conteneur. Restaurez ensuite la base de données, les pièces jointes, les Sends, les clés et la configuration dans /data sur une infrastructure vierge, puis vérifiez que les éléments du coffre, les pièces jointes, les Sends et l’appartenance à l’organisation se synchronisent correctement avec un client vierge après la restauration. Mesurez le volume des pièces jointes, la contention des écritures SQLite ou les limites du pool de connexions à la base de données, ainsi que la latence SMTP lors des invitations pendant les deux exécutions réussies ; des différences inattendues révèlent souvent l’absence d’un cache, d’un index, d’un worker ou d’un montage de données.

Ajoutez un exercice de panne : refusez temporairement le chemin de test utilisé par le SMTP opérationnel si les invitations et les e-mails d’accès d’urgence sont nécessaires. Vaultwarden doit générer une erreur utile, préserver l’état existant et récupérer lorsque la condition valide est rétablie. Enregistrez les horodatages et les lignes de log pertinentes, en masquant les secrets. Ces éléments serviront de référence lors de la prochaine modification de l’image ou de la configuration.

Surveiller la charge de travail, pas seulement le conteneur

Un conteneur au vert est nécessaire, mais pas suffisant. L’indicateur de niveau de service est la réussite de « se connecter depuis une extension de navigateur, créer un élément, synchroniser un second client, importer une pièce jointe et récupérer un Send après un redémarrage », tandis que les principaux signaux de pression probables sont le volume des pièces jointes, la contention des écritures SQLite ou les limites du pool de connexions à la base de données, ainsi que la latence SMTP lors des invitations.

La gestion des changements est importante, car les migrations de base de données Vaultwarden et la compatibilité des clients Bitwarden doivent être vérifiées ensemble ; la rotation de ADMIN_TOKEN est une modification de l’accès administrateur, pas une migration des données du coffre. Conservez l’ancienne image, testez les migrations sur un état copié et documentez la prise en charge ou non du rollback après la modification du schéma. Si DOMAIN utilise HTTP alors que le navigateur exige une origine sécurisée pour les fonctionnalités du coffre, diagnostiquez la première frontière qui diffère de l’environnement fonctionnel.

Fermer les accès temporaires de configuration

Un déploiement Vaultwarden sécurisé commence par la suppression des privilèges inutiles. Évitez d’utiliser un token d’administration faible ou de laisser les inscriptions ouvertes ; désactivez plutôt les inscriptions ouvertes à la fin de l’enrôlement, protégez la page d’administration avec un token robuste et exigez HTTPS pour chaque client du coffre.

Remplacez immédiatement l’ADMIN_TOKEN d’exemple, stockez-le en dehors de l’image et faites-le tourner comme un identifiant administrateur s’il est exposé. Restreignez les routes d’administration, utilisez un DNS privé pour les dépendances et examinez chaque montage de volume. Lorsque les logs sont envoyés vers un système centralisé, filtrez les secrets et les contenus privés avant qu’ils ne quittent le serveur.

Utiliser Dockup pour la couche plateforme

Dockup supprime le travail manuel lié au reverse proxy et au cycle de vie de Vaultwarden. Le service reçoit une route HTTPS stable vers le port 80, une configuration injectée et un stockage persistant lors des remplacements. Un serveur client rattaché suit le même modèle que le compute hébergé par Dockup.

Après le lancement, respectez le contrat de l’application : définissez DOMAIN sur l’origine HTTPS externe exacte, autorisez et vérifiez le fonctionnement du SMTP si les invitations et les e-mails d’accès d’urgence sont nécessaires, puis exécutez cette preuve : connectez-vous depuis une extension de navigateur, créez un élément, synchronisez un second client, importez une pièce jointe et récupérez un Send après un redémarrage. Cela préserve l’intérêt de l’expérience en un clic sans gommer les détails qui rendent Vaultwarden récupérable et sécurisé.

Questions fréquentes

De quoi Vaultwarden a-t-il besoin pour un déploiement en production ?

Faites transiter le conteneur Vaultwarden sur le port 80 via une seule origine HTTPS. Le prérequis de diffusion externe est un SMTP opérationnel si les invitations et les e-mails d’accès d’urgence sont nécessaires. Ne considérez pas Vaultwarden comme prêt tant que vous ne pouvez pas vous connecter depuis une extension de navigateur, créer un élément, synchroniser un second client, importer une pièce jointe et récupérer un Send après un redémarrage.

Quelles données Vaultwarden doivent-elles être incluses dans une sauvegarde ?

Rendez /data persistant et incluez dans le même manifest de récupération la base de données, les pièces jointes, les Sends, les clés et la configuration présents dans /data. Une restauration propre de Vaultwarden n’est réussie que lorsque les éléments du coffre, les pièces jointes, les Sends et l’appartenance à l’organisation se synchronisent correctement avec un client vierge après la restauration.

Vaultwarden nécessite-t-il HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l’origine publique de Vaultwarden et conservez le port 80 sur la route interne. Appliquez correctement le paramètre Vaultwarden : définissez DOMAIN sur l’origine HTTPS externe exacte. Pour Vaultwarden, HTTPS protège les identifiants ou le contenu utilisateur pendant leur transit et garantit un comportement cohérent des clients dépendant de l’origine.

Comment tester une mise à niveau de Vaultwarden ?

Restaurez l’état actuel de Vaultwarden dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d’acceptation. Soyez particulièrement attentif, car les migrations de base de données Vaultwarden et la compatibilité des clients Bitwarden doivent être vérifiées ensemble ; la rotation de ADMIN_TOKEN est une modification de l’accès administrateur, pas une migration des données du coffre. Conservez l’ancienne image Vaultwarden jusqu’à ce que les limites de sa migration des données et de son rollback soient comprises.