Vaultwarden ou Bitwarden auto-hébergé : lequel choisir ?

Ce que sont réellement Vaultwarden et Bitwarden auto-hébergé

Vaultwarden et Bitwarden auto-hébergé correspondent à un choix entre deux serveurs qui utilisent la même API client, et non à un choix entre deux gestionnaires de mots de passe. La stack officielle de Bitwarden exécute environ une douzaine de conteneurs derrière nginx, stocke toutes les données dans Microsoft SQL Server et dépend d’un ID d’installation que vous enregistrez avec une adresse e-mail. Vaultwarden est une réimplémentation non officielle de l’API client Bitwarden, écrite en Rust. Il s’exécute dans un seul conteneur et utilise un seul fichier SQLite. Votre extension de navigateur et votre téléphone ne peuvent pas les distinguer, car les deux répondent aux mêmes endpoints.

Le chiffrement est identique dans les deux cas. Les clients Bitwarden chiffrent le coffre avant que les données ne quittent l’appareil. Le serveur stocke donc des blobs qu’il ne peut pas lire. Le format du coffre appartient à Bitwarden dans les deux cas. Ce qui change, c’est la quantité de ressources que vous devez louer, les personnes qui assurent la maintenance du code, les fonctionnalités payantes et les données que vous devez sauvegarder.

Le README de Vaultwarden indique clairement son statut : « Ce projet n’est pas associé à Bitwarden ni à Bitwarden, Inc. » Il s’agit d’un projet bénévole, sans service d’assistance ni garantie. L’un de ses mainteneurs actifs travaille chez Bitwarden et contribue sur son temps personnel. Cela relève de la courtoisie et non d’une approbation officielle.

Les trois stacks que vous pouvez installer

La plupart des comparatifs ne tiennent pas compte du fait que Bitwarden propose deux produits self-hosted différents.

Bitwarden standard. Le déploiement fourni par l’éditeur, piloté par un script shell.

curl -Lso bitwarden.sh "https://func.bitwarden.com/api/dl/?app=self-host&platform=linux" \
  && chmod 700 bitwarden.sh
./bitwarden.sh install

L’installateur vous demande votre domaine, s’il doit demander un certificat Let’s Encrypt, un nom de base de données, ainsi qu’un identifiant et une clé d’installation que vous obtenez depuis https://bitwarden.com/host en saisissant une adresse e-mail. ./bitwarden.sh start télécharge ensuite les images et démarre la stack. Bitwarden indique 2 GB de RAM et 12 GB de stockage comme minimum, et 4 GB et 25 GB comme valeurs recommandées, avec Docker Engine 26 ou une version ultérieure et le plugin Compose. La base de données utilise une image MSSQL Express. Cette édition limite la base de données relationnelle à 10 GB, sauf si vous configurez le déploiement pour utiliser une base de données externe.

Bitwarden lite. Il s’agit du déploiement auparavant appelé Bitwarden Unified. Il est sorti de la phase bêta et a été renommé en décembre 2025. Il utilise un conteneur d’application et une base de données de votre choix :

services:
  bitwarden:
    depends_on:
      - db
    env_file:
      - settings.env
    image: ghcr.io/bitwarden/lite
    restart: always
    ports:
      - "80:8080"
    volumes:
      - bitwarden:/etc/bitwarden
  db:
    environment:
      MARIADB_USER: "bitwarden"
      MARIADB_PASSWORD: "super_strong_password"
      MARIADB_DATABASE: "bitwarden_vault"
      MARIADB_RANDOM_ROOT_PASSWORD: "true"
    image: mariadb:10
    restart: always
    volumes:
      - data:/var/lib/mysql
volumes:
  bitwarden:
  data:

Il accepte MariaDB ou MySQL, PostgreSQL, SQLite et MSSQL. Il demande 200 MB de RAM et 1 GB de stockage. La documentation de Bitwarden présente toutefois deux limites. Ce déploiement est documenté pour un usage personnel et les home labs, pas pour un usage professionnel. Il n’effectue pas non plus de sauvegardes automatiques de la base de données. Cette tâche vous incombe donc entièrement.

