Héberger Vaultwarden sur un VPS infogéré : vos mots de passe sur votre serveur

Ce que fait Vaultwarden

Vaultwarden est un serveur de gestion de mots de passe écrit en Rust, conçu pour l'auto-hébergement. Son wiki le destine aux particuliers, aux familles et aux organisations à taille humaine. Le coffre web est livré dans ses images Docker.

Il met en œuvre une API compatible avec les clients officiels Bitwarden, sur le navigateur, l'ordinateur et le téléphone. Le README précise que le projet n'est pas associé à Bitwarden ni à Bitwarden, Inc., et il demande de lui signaler directement tout problème, quel que soit le client utilisé, plutôt qu'aux canaux d'assistance officiels.

• Le coffre : coffre personnel, pièces jointes, icônes des sites, clé d’API personnelle, et Send pour transmettre un texte ou un fichier.
• Les organisations : collections, partage de mots de passe, rôles, groupes, journaux d’événements et politiques.
• La double authentification : application d’authentification, e-mail, FIDO2 WebAuthn, YubiKey et Duo.
• Les recours : accès d’urgence et récupération de compte, cette dernière demandant que l’e-mail soit configuré.
• L’administration : une page /admin pour les réglages, les comptes et le diagnostic.

Le wiki liste aussi ce qui manque par rapport au serveur officiel, comme la connexion par clé d'accès, les rôles personnalisés et certaines politiques d'entreprise. Il précise que les fonctions surtout utiles aux grandes organisations ne sont pas une priorité du projet : lisez cette liste si vous en avez besoin.

Ce que permet la licence AGPL-3.0

Vaultwarden est publié sous GNU Affero General Public License, version 3. Le texte affirme une permission illimitée de faire tourner le programme non modifié. Vous pouvez donc utiliser l'image publiée par le projet pour votre entreprise et votre équipe, sans licence à acheter.

L'article 13 ajoute une condition propre à l'AGPL : si vous modifiez le programme, votre version doit offrir à tous ceux qui l'utilisent à distance, par le réseau, le moyen d'obtenir gratuitement son code source.

L'installation avec Docker Compose

Le README recommande les images de conteneur. Sur un serveur où Docker est installé, créez un dossier et placez-y ce compose.yaml, tiré du README et du wiki :

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "true"
    volumes:
      - ./vw-data/:/data/
    ports:
      - 127.0.0.1:8000:80

docker compose up -d

• Un port publié sur 127.0.0.1 : comme dans le README, Vaultwarden s'atteint par le seul proxy inverse, posé sur le même serveur.
• DOMAIN : l'adresse de base de votre instance, en https. Le wiki prévient que des fonctions cassent sans cela, dont les pièces jointes et les liens d'invitation.
• Un dossier vw-data sur un disque local : il garde toutes les données. Le wiki signale les ennuis de SQLite sur un volume CIFS ou Samba, qui ne gère pas le verrouillage.
• L'étiquette latest suit la dernière version publiée, et le wiki la recommande à la plupart des usages. Une étiquette comme 1.37.5 fixe une version, et latest-alpine donne la même chose sur une base Alpine.

Votre nom de domaine pointe vers le serveur avec des enregistrements A et AAAA, et les visiteurs arrivent sur les ports 80 et 443. Tant que le proxy inverse n'est pas en place, le coffre web reste inutilisable : passez directement à la section suivante.

Le projet ne chiffre ni la mémoire ni le processeur ; il se présente seulement comme une solution pour les cas où le service officiel, gourmand en ressources, ne convient pas. La taille dépend du nombre de comptes et du volume des pièces jointes. Sur un VPS infogéré, décrivez-nous votre usage et nous vous recommandons la taille qui convient.

HTTPS et WebSocket : le proxy inverse

Le coffre web s'appuie sur l'API Web Crypto, que les navigateurs réservent aux contextes sécurisés : le README indique qu'il ne fonctionne qu'une fois HTTPS activé, et le wiki juge HTTPS « pretty much required », à peu près obligatoire. Le projet recommande un proxy inverse devant Vaultwarden, et déconseille le TLS intégré à son framework Rocket.

