Vaultwarden est-il sécurisé ? Guide de hardening

La sécurité de Vaultwarden : réponse courte

Vaultwarden est sécurisé là où cela compte le plus : chaque élément du coffre est chiffré sur votre appareil avant d’atteindre le serveur. Le serveur stocke des blobs qu’il ne peut pas lire. Même une personne qui copie l’intégralité de la base de données a encore besoin du mot de passe principal pour en tirer quoi que ce soit d’utile.

Cette réponse repose sur plusieurs conditions, et les problèmes viennent de ce que vous configurez. Un panneau d’administration protégé par un token facile à deviner. Un port de conteneur publié sur l’ensemble d’Internet. Un config.json en clair. Une archive tar de sauvegarde stockée dans le répertoire personnel sur le même serveur. Aucun de ces problèmes ne concerne la cryptographie. Ce sont eux qui permettent de vider les coffres auto-hébergés.

Tout ce qui suit suppose que l’installation fonctionne. Si ce n’est pas encore le cas, commencez par l’installer en suivant le guide d’installation de Vaultwarden sur un VPS, puis revenez ici et suivez cette liste dans l’ordre.

Ce que le serveur stocke réellement

Vaultwarden implémente le modèle de données de Bitwarden. Le nom, le nom d’utilisateur, le mot de passe, les notes et les URI d’un élément de coffre sont chiffrés avec une clé dérivée de votre mot de passe maître, dans le client, avant l’envoi de toute requête. Le contenu des pièces jointes est chiffré de la même manière. Le serveur reçoit des données opaques associées à un UUID (identifiant universellement unique).

Certaines données ne sont pas chiffrées. Vous devez savoir précisément lesquelles :

• L’adresse e-mail de votre compte, en clair.
• Les paramètres et le sel de votre KDF (fonction de dérivation de clé), car le client en a besoin pour reconstruire la clé lors de la prochaine connexion.
• Un hash côté serveur du hash du mot de passe maître envoyé par le client, utilisé pour authentifier la connexion elle-même.
• Les métadonnées : appartenance à une organisation, noms des appareils, heures de dernière connexion.
• Le secret de la méthode d’authentification à deux facteurs qui protège la connexion à Vaultwarden. Il se trouve en clair dans la table twofactor, car le serveur doit calculer le code attendu pour le comparer au vôtre. Il ne s’agit pas du même secret TOTP (mot de passe à usage unique basé sur le temps) que celui que vous stockez dans un élément de coffre, qui est chiffré comme n’importe quel autre champ.

Le dossier de données est petit. Avec une installation Docker, il s’agit du répertoire que vous avez monté sur /data.

sudo ls -l /vw-data/

db.sqlite3 contient presque tout l’état de l’application. attachments/ contient les fichiers téléversés, un par UUID, et constitue la seule catégorie importante de données qui ne se trouve pas dans les tables de la base de données. sends/ contient les pièces jointes de Send et est destiné à un usage temporaire. icon_cache/ peut être supprimé sans conséquence. rsa_key.pem et les fichiers associés signent les JWT (JSON Web Tokens) des utilisateurs connectés. Une copie de cette clé privée peut donc servir à falsifier une session de connexion à un coffre. config.json n’existe qu’après l’activation de la page d’administration. Le projet est explicite à ce sujet : ce fichier contient le token d’administration et vos identifiants SMTP en clair.

Le modèle de menace pratique concerne donc l’accès au système de fichiers, et non la cryptographie réseau. Un accès en lecture à ce seul répertoire donne accès à l’adresse e-mail de chaque utilisateur, à leurs secrets 2FA de connexion, à une clé permettant de falsifier des sessions et à une copie hors ligne de chaque coffre, que l’attaquant peut tenter de casser à son rythme. Chaque étape ci-dessous vise à empêcher l’accès à ce répertoire.

Corrigez d’abord le token d’administration

/admin est un panneau d’administration complet : liste des utilisateurs, invitations, suppression et tous les paramètres d’exécution. Il est protégé par un seul secret partagé, sans autre protection. Il n’y a pas de nom d’utilisateur ni d’authentification à deux facteurs par utilisateur.

Les anciens guides indiquent de générer ADMIN_TOKEN avec openssl rand -base64 48. Cette méthode fonctionne, mais elle écrit le secret en clair dans config.json et dans votre fichier Compose. Vaultwarden accepte également une chaîne PHC Argon2 (Password Hashing Competition), ce qui permet de stocker un hash à la place. Générez-en une avec un conteneur en cours d’exécution :