Vaultwarden. Un seul conteneur, directement depuis le README du projet :

docker run --detach --name vaultwarden \
  --env DOMAIN="https://vw.domain.tld" \
  --volume /vw-data/:/data/ \
  --restart unless-stopped \
  --publish 127.0.0.1:8000:80 \
  vaultwarden/server:latest

La ligne de publication lie le port 8000 à loopback uniquement, et c’est volontaire. Vaultwarden fournit du HTTP non chiffré et attend qu’un reverse proxy effectue la terminaison TLS (transport layer security) devant lui. TLS est obligatoire ici : le web vault effectue son chiffrement avec l’API WebCrypto du navigateur, que les navigateurs n’exposent que dans un contexte sécurisé. En http non chiffré, la page de connexion échoue donc dans le navigateur avant même que votre serveur soit sollicité. Le guide complet d’installation de Vaultwarden couvre le proxy et le certificat.

Quelle quantité de RAM Vaultwarden utilise-t-il par rapport à Bitwarden auto-hébergé ?

Les minimums indiqués par l’éditeur précisent la configuration sous laquelle l’installateur refuse de s’exécuter, pas l’empreinte réelle du logiciel. Les valeurs ci-dessous proviennent de docker stats --no-stream sur des installations inactives, avec un utilisateur, un petit coffre et aucune pièce jointe, sur une machine Ubuntu 24.04 dotée de 4 GB de RAM. L’espace disque correspond aux images et au répertoire de données après le premier démarrage réussi.

[
  {
    "label": "Vaultwarden (SQLite)",
    "idle_ram_mb": 58,
    "containers": 1,
    "disk_gb": 0.4
  },
  {
    "label": "Bitwarden lite + MariaDB",
    "idle_ram_mb": 470,
    "containers": 2,
    "disk_gb": 1.6
  },
  {
    "label": "Bitwarden standard (MSSQL)",
    "idle_ram_mb": "2,400",
    "containers": 12,
    "disk_gb": 6.5
  }
]

Vaultwarden utilisait 58 MB au repos dans un seul conteneur. La stack Bitwarden standard utilisait près de 2,400 MB répartis entre 12 conteneurs, dont la majeure partie par le conteneur MSSQL. Bitwarden lite se situait entre les deux, à 470 MB, avec son conteneur MariaDB. Exécutez la même commande sur votre propre machine avant de vous fier à ces chiffres, car ils varient selon le nombre d’utilisateurs, les pièces jointes et le trafic de synchronisation. L’ensemble de travail de MSSQL augmente également avec la durée d’exécution.

Pour un petit VPS, retenez ceci : Vaultwarden avec SQLite fonctionne confortablement sur une offre de 1 GB, tandis que la stack Bitwarden standard ne démarre pas dans cette configuration. Sur une offre de 2 GB, la stack standard respecte le minimum documenté, mais il reste très peu de mémoire pour le système d’exploitation. Le tueur de processus déclenché par un manque de mémoire du noyau devient alors un risque réel. Lorsqu’il intervient, dmesg affiche une ligne indiquant le processus tué. Avec cette stack, il s’agit généralement de sqlservr. Prévoyez 4 GB pour le déploiement standard.

Quelles fonctionnalités payantes sont disponibles gratuitement dans Vaultwarden ?

L’exécution du serveur Bitwarden ne coûte rien, mais les fonctionnalités payantes restent verrouillées tant que vous n’avez pas importé un fichier de licence. Les comptes individuels Premium et tous les niveaux d’organisation payants (Families, Teams, Enterprise) en nécessitent une. Vous la téléchargez depuis le coffre web cloud, dans Settings puis Subscription pour un compte individuel, ou depuis l’Admin Console, dans Billing puis Subscription pour une organisation, avant de l’importer dans votre propre instance. Les licences d’organisation sont émises pour l’installation identifiée dans ./bwdata/env/global.override.env. Une organisation auto-hébergée dispose donc toujours d’un abonnement payant et contacte toujours le cloud de Bitwarden pour la facturation.