Prenez un certificat reconnu, comme ceux de Let's Encrypt, que le wiki recommande : avec un certificat auto-signé, certaines plateformes refusent la connexion. Le certificat doit porter sa chaîne complète, sans quoi les appareils Android ne se connectent pas.

Les notifications WebSocket, actives par défaut, préviennent le navigateur, l'application de bureau et l'extension qu'une entrée a changé. Elles passent par le port HTTP principal, et le proxy doit transmettre les en-têtes Upgrade et Connection. Les applications mobiles utilisent les notifications natives de leur système, qui se configurent à part.

Avec Caddy

Le wiki conseille de regarder Caddy en premier si vous n'avez pas de préférence : il active HTTPS de lui-même, obtient le certificat Let's Encrypt et prend en charge WebSocket. Le réglage du wiki transmet aussi l'adresse réelle du visiteur à Vaultwarden, pour ses journaux :

vault.example.com {
  reverse_proxy 127.0.0.1:8000 {
    header_up X-Real-IP {remote_host}
  }
}

Avec Nginx et Certbot

Ce bloc reprend l'exemple Nginx du wiki, réduit au port 80 pour laisser Certbot poser HTTPS :

upstream vaultwarden-default {
  zone vaultwarden-default 64k;
  server 127.0.0.1:8000;
  keepalive 2;
}

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      "";
}

server {
    listen 80;
    listen [::]:80;
    server_name vault.example.com;

    client_max_body_size 525M;

    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    location / {
      proxy_pass http://vaultwarden-default;
    }
}

Certbot pose ensuite le certificat et se charge de le renouveler :

sudo certbot --nginx

Vérifier WebSocket

Ouvrez les outils de développement du navigateur, onglet réseau, filtre WS, puis reconnectez-vous au coffre : une réponse 101 sur /notifications/hub confirme la connexion. Autre test du wiki : ouvrez le coffre dans deux navigateurs, renommez une entrée dans l'un, et le changement paraît aussitôt dans l'autre.

Fermer les inscriptions

Par défaut, toute personne qui atteint votre instance peut y créer un compte. C'est utile pour votre premier compte, et le wiki recommande de fermer ensuite, pour empêcher un attaquant d'en créer un.

1. Ouvrez votre adresse HTTPS et créez votre compte, puis reliez vos applications à cette adresse.
2. Passez SIGNUPS_ALLOWED à "false" dans compose.yaml.
3. Relancez avec docker compose up -d : une variable d’environnement est liée au conteneur, qui doit être recréé pour la prendre en compte.

SIGNUPS_ALLOWED: "false"

• Les invitations restent ouvertes après la fermeture : les propriétaires et les administrateurs d'une organisation peuvent inviter de nouvelles personnes. INVITATIONS_ALLOWED à "false" retire cette possibilité, et le wiki laisse ce choix selon la confiance que vous accordez à vos utilisateurs.
• Une liste de domaines : SIGNUPS_DOMAINS_WHITELIST limite l'inscription à certains domaines d'e-mail, et SIGNUPS_VERIFY à true impose alors de vérifier l'adresse. Quand cette liste est posée, SIGNUPS_ALLOWED est ignorée.
• La page d'administration permet d'inviter n'importe qui, quelles que soient ces restrictions.

Dès que vous enregistrez la configuration depuis la page d'administration, un fichier config.json naît dans le dossier de données et l'emporte sur les variables d'environnement. Les réglages concernés se changent alors depuis cette page : modifier compose.yaml ne suffit plus.

La page d'administration et son jeton

La page /admin sert à configurer Vaultwarden, à voir et supprimer les comptes et les organisations, à retirer la double authentification d'un utilisateur, à inviter et à lire le diagnostic. Sans ADMIN_TOKEN, elle reste désactivée : si vous n'en avez pas l'usage, laissez-la ainsi.

Le wiki recommande vivement d'activer HTTPS avant cette page. Le jeton sert de mot de passe, et il peut être gardé sous forme hachée, en argon2id, plutôt qu'en clair dans la configuration. Vaultwarden fournit la commande : elle demande le mot de passe deux fois, puis rend une chaîne PHC.

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

Placez cette chaîne dans un fichier .env, à côté de compose.yaml, entre apostrophes, puis appelez-la depuis le service :

VAULTWARDEN_ADMIN_TOKEN='$argon2id$...'