docker exec -it vaultwarden /vaultwarden hash

Ou sans toucher au conteneur en cours d’exécution :

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

La commande demande le mot de passe deux fois, puis affiche une ligne qui commence par $argon2id$. Sur une installation bare metal, exécutez ./vaultwarden hash. Si vous préférez utiliser directement la CLI argon2, le projet documente les paramètres minimaux de l’OWASP :

echo -n 'MySecretPassword' | argon2 "$(openssl rand -base64 32)" -e -id -k 19456 -t 2 -p 1

Voici le piège qui peut vous faire perdre une heure. Une chaîne PHC contient beaucoup de caractères $, et Docker Compose interprète $ comme une interpolation de variable. Si vous la collez sans l’échapper dans un bloc environment:, la valeur transmise au conteneur est altérée. /admin rejette alors un token pourtant correct. Deux méthodes sûres existent. Dans docker-compose.yml, doublez chaque caractère $ :

environment:
  ADMIN_TOKEN: $$argon2id$$v=19$$m=19456,t=2,p=1$$UUZxK1FZMkZoRHFQRlVrTXZvS0E3bHpNQW55c2dBN2NORzdsa0Nxd1JhND0$$cUoId+JBUsJutlG4rfDZayExfjq4TCt48aBc9qsc3UI

Dans un fichier .env, aucun échappement n’est nécessaire, mais utilisez des guillemets simples :

ADMIN_TOKEN='$argon2id$v=19$m=65540,t=3,p=4$MmeKRnGK5RW5mJS7h3TOL89GrpLPXJPAtTK8FTqj9HM$DqsstvoSAETl9YhnsXbf43WeaUwJC6JhViIvuPoig78'

Limitez ensuite le débit d’accès au panneau et réduisez la durée de sa session :

ADMIN_RATELIMIT_SECONDS=300
ADMIN_RATELIMIT_MAX_BURST=3
ADMIN_SESSION_LIFETIME=20

Après trois tentatives incorrectes en cinq minutes, le panneau cesse de répondre à ce client. La session d’administration expire 20 minutes après la connexion, même si vous utilisez encore le panneau, car l’activité ne prolonge pas sa durée.

La meilleure solution reste de désactiver cette page. La plupart des installations en ont besoin une seule fois, pour configurer SMTP et inviter les premiers utilisateurs, puis plus jamais. Pour la désactiver, ne définissez ni ADMIN_TOKEN ni DISABLE_ADMIN_TOKEN, supprimez toute clé "admin_token" de config.json, puis recréez le conteneur. La suppression de la clé dans le fichier est importante, car la page d’administration y écrit les paramètres et les valeurs présentes dans config.json sont prioritaires sur celles de l’environnement. Supprimer uniquement la variable laisse la page accessible.

Fermez les inscriptions avant que quelqu’un ne trouve le domaine

SIGNUPS_ALLOWED=false
SIGNUPS_VERIFY=true
SHOW_PASSWORD_HINT=false

SIGNUPS_ALLOWED est défini sur true par défaut. Laissez cette valeur : toute personne qui accède à votre domaine peut alors créer un compte, et ses données sont stockées dans le même db.sqlite3 que les vôtres. Définissez-le sur false, puis ajoutez les utilisateurs par invitation depuis la page d’administration. Cette méthode nécessite un serveur SMTP opérationnel. INVITATIONS_ALLOWED est également défini sur true par défaut et permet aux administrateurs d’une organisation d’inviter d’autres utilisateurs. Ce réglage convient si vous faites confiance à vos utilisateurs. Sur une instance utilisée par une seule personne, il doit être défini sur false. Si seules certaines adresses doivent pouvoir s’inscrire, SIGNUPS_DOMAINS_WHITELIST=example.com est plus restrictif que l’inscription ouverte, mais bien moins sûr que les invitations.

SHOW_PASSWORD_HINT est défini sur false par défaut et doit le rester. Lorsqu’il est activé et qu’aucun serveur SMTP n’est configuré, la saisie d’une adresse e-mail valide dans le formulaire de connexion renvoie l’indice du mot de passe maître du compte. Cela divulgue l’indice et confirme que l’adresse existe.

Si votre instance a permis les inscriptions ouvertes, même pendant une courte période, ouvrez la page d’administration et consultez la liste des utilisateurs avant de supposer que vous êtes le seul compte présent.