Vaultwarden active ces mêmes fonctionnalités sans licence ni abonnement. Le wiki du projet les répertorie :

• organisations, collections et groupes
• pièces jointes
• authentification en deux étapes avec e-mail, Duo, YubiKey et FIDO2
• Emergency Access
• Bitwarden Send
• clés API personnelles
• SSO via OpenID Connect

Le SSO est la plus récente de ces fonctionnalités. Il se configure avec SSO_ENABLED, SSO_AUTHORITY, SSO_CLIENT_ID et SSO_CLIENT_SECRET. Il authentifie uniquement la connexion. Le wiki précise qu’un mot de passe principal reste nécessaire et qu’il n’est pas contrôlé par votre fournisseur d’identité, car ce mot de passe dérive la clé qui déchiffre le coffre. Indiquez dans SSO_AUTHORITY l’émetteur de découverte de un fournisseur d’identité Authentik auto-hébergé. Les utilisateurs s’y connectent, puis déverrouillent leur coffre avec leur mot de passe principal. La valeur doit correspondre au champ issuer renvoyé par le endpoint de découverte, sans le suffixe /.well-known/openid-configuration final.

Ce que Vaultwarden ne vous fournit pas, c’est un éditeur. Bitwarden détient les certifications SOC 2 Type 2 et ISO 27001, publie des rapports d’audit réalisés par des tiers et gère un programme privé de bug bounty sur HackerOne. Ces éléments concernent le code et le service de Bitwarden, et non le serveur que vous avez installé. Toutefois, si un auditeur exige un fournisseur identifié derrière votre gestionnaire de mots de passe, une réimplémentation maintenue par des bénévoles constitue un sujet difficile à défendre.

Les applications officielles Bitwarden fonctionnent-elles avec Vaultwarden ?

Oui. Vaultwarden implémente l’API client. Les extensions de navigateur, les applications de bureau, les applications mobiles et le coffre web intégré fonctionnent donc avec lui. Dans chaque client, définissez l’URL du serveur auto-hébergé sur l’écran d’environnement avant de vous connecter, et non après.

Une fonctionnalité nécessite une configuration supplémentaire : les notifications push vers les applications mobiles. Sans elles, l’application se synchronise lorsque vous l’ouvrez ou selon son propre intervalle. Un mot de passe modifié sur votre ordinateur portable n’apparaît donc pas sur votre téléphone tant que vous n’avez pas ouvert l’application. Vaultwarden peut utiliser le relais push de Bitwarden. Il lui faut un ID d’installation et une clé provenant de la même page https://bitwarden.com/host que celle utilisée par l’installateur officiel.

PUSH_ENABLED=true
PUSH_INSTALLATION_ID=<your installation id>
PUSH_INSTALLATION_KEY=<your installation key>

Les serveurs de la région UE ont également besoin de PUSH_RELAY_URI=https://api.bitwarden.eu et PUSH_IDENTITY_URI=https://identity.bitwarden.eu. Le wiki documente deux pièges à connaître avant de passer une heure à diagnostiquer le problème. Une application installée depuis F-Droid ou Neo Store ne prend pas en charge Firebase et ne recevra jamais de notification push, quel que soit le comportement du serveur. Une application qui s’est connectée avant Vaultwarden 1.30.2 doit être réinitialisée en supprimant ses données afin qu’elle enregistre un token push.

Quelle est la sécurité d’une réimplémentation ?

L’historique des audits de Bitwarden est long et public. Cure53 l’a examiné en 2018, 2021, 2022 et 2023. IOActive et Mandiant ont examiné les clients en 2024, Fracture Labs a couvert les évaluations web et réseau en 2024 et 2025, Unit 42 a évalué les applications mobiles en 2025, et l’Applied Cryptography Group de l’ETH Zurich a examiné la cryptographie en 2025.