ADMIN_TOKEN: ${VAULTWARDEN_ADMIN_TOKEN}

Vérifiez le résultat, relancez, puis connectez-vous sur /admin avec votre mot de passe, et non avec la chaîne PHC :

docker compose config
docker compose up -d

• La session dure 20 minutes par défaut, réglables par ADMIN_SESSION_LIFETIME. Une session ouverte reste valide après un changement de jeton. Pour toutes les couper, supprimez rsa_key.pem du dossier de données et redémarrez, ce qui déconnecte aussi les utilisateurs et annule les invitations en cours.
• Un accès réduit : les exemples de proxy du wiki montrent comment n'ouvrir /admin qu'à certaines adresses, ou y ajouter une authentification HTTP.
• DISABLE_ADMIN_TOKEN retire tout contrôle : il est prévu pour une couche d'authentification séparée placée devant, et le wiki le réserve à ceux qui savent ce qu'ils font.

Ce qui protège le coffre

La première protection est le mot de passe maître. Les données du coffre sont chiffrées avec des clés personnelles ou d'organisation : qui obtient une copie de la base ou force une session doit encore casser ce mot de passe pour les lire. Sa solidité compte donc avant tout. Une session d'administration elle-même permet de supprimer un compte ou de retirer une double authentification, sans donner accès aux données du coffre.

Préparez l'oubli du mot de passe maître avant qu'il n'arrive : activez l'accès d'urgence de votre compte et, dans une organisation, la récupération de compte, qui demande l'e-mail configuré.

Trois réglages de plus, tirés du guide de durcissement

• Un compte non root : l'image tourne en root par défaut, et le wiki juge préférable de lui donner le minimum de droits. Ajoutez user: 1000:1000 au service, avec un dossier vw-data qui appartient à cet utilisateur.
• Les journaux du proxy : la connexion WebSocket passe un jeton dans l'adresse, en access_token. Si votre proxy garde ses journaux ou les envoie à un service extérieur, le wiki recommande d'y masquer cette valeur.
• Le minimum de montages : montez le dossier de données et rien d'autre, ni votre dossier personnel, ni /var/run/docker.sock.

SQLite, MariaDB ou PostgreSQL

La même image prend en charge les trois bases. Le wiki décrit SQLite comme la plus utilisée et la plus testée, et la recommande à la plupart des usages, sauf besoin précis d'une autre.

DATABASE_URL: "postgresql://user_name:user_password@db_host:5432/vaultwarden"

Créez une base vide et son utilisateur : au démarrage, Vaultwarden y pose lui-même son schéma. Un mot de passe qui porte des caractères spéciaux s'écrit en encodage pourcent dans cette adresse.

Faites ce choix avant de remplir le coffre. Le wiki décrit un passage de SQLite à PostgreSQL avec pgloader, en précisant que cette voie n'est pas prise en charge par le projet, qu'elle se fait à vos risques et qu'elle commence par une sauvegarde.

Les e-mails : la configuration SMTP

Vaultwarden démarre sans e-mail, mais plusieurs fonctions en dépendent : les invitations, la vérification des adresses, l'envoi des indices de mot de passe, la double authentification par e-mail et la récupération de compte.

Sur un VPS Simafri, l'envoi passe par un relais SMTP authentifié, sur le port 587 : l'adresse d'un compte de messagerie que vous avez déjà, ou Simafri Suite. Le mot de passe se place dans le fichier .env, comme le jeton d'administration :

SMTP_HOST: "smtp.example.com"
SMTP_FROM: "vault@example.com"
SMTP_PORT: "587"
SMTP_SECURITY: "starttls"
SMTP_USERNAME: "vault@example.com"
SMTP_PASSWORD: ${VAULTWARDEN_SMTP_PASSWORD}

• Les liens d'invitation se construisent à partir de DOMAIN, et restent valides 5 jours.
• Microsoft : le wiki indique que Hotmail, Outlook et Office 365 demandent désormais OAuth2, que Vaultwarden ne prend pas encore en charge. L'erreur à reconnaître est No compatible authentication mechanism was found.
• Gmail : prévoyez un mot de passe d'application, selon le wiki.
• L'essai : la page d'administration envoie un e-mail de test. Si vous y changez un réglage SMTP, enregistrez d'abord, car le test utilise les réglages enregistrés, et cet enregistrement crée config.json.