Le port que vous ne vouliez pas publier

L’image Docker écoute sur le port 80 à l’intérieur du conteneur. Une installation bare metal utilise par défaut ROCKET_PORT=8000. La commande d’exécution documentée le publie ainsi :

--publish 127.0.0.1:8000:80

Le préfixe 127.0.0.1: est essentiel. Si vous écrivez plutôt -p 8000:80, Docker se lie à 0.0.0.0 et ajoute pour cela des règles DNAT (destination network address translation) dans la table nat. Ces règles sont évaluées avant les chaînes filter gérées par ufw. Ainsi, ufw status indique que le port est refusé alors que celui-ci répond bien aux connexions venant d’Internet. Le mécanisme complet est expliqué dans le guide sur les ports Docker qui contournent ufw.

Vérifiez ce qui écoute réellement :

sudo ss -tlnp | grep 8000

Un résultat correct contient une seule ligne liée à 127.0.0.1:8000. Une ligne liée à 0.0.0.0:8000 signifie que le coffre est exposé directement. Corrigez le mapping, puis recréez le conteneur, car une liaison de port est définie lors de la création du conteneur et docker compose restart ne la modifiera pas :

docker compose up -d --force-recreate

Un autre port figure encore dans d’anciens guides : 3012, le port WebSocket séparé. Sa prise en charge a été supprimée dans Vaultwarden 1.31.0, car le trafic de notification est passé sur le port HTTP principal. WEBSOCKET_ENABLED et WEBSOCKET_PORT sont obsolètes depuis la version 1.29.0 et sont ignorés. Le paramètre actuel est ENABLE_WEBSOCKET, dont la valeur par défaut est true. Si votre pare-feu ou votre fichier compose ouvre encore le port 3012, fermez-le.

Terminer TLS sur un reverse proxy, pas dans Rocket

Vaultwarden peut gérer lui-même TLS (transport layer security) via Rocket, son framework web, mais le projet déconseille cette configuration en production. Le support TLS intégré de Rocket ne gère pas strictement le SNI (server name indication). C’est aussi pourquoi les recommandations de durcissement préconisent d’accéder à votre instance par son nom d’hôte, jamais par une adresse IP seule. Les plages d’adresses IP publiques sont analysées en permanence. Un coffre-fort qui répond sur une adresse IP finit par être découvert.

Les éléments importants d’un bloc server nginx sont les suivants :

client_max_body_size 525M;

location / {
  proxy_pass http://127.0.0.1:8000;
  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;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection $connection_upgrade;
}

Par défaut, nginx limite client_max_body_size à 1 MB. Sans cette ligne, l’envoi d’une pièce jointe échoue avec 413 Request Entity Too Large dans le journal d’erreur nginx, tandis que Vaultwarden n’écrit absolument rien dans ses journaux. Les en-têtes Upgrade et Connection transmettent la négociation WebSocket à /notifications/hub. Si vous les supprimez, le coffre-fort continue de fonctionner, mais les modifications cessent d’apparaître sur vos autres appareils jusqu’à ce que vous rechargiez la page manuellement.

La configuration Caddy est plus courte et obtient automatiquement le certificat :

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

Indiquez ensuite cette configuration à Vaultwarden :

DOMAIN=https://vw.example.com
IP_HEADER=X-Real-IP

IP_HEADER vaut déjà X-Real-IP par défaut. Il faut donc vérifier que le proxy définit réellement cet en-tête. Vaultwarden n’accepte également cet en-tête que depuis les adresses indiquées dans IP_HEADER_TRUSTED_PROXIES, dont la valeur par défaut est local : toute adresse qui n’est pas globale, ce qui couvre un proxy présent sur le même hôte ou sur le même réseau de conteneurs. Un proxy qui se connecte depuis une adresse publique doit être ajouté à cette liste. Si l’en-tête est absent ou provient d’une adresse non approuvée, chaque ligne de journal et chaque limite de débit des connexions voient l’adresse du proxy lui-même. Les échecs d’un seul attaquant sont alors comptabilisés pour tous les utilisateurs de l’instance. Si vous utilisez IP_HEADER=X-Forwarded-For, la version 1.37.4 retient l’adresse la plus à droite qui n’est pas celle d’un proxy approuvé. Vous devez donc répertorier tous les proxies de la chaîne, y compris un CDN placé devant nginx. Définissez également DOMAIN avec la véritable URL https, car Vaultwarden construit à partir de celle-ci les liens d’invitation et de réinitialisation du mot de passe. Les clés de sécurité WebAuthn sont aussi associées à cette origine.