Vaultwarden a également été examiné par des organismes externes, ce qui surprend les personnes qui pensent que personne ne s’y intéresse. L’Office fédéral allemand pour la sécurité de l’information (BSI) a fait tester le projet par mgm security partners entre février et mai 2024, dans le cadre du projet d’analyse de code Caos 3.0. Cet examen a classé deux problèmes comme étant de gravité élevée. Par ailleurs, ERNW a signalé un contournement de l’authentification qui affectait les versions antérieures à 1.32.5 (CVE-2024-55225), corrigé en novembre 2024. La version 1.37.0, publiée en juillet 2026, corrigeait une SSRF (server side request forgery) via l’endpoint des icônes, un accès interorganisations aux chiffrements et un contournement de la policy d’une organisation lors des imports de répertoires.

Cet historique montre qu’il s’agit d’un projet doté d’un processus fonctionnel de signalement des vulnérabilités. Il met également en évidence la surface qui revient régulièrement dans les rapports : la page d’administration. Traitez donc cette page comme une fonctionnalité sensible. Elle reste désactivée tant que ADMIN_TOKEN n’est pas défini, et vous devez stocker un hash plutôt que le token en clair.

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

Cette commande affiche une chaîne PHC Argon2 (password hashing competition format) à copier dans ADMIN_TOKEN. Activez HTTPS avant d’activer la page d’administration, car le token est envoyé dans la requête. Un token en clair sur une connexion HTTP non chiffrée est lisible par tout équipement situé sur le chemin. Évitez autant que possible d’exposer /admin à Internet, et associez-le aux mesures classiques de durcissement de l’hôte, par exemple restreindre l’accès SSH au serveur.

Ce qui casse lorsque l’API officielle change

C’est le risque que les utilisateurs sous-estiment. Bitwarden publie les clients, et ces clients se mettent à jour automatiquement depuis les app stores pendant la nuit. Vaultwarden doit suivre. Lorsqu’une nouvelle version d’un client modifie le contrat de l’API, un Vaultwarden qui n’a pas été mis à niveau reçoit un client qui a déjà changé. Les connexions ou la synchronisation commencent alors à échouer sur des appareils auxquels vous n’avez rien modifié.

Les notes de version donnent un exemple concret. Vaultwarden 1.37.0 indique : « Cette mise à jour est requise pour assurer la compatibilité avec les clients en version 2026.7.0 et ultérieure. Veuillez effectuer la mise à jour avant de signaler un problème avec ces clients. » En août 2026, la version actuelle est 1.37.1, publiée le 29 juillet 2026.

Deux habitudes permettent d’éviter les problèmes imprévus. Épinglez un tag d’image précis au lieu de latest, afin qu’un pull automatique ne mette pas à jour votre serveur à 3 h du matin. Surveillez ensuite le flux des releases et mettez à niveau volontairement, après avoir lu les notes, car les changements incompatibles y sont signalés et nulle part ailleurs. Par exemple, la version 1.35.5 a invalidé lors de la mise à niveau tous les tokens existants de mémorisation de l’authentification à deux facteurs. Les utilisateurs ont donc été déconnectés après une étape qu’ils pensaient avoir enregistrée.

Le déploiement Bitwarden standard présente le problème inverse. Les mises à niveau passent par ./bitwarden.sh updateself et ./bitwarden.sh update, et la mise à jour applique des migrations de base de données. Une sauvegarde effectuée avant la migration ne permet pas de revenir au schéma antérieur après celle-ci. Effectuez donc la sauvegarde et notez la version au moment où vous la créez.

Sauvegardes : c’est là que les coffres sont réellement perdus

Le répertoire de données de Vaultwarden contient le serveur. Conservez les éléments suivants :

• db.sqlite3
• tous les fichiers rsa_key*, y compris rsa_key.pem et rsa_key.der
• attachments/
• config.json
• sends/

Ne copiez pas db.sqlite3 avec cp pendant que le conteneur fonctionne. SQLite peut être en train d’écrire. La copie peut donc produire une base de données corrompue, qui semble correcte jusqu’à sa restauration. Utilisez plutôt l’API de sauvegarde en ligne :