Si rien ne part, le wiki propose de tester la connexion au relais depuis le serveur. La commande rend 0 quand le relais répond :

timeout 5 bash -c 'cat < /dev/null > /dev/tcp/smtp.example.com/587'; echo $?

Les sauvegardes

Le README rappelle que le projet ne peut être tenu responsable d'une perte de données et recommande vivement des sauvegardes régulières. Le wiki les conseille automatiques, avec au moins une copie ailleurs. Voici ce que contient le dossier de données avec SQLite :

La base, service en marche

Depuis la version 1.32.1, Vaultwarden sait sauvegarder sa base SQLite lui-même, sans arrêt du service :

docker exec -it vaultwarden /vaultwarden backup

La commande écrit un fichier db_AAAAMMJJ_HHMMSS.sqlite3 à côté de la base, dans vw-data. L'image ne contient ni sqlite3 ni cron : le wiki conseille de planifier la tâche sur le serveur, au moins une fois par jour. Retirez alors -it, car une tâche planifiée n'a pas de terminal, et faites le tri parmi ces fichiers, qui s'accumulent.

Tout le dossier, service arrêté

Quand la base n'est pas utilisée, une simple copie de tous ses fichiers suffit. C'est la méthode à service arrêté que le wiki donne en exemple pour Docker, et elle emporte aussi les pièces jointes :

docker compose down
tar -czf vaultwarden-$(date +%F).tar.gz vw-data
docker compose up -d

Le wiki juge une couche de chiffrement utile, surtout quand la sauvegarde porte le jeton d'administration et les accès SMTP, et il cite rclone, restic et rustic pour envoyer les copies au loin. Avec MariaDB ou PostgreSQL, ajoutez un export de la base au dossier vw-data.

Le wiki demande de ne pas s'en remettre aux seuls instantanés de disque, plus délicats à restaurer. Gardez donc ces copies propres à l'application : posées sur le disque du serveur, elles entrent aussi dans ses sauvegardes de nuit.

Restaurer

1. Arrêtez Vaultwarden.
2. Remplacez chaque fichier ou dossier de vw-data par sa version sauvegardée.
3. Si la base vient de /vaultwarden backup, nommez-la db.sqlite3 et supprimez d’abord tout fichier db.sqlite3-wal existant : un journal qui ne correspond pas peut corrompre la base. Si elle vient d’une copie directe, restaurez ensemble db.sqlite3 et son db.sqlite3-wal.
4. Relancez, puis vérifiez que vous pouvez ouvrir le coffre.

Le wiki conseille de répéter cet exercice de temps en temps, en gardant une copie des données en place : c'est ainsi que vous vérifiez qu'une sauvegarde fonctionne.

Les mises à jour

Le wiki donne deux commandes, depuis le dossier du compose.yaml. Le dossier de données reste en place :

docker compose pull
docker compose up -d

Ces mises à jour comptent plus qu'ailleurs. Les applications mobiles et les extensions de navigateur se mettent à jour d'elles-mêmes, et le wiki prévient qu'un écart de version avec le serveur peut provoquer des pannes soudaines. Le coffre web, livré dans l'image, reste toujours accordé à son serveur.

Le projet n'a pas de calendrier de versions : suivez ses notes de version, et lancez une sauvegarde juste avant chaque mise à jour. Certaines portent des correctifs de sécurité, comme la 1.37.5 du 1er novembre 2026, dont les notes recommandent de mettre à jour au plus vite. Ces notes préviennent aussi que, depuis la 1.37.5, une valeur de configuration invalide empêche Vaultwarden de démarrer : relisez votre fichier d'environnement avant de mettre à jour. La page de diagnostic de /admin indique si une version plus récente existe.

Qui fait quoi sur un VPS infogéré

L'auto-hébergement demande de tenir le serveur en plus de l'application. Sur un VPS infogéré, nos équipes prennent le serveur en main et suivent votre instance de manière proactive ; Vaultwarden reste votre logiciel, avec ses réglages et ses données.

Si vous préférez que nos équipes interviennent dans l'application elle-même, cette prestation se facture à l'heure ou au forfait, avec un chiffrage communiqué avant l'intervention.