Un détail est souvent oublié : la connexion WebSocket transmet le jeton de session dans la chaîne de requête, sous la forme /notifications/hub?access_token=[JWT]. Ce jeton apparaît alors en clair dans le journal d’accès du proxy. Masquez le paramètre access_token dans le format des journaux, ou vérifiez que ces journaux ne sont envoyés nulle part où vous n’avez pas le contrôle.

Bloquer le brute force sur le point d’authentification

Les limites de débit sont activées par défaut (LOGIN_RATELIMIT_SECONDS=60, LOGIN_RATELIMIT_MAX_BURST=10). Elles ralentissent l’attaquant, mais ne l’arrêtent pas. fail2ban le fait, mais il doit pouvoir lire les échecs d’authentification de Vaultwarden. Avec Docker, la méthode la plus simple consiste à utiliser un fichier journal, car Vaultwarden n’en écrit pas par défaut :

LOG_FILE=/data/vaultwarden.log
LOG_LEVEL=info
EXTENDED_LOGGING=true

Un échec d’authentification produit alors exactement une ligne. C’est cette chaîne que votre filtre doit rechercher :

[2026-08-07 09:14:22][vaultwarden::api::identity][ERROR] Username or password is incorrect. Try again. IP: 203.0.113.10. Username: user@example.com.

Écrivez le filtre dans /etc/fail2ban/filter.d/vaultwarden.local :

[INCLUDES]
before = common.conf

[Definition]
failregex = ^.*?Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$
ignoreregex =

Puis le jail dans /etc/fail2ban/jail.d/vaultwarden.local :

[vaultwarden]
enabled = true
port = 80,443
filter = vaultwarden
banaction = %(banaction_allports)s
logpath = /vw-data/vaultwarden.log
maxretry = 3
bantime = 14400
findtime = 14400

Si Vaultwarden fonctionne comme un service systemd plutôt que dans un conteneur, vous pouvez ignorer LOG_FILE : le wiki fail2ban du projet lit le journal avec backend = systemd et utilise un journalmatch sur l’unité Vaultwarden à la place de logpath.

Si vous avez conservé la page d’administration, ajoutez un deuxième jail dont le failregex est ^.*Invalid admin token\. IP: <ADDR>.*$, car les échecs d’authentification de l’administration sont journalisés avec un message différent et le filtre de connexion ne les détectera jamais. Vérifiez ensuite votre configuration :

sudo systemctl restart fail2ban
sudo fail2ban-client status vaultwarden

Un jail opérationnel affiche votre fichier journal sous File list et indique Currently failed: 0. Saisissez trois fois un mot de passe incorrect depuis un autre réseau. Le compteur augmente, puis l’adresse apparaît sous Banned IP list. Si le compteur ne bouge jamais, la cause habituelle est logpath : il doit s’agir du chemin du fichier sur l’hôte, et non du chemin /data/... à l’intérieur du conteneur. L’autre cause fréquente est l’absence d’un X-Real-IP ou l’absence de confiance envers celui-ci, ce qui fait que chaque bannissement cible votre propre proxy. Le reste de la configuration, notamment le jail SSH que vous devriez déjà utiliser, se trouve dans le guide fail2ban pour Ubuntu 24.04.

Le mot de passe maître reste l’ensemble du système

Le chiffrement côté client signifie que le mot de passe maître est la clé. Un mot de passe maître court sur une instance dont la base de données a été copiée par un attaquant n’est protégé par aucun élément décrit dans cet article, car l’attaquant peut attaquer cette copie hors ligne à la vitesse permise par son matériel. Aucun paramètre du serveur ne peut agir sur la machine de l’attaquant.