sqlite3 data/db.sqlite3 ".backup '/path/to/backups/db-$(date '+%Y%m%d-%H%M').sqlite3'"

Depuis 1.32.1, l’image contient également une commande /vaultwarden backup intégrée. Dans les deux cas, l’instantané reste sur le même disque que l’original tant que vous ne le déplacez pas. Transférez-le donc hors du serveur avec des instantanés restic vers un stockage distant selon une planification. Les fichiers rsa_key sont aussi importants que la base de données : le serveur signe ses jetons de session avec cette clé. Restaurer une base de données à côté d’une clé nouvellement générée déconnecte donc tous les utilisateurs et invalide les invitations d’organisation qui étaient en cours.

Bitwarden standard sauvegarde davantage de données. Le conteneur mssql écrit chaque nuit des sauvegardes de la base de données dans ./bwdata/mssql/backups et en conserve 30 jours, tant que le conteneur fonctionne. Vous pouvez en forcer une :

docker exec -i bitwarden-mssql /backup-db.sh

Les répertoires à conserver sont ./bwdata/env (variables d’environnement, notamment les mots de passe de la base de données et des certificats), ./bwdata/core/attachments, ./bwdata/mssql/data et ./bwdata/core/aspnet-dataprotection. Le dernier est souvent oublié. Il contient les données de protection du framework, notamment les jetons d’authentification et certaines colonnes de la base de données. Restaurer la base de données sans ce répertoire rend illisibles les colonnes qu’il protège. Bitwarden lite n’effectue aucune sauvegarde automatique. Choisir lite implique donc de gérer une planification de dumps, exactement comme avec Vaultwarden.

Migration dans un sens ou dans l’autre

La migration s’effectue avec les clients, et non avec les serveurs, car l’export et l’import sont des fonctionnalités des clients. La procédure est donc identique dans les deux sens.

Chaque utilisateur exporte son coffre depuis le coffre web ou l’application de bureau, crée un compte sur le nouveau serveur, puis importe ses données. Les formats disponibles sont le texte brut .json, le texte brut .csv, le format chiffré .json et un .zip qui contient le JSON ainsi que les pièces jointes pour les coffres individuels. Les cartes, les identités, les passkeys enregistrées et les clés SSH ne sont conservées que dans les formats JSON. Une migration au format CSV les supprime donc silencieusement. Aucun format d’export n’inclut les éléments de la corbeille ni les Sends. Les données appartenant à une organisation ne font pas partie de l’export individuel.

Considérez un export en texte brut comme un secret actif : c’est l’intégralité de votre coffre en clair sur le disque. Exportez-le, importez-le, puis supprimez-le au cours de la même session. Ne l’envoyez jamais par e-mail ou par chat.

Un piège survient souvent pendant la migration. Un export chiffré associé à votre compte ne peut pas être importé dans un autre compte. Or changer de serveur implique nécessairement de changer de compte. Choisissez plutôt l’option d’export protégée par mot de passe, car elle est portable.

Le passage de Vaultwarden à Bitwarden standard est le plus difficile, car la structure de l’organisation n’est pas incluse dans un export. Recréez l’organisation sur le nouveau serveur, invitez à nouveau les utilisateurs, puis demandez à chaque utilisateur d’importer son propre coffre. Prévoyez une fenêtre de maintenance au lieu de découvrir cette contrainte le jour de la migration.

Quelle solution devez-vous utiliser ?

Utilisez Vaultwarden si vous êtes un particulier, une famille ou si vous gérez un home lab sur un VPS de 1 GB ou 2 GB. Organizations, Emergency Access et Send sont inclus gratuitement, la consommation mémoire au repos équivaut à peu près à celle d’un onglet de navigateur, et la sauvegarde se résume à un fichier SQLite et à un petit répertoire. C’est cette combinaison qui explique sa domination dans l’auto-hébergement de gestionnaires de mots de passe.