PASSWORD_ITERATIONS=600000 est facile à mal interpréter. Ce paramètre définit le nombre d’itérations du hash côté serveur appliqué au hash de connexion envoyé par le client. Le modèle de configuration du projet indique qu’une valeur modifiée est appliquée aux utilisateurs existants lors de leur prochaine connexion. Il ne concerne pas le KDF côté client, qui détermine le coût d’une attaque hors ligne contre le coffre. Ce paramètre appartient à chaque compte. Il se modifie dans Settings, Security, Keys, dans le coffre web, ce qui rechiffre la clé. La documentation de Bitwarden indique que ses clients, depuis 2026.2.1, augmentent automatiquement un paramètre PBKDF2 inférieur à 600,000 itérations lorsque l’utilisateur se connecte ou déverrouille le coffre avec le mot de passe maître. Au 10 octobre 2026, ce comportement n’est pas confirmé avec un serveur Vaultwarden et il ne modifie jamais les paramètres Argon2id. Une personne inscrite il y a plusieurs années peut donc toujours utiliser un paramètre KDF plus ancien et moins élevé. Vérifiez ce paramètre et informez-la, car le serveur ne peut pas le faire à sa place.

Activez ensuite l’authentification à deux facteurs pour chaque compte. Elle ne protège pas le texte chiffré, car la clé du coffre provient uniquement du mot de passe maître. Elle empêche toutefois qu’un mot de passe volé suffise à se connecter et à synchroniser une copie. REQUIRE_DEVICE_EMAIL=true rend obligatoire l’e-mail de connexion depuis un nouvel appareil : si Vaultwarden ne peut pas l’envoyer, la connexion échoue. Une connexion depuis un appareil non reconnu ne passe donc jamais inaperçue. Un serveur SMTP fonctionnel est nécessaire, sinon toutes les connexions depuis un nouvel appareil seront refusées.

Les sauvegardes sont le point faible des coffres auto-hébergés

Une tar czf du dossier de données, laissée dans un répertoire personnel sur le même VPS, annule toutes les mesures précédentes. Cette archive contient db.sqlite3 avec le texte chiffré de chaque utilisateur, rsa_key.pem qui permet de falsifier les sessions de connexion, et config.json avec le token d’administration et le mot de passe SMTP en clair. L’accès en lecture à ce seul fichier donne accès au coffre.

Deux règles suffisent. Sortez l’archive du serveur. Chiffrez-la avant son transfert.

Il y a aussi un problème d’intégrité. Copier db.sqlite3 avec cp pendant que le service fonctionne peut produire un fichier en cours d’écriture qui ne pourra pas être ouvert. Vous ne le découvrirez qu’au moment de la restauration. Utilisez plutôt le snapshot natif de SQLite :

sqlite3 /vw-data/db.sqlite3 ".backup '/tmp/vw-db-backup.sqlite3'"

La restauration, que personne ne teste souvent, est couverte dans le guide de sauvegarde et de restauration de Vaultwarden.

Ce que vous abandonnez par rapport à Bitwarden hébergé

Un bilan honnête. Le service hébergé de Bitwarden est exploité par des personnes dont le métier à temps plein consiste à l’administrer, avec des audits tiers publiés et une personne d’astreinte à 3 h du matin. L’auto-hébergement remplace cela par votre propre rythme d’application des correctifs.

Vaultwarden publie les correctifs de sécurité sous la forme de releases ordinaires, et ces releases sont fréquentes. Vérifiée le 10 octobre 2026 dans le flux des releases du projet, la release actuelle est toujours la 1.37.4, publiée le 5 octobre 2026. Ses notes couvrent sept avis de sécurité, dont le plus grave est classé High, et recommandent fortement d’effectuer la mise à jour dès que possible. Il s’agit de la quatrième release depuis la 1.37.0 du 24 juillet 2026 : la 1.37.1 a suivi le 29 juillet, la 1.37.2 le 22 août (requise pour les clients en version 2026.8.0 et ultérieure), puis la 1.37.3 le 13 septembre, qui révoque les remember tokens de 2FA lorsque les identifiants ou la 2FA changent et applique une limitation de débit aux endpoints de requêtes prelogin et auth. Si vous utilisez des organisations dont vous ne faites pas entièrement confiance aux administrateurs, les notes de la 1.37.4 recommandent également de faire tourner la clé API de chaque organisation après la mise à jour. La 1.37.4 modifie aussi l’adresse lue depuis X-Forwarded-For, comme indiqué dans la section consacrée au reverse proxy ci-dessus. Une instance que vous avez configurée il y a un an puis oubliée exécute du code vieux d’un an. Le tag latest ne suffit pas : un conteneur en fonctionnement conserve l’image avec laquelle il a démarré jusqu’à ce que vous exécutiez docker compose pull et le recréiez. Mettez en place des mises à niveau automatiques sur Ubuntu pour les paquets de l’hôte, et inscrivez la mise à jour du conteneur dans un rappel de calendrier que vous consulterez réellement.

La conclusion qu’un lecteur honnête devrait tirer est la suivante : la cryptographie repose ici sur la conception de Bitwarden et elle tient la route, tandis que le risque opérationnel vous revient entièrement. Si vous appliquez les correctifs et effectuez vos sauvegardes ailleurs, une instance Vaultwarden sur un VPS que vous contrôlez constitue un emplacement raisonnable pour conserver vos mots de passe. Si ces deux habitudes ne seront pas adoptées, payez le service hébergé et consacrez votre attention à autre chose. La comparaison fonctionnalité par fonctionnalité se trouve dans Vaultwarden comparé à Bitwarden auto-hébergé.

Renforcez l’hôte sous-jacent au conteneur

Vaultwarden est un processus sur une machine Linux. Le compte root de cette machine peut lire /vw-data, quelle que soit la configuration de l’application. Exécutez le conteneur avec un utilisateur non privilégié en utilisant user: "1000:1000" dans votre fichier compose, et attribuez les bons propriétaires au dossier de données. Montez ensuite en lecture seule tout ce que le conteneur ne doit pas modifier avec :ro. Fermez enfin la porte d’entrée : Renforcer SSH sur un VPS explique comment autoriser uniquement l’authentification par clé et désactiver l’authentification par mot de passe. C’est ce qui bloque l’attaque classique qui contourne toutes les mesures précédentes.

FAQ

Quelqu’un peut-il lire mes mots de passe s’il vole la base de données Vaultwarden ?

Pas directement. Chaque élément du coffre est chiffré côté client avec une clé dérivée du mot de passe maître. db.sqlite3 contient donc du texte chiffré. La personne obtient immédiatement l’adresse e-mail de chaque compte, les paramètres du KDF, les métadonnées de connexion et d’appareil, ainsi que les secrets à deux facteurs de la table twofactor. Ces derniers sont stockés sans chiffrement, car le serveur doit calculer le code attendu. Elle peut également attaquer hors ligne le texte chiffré du coffre aussi longtemps qu’elle le souhaite. C’est pourquoi la longueur du mot de passe maître est le facteur déterminant.

Dois-je utiliser ADMIN_TOKEN ou désactiver complètement la page d’administration ?

Désactivez-la si possible. La plupart des instances en ont besoin une seule fois pour configurer SMTP et inviter les utilisateurs, puis plus jamais. Pour la désactiver, ne définissez ni ADMIN_TOKEN ni DISABLE_ADMIN_TOKEN, supprimez toute clé "admin_token" de config.json, puis recréez le conteneur. Supprimer uniquement la variable d’environnement ne suffit pas, car les paramètres enregistrés par la page d’administration se trouvent dans config.json et sont prioritaires. Si vous conservez la page, stockez le token sous forme de hash Argon2 produit par vaultwarden hash, plutôt qu’en tant que chaîne aléatoire en clair, et définissez ADMIN_RATELIMIT_MAX_BURST=3.

Mon ADMIN_TOKEN est correct, mais /admin le refuse. Quel est le problème ?

Il s’agit presque toujours d’une interpolation de $. Une chaîne PHC Argon2 contient plusieurs caractères $. Docker Compose les interprète comme des variables à l’intérieur d’un bloc docker-compose.yml environment:. Le conteneur reçoit donc une valeur modifiée, même si votre fichier semble correct. Doublez chaque $ en $$ dans le fichier Compose, ou placez la valeur dans un fichier .env entouré d’apostrophes simples. Aucun échappement n’est alors nécessaire. Recréez ensuite le conteneur, car un redémarrage ne recharge pas les modifications de l’environnement.

Dois-je encore ouvrir le port 3012 pour les notifications ?

Non. La prise en charge du trafic WebSocket sur le port 3012 a été supprimée dans Vaultwarden 1.31.0, car les notifications utilisent désormais le port HTTP principal. WEBSOCKET_ENABLED et WEBSOCKET_PORT sont obsolètes depuis la version 1.29.0 et sont ignorés. Le paramètre actuel est ENABLE_WEBSOCKET, qui vaut true par défaut. Fermez le port 3012 dans le firewall et supprimez-le de votre fichier Compose. Vérifiez ensuite que votre reverse proxy transmet les en-têtes Upgrade et Connection, car la synchronisation en temps réel en dépend désormais.