Utilisez le serveur officiel de Bitwarden lorsque d’autres personnes en dépendent dans un cadre professionnel : une entreprise qui a besoin d’un contrat de support, une exigence de conformité qui impose cet éditeur ou des fonctionnalités d’entreprise que vous payez déjà. Prévoyez 4 GB pour le déploiement standard et considérez le fichier de licence et l’ID d’installation comme des éléments du déploiement, pas comme de simples formalités administratives.

Bitwarden lite occupe une position intermédiaire peu claire. Il s’agit du code de l’éditeur, avec une empreinte bien moindre, ce qui est réellement intéressant. Cependant, Bitwarden le destine aux usages personnels et aux home labs, et il ne propose aucune sauvegarde automatique. Vous assumez la charge opérationnelle de Vaultwarden sans bénéficier de ses fonctionnalités gratuites. Choisissez cette solution si l’utilisation du code de l’éditeur compte davantage pour vous que les fonctionnalités et si vous acceptez de gérer vous-même la base de données.

Si vous hésitez encore sur les autres services que le serveur hébergera, la sélection plus large de services d’auto-hébergement présente ce choix à côté des autres services qui se disputent la même quantité de RAM.

FAQ

Vaultwarden est-il suffisamment sûr pour servir de gestionnaire de mots de passe réel ?

Pour un usage personnel ou familial, oui, sous certaines conditions. Les clients chiffrent le coffre avant de l’envoyer au serveur. Vaultwarden ne voit donc jamais votre mot de passe maître ni aucune donnée en clair. Le logiciel a fait l’objet d’audits externes : BSI a chargé les partenaires de mgm security de le tester entre février et mai 2024, et ERNW a signalé un contournement de l’authentification, corrigé dans 1.32.5. Gardez la version à jour. Désactivez la page d’administration ou protégez-la avec un ADMIN_TOKEN haché avec Argon2. Servez l’application uniquement en HTTPS. Une entreprise qui a besoin du support de l’éditeur ou de documents d’audit doit utiliser le serveur officiel de Bitwarden.

De combien de RAM Vaultwarden a-t-il besoin par rapport à Bitwarden auto-hébergé ?

Sur des installations inactives mesurées avec docker stats --no-stream, Vaultwarden avec SQLite utilisait environ 58 Mo dans un conteneur, tandis que le déploiement standard de Bitwarden utilisait près de 2,400 Mo répartis entre 12 conteneurs. La majeure partie correspondait à la base de données MSSQL. Bitwarden indique 2 Go comme minimum et 4 Go comme valeur recommandée pour la stack standard, ainsi que 200 Mo pour Bitwarden lite. Vaultwarden fonctionne sur un VPS de 1 Go avec une marge suffisante.

Ai-je besoin d’une licence Bitwarden pour l’auto-hébergement ?

Pas pour un coffre individuel gratuit. L’exécution du serveur est gratuite. Un fichier de licence est requis pour débloquer les fonctionnalités premium individuelles et tout abonnement d’organisation payant, notamment Families, Teams et Enterprise. Vous le téléchargez depuis le coffre web cloud, puis vous l’envoyez vers votre instance. Les licences d’organisation sont attribuées à l’installation identifiée dans ./bwdata/env/global.override.env. Vaultwarden n’a besoin d’aucune licence et active lui-même les fonctionnalités d’organisation.

Puis-je passer de Vaultwarden à Bitwarden plus tard, ou revenir en arrière ?

Oui, dans les deux sens, via les clients. Chaque utilisateur exporte son coffre depuis le coffre web ou l’application de bureau, puis l’importe sur le nouveau serveur après y avoir créé un compte. L’export .zip inclut les pièces jointes des coffres individuels. Les fichiers JSON incluent les cartes, les identités, les passkeys et les clés SSH. Les éléments de la corbeille et les Sends ne sont inclus dans aucun format d’export. Les éléments appartenant à une organisation doivent être exportés séparément par un propriétaire. Prévoyez donc de recréer l’organisation et de réinviter les utilisateurs sur le nouveau serveur.