Installation de Vaultwarden sur Linux avec Docker Compose sur un mini-serveur synchronisé avec un ordinateur et un smartphone

Vaultwarden sur Linux : installer, sécuriser et synchroniser son gestionnaire de mots de passe

Écrit par Vincent

Mis à jour le 7 septembre 2026

Vaultwarden est un serveur open source écrit en Rust, compatible avec les applications officielles Bitwarden, qui permet d’héberger ses mots de passe sur sa propre machine. Il s’installe avec Docker Compose en une quinzaine de minutes, mais deux étapes décident de la réussite : le HTTPS, sans lequel les pièces jointes échouent, et la configuration des notifications, qui n’utilise pas le même mécanisme sur navigateur et sur mobile.

L’essentiel

Commande clé : docker compose up -d

Prérequis : Docker et Docker Compose, un nom de domaine, un reverse proxy pour le HTTPS

Distributions : toutes celles qui exécutent Docker (image officielle vaultwarden/server, multi-architecture)

Base de données par défaut : SQLite, recommandée pour la majorité des installations

Temps estimé : 15 minutes pour l’installation, 30 avec le durcissement

Vérifié le 04/09/2026 sur Vaultwarden 1.37.2 et Docker Compose v5.5.1

Vaultwarden ou Bitwarden : ce que vous gagnez, ce que vous perdez

Vaultwarden réimplémente l’API du serveur Bitwarden en Rust. Les applications officielles (mobile, bureau, extension de navigateur, ligne de commande) s’y connectent sans modification, et le chiffrement est identique : vos données sont chiffrées sur votre appareil avant d’atteindre le serveur, qui ne voit jamais un mot de passe en clair.

Le gain porte sur les ressources. Le serveur officiel repose sur une architecture .NET faite pour le déploiement à grande échelle ; Vaultwarden tient dans un seul conteneur léger, exécutable sur un VPS d’entrée de gamme, un NAS ou un Raspberry Pi.

Le projet vise explicitement les particuliers, les familles et les petites structures, et n’a jamais prétendu couvrir tout le périmètre du serveur officiel. Plusieurs fonctions y manquent, dont la première est régulièrement présentée à tort comme disponible :

Fonction du serveur officiel	État dans Vaultwarden 1.37.2
Connexion par clé d’accès (passkey)	Absente, listée dans les fonctionnalités manquantes du projet
Protection de connexion depuis un nouvel appareil	Absente
Rôles personnalisés dans une organisation	Absente, ne sera ajoutée que par contribution externe
API publique Bitwarden	Partielle, uniquement pour le Directory Connector
Authentification unique (SSO) via OpenID Connect	Disponible
TOTP, FIDO2 WebAuthn, YubiKey, Duo, Send, Emergency Access	Disponibles

Retenez ce point si vous vous connectez aujourd’hui à Bitwarden avec une clé d’accès : cette méthode de connexion n’existe pas côté Vaultwarden, le mot de passe maître reste obligatoire.

Comparatif Vaultwarden et Bitwarden officiel : les cas où l'auto-hébergement convient et ceux où il faut rester sur le serveur officiel

Prérequis

Un serveur Linux, VPS ou machine locale, avec Docker et Docker Compose. La procédure d’installation de Docker sur Linux couvre les quatre grandes familles de distributions.
Un nom de domaine ou un sous-domaine pointé vers ce serveur.
Un reverse proxy pour le certificat HTTPS. La mise en place d’un reverse proxy avec Nginx Proxy Manager décrit la procédure complète ; ce guide se limite à ce que Vaultwarden exige de son côté.

Les cinq étapes pour installer Vaultwarden sur Linux avec Docker Compose, du fichier de configuration à la fermeture des inscriptions

Étape 1 : créer le fichier compose.yml

Créez un dossier dédié et le fichier de configuration. Le nom compose.yml est celui qu’emploie la documentation actuelle ; docker-compose.yml reste accepté et fonctionne à l’identique.

mkdir -p ~/vaultwarden && cd ~/vaultwarden
nano compose.yml

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: always
    environment:
      DOMAIN: "https://vault.exemple.fr"
      SIGNUPS_ALLOWED: "true"
      LOG_FILE: "/data/vaultwarden.log"
    volumes:
      - ./vw-data:/data
    ports:
      - 127.0.0.1:8000:80

Remplacez vault.exemple.fr par votre domaine. Trois choix méritent une explication :

DOMAIN doit contenir l’adresse HTTPS complète. Sans elle, l’envoi de pièces jointes échoue.
LOG_FILE écrit les journaux dans le volume de données. Ils sont indispensables à Fail2Ban plus loin, et cette ligne évite d’avoir à recréer le conteneur pour l’ajouter après coup.
Le port n’est publié que sur 127.0.0.1. Le conteneur n’est donc pas joignable depuis Internet : seul le reverse proxy l’atteint.

L’image vaultwarden/server:latest convient à la majorité des installations. Une variante latest-alpine existe, plus légère, fonctionnellement identique.

Étape 2 : démarrer et vérifier

docker compose up -d

[+] Running 2/2
 ✔ Network vaultwarden_default  Created
 ✔ Container vaultwarden        Started

Contrôlez l’état du conteneur et ses journaux :

docker compose ps
docker compose logs -f

docker compose ps doit afficher vaultwarden avec le statut running. Quittez l’affichage des journaux avec Ctrl+C : le conteneur continue de tourner.

Étape 3 : activer le HTTPS

Le chiffrement TLS n’est pas assuré par Vaultwarden. Le projet déconseille formellement son serveur TLS interne, dont l’auteur amont indique lui-même qu’il n’est pas destiné à la production. Le certificat se gère donc sur le reverse proxy placé devant.

Côté nginx, la configuration se fait en deux endroits. D’abord un bloc map placé au niveau http, en dehors de tout bloc server :

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

Ce bloc n’est pas décoratif : $connection_upgrade n’existe pas nativement dans nginx, c’est cette directive qui la crée. Si vous copiez seulement les en-têtes ci-dessous en l’oubliant, nginx refuse de démarrer avec unknown "connection_upgrade" variable.

Ensuite, dans le bloc server de votre hôte :

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;

Les deux premières lignes activent la bascule WebSocket. X-Real-IP paraît accessoire ; elle conditionne en réalité le bon fonctionnement de Fail2Ban décrit plus bas, faute de quoi Vaultwarden journalisera toutes les tentatives de connexion comme venant de 127.0.0.1. Si vous utilisez Nginx Proxy Manager, déjà évoqué plus haut, ces en-têtes se saisissent dans les paramètres avancés de l’hôte proxy.

Étape 4 : sécuriser la page d’administration

Connectez-vous à https://vault.exemple.fr et créez votre compte. La page /admin sert ensuite à gérer les utilisateurs et les réglages du serveur ; elle est protégée par un jeton distinct de votre mot de passe.

Générez ce jeton :

openssl rand -base64 32

Ne le stockez pas en clair. Vaultwarden sait le vérifier sous forme de condensat Argon2id, ce qui évite qu’un accès en lecture au fichier de configuration livre l’accès administrateur :

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

La commande demande la saisie du mot de passe deux fois, puis affiche une chaîne au format PHC :

$argon2id$v=19$m=19456,t=2,p=1$c0FsdEV4ZW1wbGU$Q29uZGVuc2F0RXhlbXBsZQ

Avant de la coller dans compose.yml, doublez chacun des cinq caractères $. Docker Compose traite un $ isolé comme le début d’une variable à substituer : sans cet échappement, le jeton enregistré ne sera pas celui que vous avez généré.

    environment:
      DOMAIN: "https://vault.exemple.fr"
      SIGNUPS_ALLOWED: "false"
      LOG_FILE: "/data/vaultwarden.log"
      ADMIN_TOKEN: '$$argon2id$$v=19$$m=19456,t=2,p=1$$c0FsdEV4ZW1wbGU$$Q29uZGVuc2F0RXhlbXBsZQ'

Cet échappement n’est pas une précaution théorique. Sans lui, Docker Compose consomme chaque $ comme une variable inexistante et enregistre un jeton tronqué, ce que docker compose config montre immédiatement :

level=warning msg="The "argon2id" variable is not set. Defaulting to a blank string."
level=warning msg="The "v" variable is not set. Defaulting to a blank string."
level=warning msg="The "m" variable is not set. Defaulting to a blank string."
...
      ADMIN_TOKEN: =19=19456,t=2,p=1

Vérifiez donc votre fichier avant de relancer :

docker compose config

Une configuration correcte n’affiche aucun avertissement de ce type, et réaffiche le jeton avec ses doubles $ : c’est le comportement attendu, pas une erreur. Des avertissements nommant argon2id, v ou m signalent au contraire un échappement manquant.

docker compose up -d

Connectez-vous ensuite sur https://vault.exemple.fr/admin avec le mot de passe en clair, celui saisi lors de la génération, jamais la chaîne $argon2id$.... La session administrateur dure 20 minutes par défaut, réglable via ADMIN_SESSION_LIFETIME.

Le piège qui fait échouer la moitié des configurations

Si Vaultwarden continue d’afficher l’avertissement You are using a plain text ADMIN_TOKEN which is insecure, la cause la plus fréquente n’est pas une erreur de syntaxe.

Dès que vous enregistrez une configuration depuis la page /admin, Vaultwarden crée un fichier config.json dans le volume de données. Les valeurs de ce fichier priment sur les variables d’environnement. Votre compose.yml peut donc être parfaitement correct et rester sans effet.

Pour savoir laquelle des deux sources s’applique :

docker exec vaultwarden printenv ADMIN_TOKEN
grep admin_token vw-data/config.json

Si la seconde commande renvoie une valeur, c’est elle qui fait foi : corrigez le jeton depuis la page /admin plutôt que dans compose.yml.

Étape 5 : fermer les inscriptions

Passer SIGNUPS_ALLOWED à "false" ne suffit pas. Un propriétaire ou administrateur d’organisation conserve le droit d’inviter de nouveaux comptes, et une adresse invitée peut s’enregistrer malgré le réglage. Pour fermer réellement l’instance :

      SIGNUPS_ALLOWED: "false"
      INVITATIONS_ALLOWED: "false"
      SHOW_PASSWORD_HINT: "false"

SHOW_PASSWORD_HINT mérite un mot. Vaultwarden affiche par défaut les indices de mot de passe directement sur la page de connexion, pour rester utilisable sans serveur de messagerie configuré. Un attaquant peut s’en servir pour préparer une attaque par devinette : désactivez-le si votre instance est publique.

Attention enfin à SIGNUPS_DOMAINS_WHITELIST : dès que cette variable est renseignée, la valeur de SIGNUPS_ALLOWED est ignorée. Une instance que vous croyez fermée reste ouverte à tous les comptes du domaine listé.

Synchronisation : deux mécanismes différents, et c’est là que ça coince

La confusion la plus répandue autour de Vaultwarden vient de là. La synchronisation instantanée ne repose pas sur la même technologie selon le client, et configurer la première ne configure pas la seconde.

Schéma des deux mécanismes de synchronisation de Vaultwarden : WebSocket direct pour le navigateur et notifications push pour les clients mobiles

Sur navigateur, bureau et extension, le client ouvre une connexion WebSocket permanente vers votre serveur. Ce mécanisme est actif par défaut depuis la version 1.29. Les tutoriels qui demandent d’ouvrir un port 3012 dédié sont périmés : ce port séparé a été supprimé en version 1.31, le trafic WebSocket passant désormais par le port HTTP principal. Rien à publier de plus dans compose.yml, seuls les en-têtes Upgrade et Connection de l’étape 3 sont nécessaires.

Sur mobile Android et iOS, les WebSocket ne sont pas utilisés du tout. Les applications s’appuient sur les services de notification natifs, FCM chez Google et APNs chez Apple, qui transitent par l’infrastructure de Bitwarden. Sans configuration supplémentaire, votre téléphone ne se synchronisera qu’à l’ouverture de l’application ou sur demande manuelle.

Activer les notifications push mobiles

Cette étape est facultative, mais c’est elle qui manque quand un lecteur constate que son téléphone ne se met pas à jour tout seul.

Rendez-vous sur https://bitwarden.com/host/, saisissez votre adresse e-mail et récupérez l’identifiant et la clé d’installation. Le principe reste celui du chiffrement de bout en bout décrit plus haut : le déchiffrement a lieu sur vos appareils, pas sur le relais. Si acheminer les notifications par une infrastructure tierce vous dérange malgré tout, laissez PUSH_ENABLED désactivé et vos clients mobiles se synchroniseront manuellement, à l’ouverture.

      PUSH_ENABLED: "true"
      PUSH_INSTALLATION_ID: "votre-identifiant"
      PUSH_INSTALLATION_KEY: "votre-cle"

Si vous avez demandé vos identifiants sur la région Union européenne, ce que beaucoup préféreront pour garder le relais sur le territoire européen, deux variables supplémentaires sont obligatoires :

      PUSH_RELAY_URI: "https://api.bitwarden.eu"
      PUSH_IDENTITY_URI: "https://identity.bitwarden.eu"

Recréez le conteneur, puis déconnectez-vous et reconnectez-vous sur chaque client mobile : c’est à la connexion que l’application récupère la configuration push du serveur.

docker compose up -d vaultwarden

Trois limites à connaître avant de conclure à une panne :

Les applications installées depuis F-Droid ou Neo Store sont compilées sans Firebase Messaging. Les notifications push n’y fonctionneront jamais. Seules les versions issues de l’App Store, du Play Store ou d’un client compatible comme Aurora Store en bénéficient.
Un appareil connecté à votre instance avant la version 1.30.2 n’a jamais enregistré son jeton. Il faut effacer les données de l’application ou la réinstaller.
Le domaine firebaseinstallations.googleapis.com doit être joignable depuis le téléphone. Un bloqueur DNS trop agressif suffit à casser la fonction.

Vérifier que tout fonctionne

Testez les deux mécanismes séparément, sinon un diagnostic en cache l’autre.

WebSocket, côté navigateur. Ouvrez les outils de développement, onglet Réseau, filtre WS. Déconnectez-vous puis reconnectez-vous : une réponse de code 101 doit apparaître sur /notifications/hub. Tout autre code signale un reverse proxy mal configuré, et vous ramène aux en-têtes de l’étape 3.

Synchronisation réelle. Ouvrez votre coffre dans deux navigateurs différents, ou une fenêtre de navigation privée. Renommez une entrée dans l’un : elle doit changer immédiatement dans l’autre.

Push mobile. Renommez un dossier depuis le coffre web et observez l’application mobile : le changement doit y apparaître en quelques secondes, sans rafraîchissement manuel.

Durcir l’instance

Trois réglages simples réduisent nettement la surface d’attaque d’une instance exposée.

Exécuter le conteneur sans les droits root. Par défaut, le processus tourne en root à l’intérieur du conteneur. Le confinement Docker limite déjà la portée, mais rien n’oblige à conserver ce privilège :

    user: "1000:1000"

L’identifiant 1000 correspond au premier compte utilisateur sur la plupart des distributions ; vérifiez le vôtre avec id. Le dossier vw-data doit appartenir à cet utilisateur, sans quoi le conteneur ne pourra pas écrire.

Ne monter que le nécessaire. Le conteneur n’a besoin que de son dossier de données. Ne lui exposez ni votre répertoire personnel ni /var/run/docker.sock. Un volume que Vaultwarden n’a pas à modifier se monte en lecture seule avec le suffixe :ro.

Servir l’instance uniquement par son nom de domaine. Une instance qui répond aussi sur son adresse IP est repérable par les robots qui balaient Internet en continu : une simple recherche sur Shodan suffit à lister des serveurs Bitwarden joignables de cette façon. Configurez le reverse proxy pour ne répondre qu’au nom de domaine attendu.

Bloquer les attaques par force brute avec Fail2Ban

Tant que l’authentification à deux facteurs n’est pas active sur tous les comptes, un mot de passe maître reste exposé aux tentatives répétées. Fail2Ban lit les journaux de Vaultwarden et bannit les adresses fautives.

Installez-le, puis créez le filtre :

sudo apt install fail2ban
sudo nano /etc/fail2ban/filter.d/vaultwarden.local

[INCLUDES]
before = common.conf

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

Puis la prison :

sudo nano /etc/fail2ban/jail.d/vaultwarden.local

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

Adaptez logpath au chemin réel du fichier défini par LOG_FILE à l’étape 1, vu depuis l’hôte.

sudo systemctl restart fail2ban

Trois raisons pour lesquelles une prison Fail2Ban ne bannit rien

Ces trois défaillances ont un point commun : Fail2Ban semble fonctionner, aucun message d’erreur n’apparaît, et pourtant aucune adresse n’est bloquée.

Toutes les tentatives sont journalisées comme 127.0.0.1. C’est l’adresse du reverse proxy, pas celle de l’attaquant. Fail2Ban bannit alors votre propre proxy, ou rien du tout. La correction est l’en-tête X-Real-IP de l’étape 3.

Docker contourne la chaîne iptables surveillée. Docker traite le trafic dans la chaîne FORWARD, alors que Fail2Ban agit par défaut sur INPUT. Ajoutez la ligne suivante dans la prison :

chain = FORWARD

Fail2Ban bannit avec nftables, Docker filtre avec iptables. Depuis la version 1.1.1.dev1, le paquet Debian bascule par défaut sur nftables, que les règles Docker ignorent. Dans ce cas seulement, forcez :

banaction = iptables

Vérifiez que la prison mord réellement, en tentant trois connexions avec une adresse e-mail quelconque, puis :

sudo fail2ban-client status vaultwarden

Pour lever un bannissement :

sudo fail2ban-client set vaultwarden unbanip 203.0.113.10

Sauvegarder son coffre

Un gestionnaire de mots de passe auto-hébergé sans sauvegarde testée est un risque, pas une solution. Depuis la version 1.32.1, Vaultwarden intègre sa propre commande de sauvegarde SQLite :

docker exec -it vaultwarden /vaultwarden backup

Utilisez-la plutôt qu’une copie directe du fichier : cp sur une base SQLite en cours d’écriture produit une sauvegarde éventuellement corrompue, sans le moindre avertissement. Sur les versions antérieures, la commande équivalente s’appuie sur le client SQLite installé sur l’hôte, l’image Docker ne l’embarquant pas :

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

Au-delà de la base, le dossier de données contient des fichiers dont la perte a des conséquences distinctes :

Élément	Sauvegarde	Conséquence de la perte
`db.sqlite3`	Indispensable	Perte de tous les identifiants
`attachments/`	Indispensable	Perte des pièces jointes, absentes de la base
`config.json`	Recommandée	Reconfiguration manuelle ; contient le jeton admin et les identifiants SMTP en clair
`rsa_key*`	Recommandée	Déconnexion de tous les utilisateurs, invitations en cours invalidées
`sends/`, `icon_cache/`	Facultative	Pièces jointes Send éphémères, icônes reconstruites automatiquement

Chiffrez la sauvegarde si elle quitte le serveur : config.json et la clé privée rsa_key.pem sont sensibles.

À la restauration, arrêtez Vaultwarden, remplacez les fichiers, et supprimez tout fichier db.sqlite3-wal existant avant de remettre en place une base issue de .backup. Un journal d’écriture désynchronisé avec la base restaurée peut la corrompre. Testez la restauration au moins une fois : une sauvegarde jamais restaurée n’est pas une sauvegarde vérifiée.

Mettre à jour, et pourquoi ce n’est pas optionnel

docker compose pull && docker compose up -d && docker compose logs -f

Les applications et extensions Bitwarden se mettent à jour automatiquement, et Bitwarden modifie parfois ses clients d’une façon qui exige une évolution correspondante côté serveur. Un Vaultwarden laissé trop longtemps sans mise à jour finit par refuser des clients qui fonctionnaient la veille. La version 1.37.2 est précisément une mise à jour de compatibilité, requise pour les clients à partir de la version 2026.8.0.

Le coffre web fait exception : il est livré avec l’image, sa version correspond donc toujours à celle du serveur.

Installer Vaultwarden sur un NAS Synology

Le fonctionnement est identique, Vaultwarden restant un conteneur Docker : sur DSM, il se lance depuis Container Manager, avec les mêmes variables d’environnement et le même volume de données. Les différences portent sur l’interface de saisie, pas sur la configuration. Deux points d’attention propres au NAS : le système de bannissement d’adresses intégré à DSM ne s’applique pas aux conteneurs Docker, et Fail2Ban y demande une installation en conteneur, avec la chaîne DOCKER-USER. Ce guide restant centré sur un serveur Linux en ligne de commande, reportez-vous à la documentation Container Manager et au wiki officiel de Vaultwarden pour la procédure DSM détaillée.

Désinstaller ou revenir en arrière

docker compose down

Le dossier vw-data reste intact : un docker compose up -d ultérieur repart de l’existant. Pour tout supprimer :

docker compose down
rm -rf vw-data

Cette commande efface définitivement l’intégralité de vos mots de passe. Avant de l’exécuter, exportez votre coffre depuis l’interface web, menu Outils puis Exporter le coffre, ou lancez la sauvegarde décrite plus haut pendant que le conteneur tourne encore.

Erreurs courantes

Les pièces jointes ne s’envoient pas. DOMAIN est absente ou ne commence pas par https://. Corrigez la valeur, puis docker compose up -d.

La page /admin refuse le jeton. Trois causes, dans cet ordre de fréquence : un config.json existant qui prime sur la variable d’environnement ; un $ non doublé dans compose.yml, que docker compose config révèle ; ou la saisie de la chaîne $argon2id$... au lieu du mot de passe en clair.

Le navigateur ne se synchronise pas en direct. Le reverse proxy ne transmet pas les en-têtes Upgrade et Connection. Le test du code 101 sur /notifications/hub tranche en quelques secondes.

Le téléphone ne se synchronise pas alors que le navigateur fonctionne. Comportement normal sans PUSH_ENABLED : les WebSocket ne concernent pas les clients mobiles.

Fail2Ban ne bannit personne. Voir les trois causes détaillées plus haut : adresse 127.0.0.1, chaîne FORWARD, bascule nftables.

Les icônes des sites n’apparaissent pas. Vaultwarden récupère les favicons depuis Internet ; un service interne ou une instance sans accès sortant nécessite une configuration spécifique documentée dans le wiki.

FAQ

Vaultwarden fonctionne-t-il avec l’application officielle Bitwarden ? Oui, sans modification. Il suffit de remplacer l’URL du serveur par la vôtre dans les paramètres de l’application ou de l’extension, avant la connexion.

Peut-on se connecter à Vaultwarden avec une clé d’accès (passkey) ? Non. La connexion par passkey figure dans les fonctionnalités manquantes du projet, une proposition de code étant ouverte mais non intégrée à ce jour. Le mot de passe maître reste nécessaire, éventuellement complété par une authentification à deux facteurs.

Vaultwarden prend-il en charge l’authentification unique (SSO) ? Oui, via OpenID Connect, avec les variables SSO_ENABLED, SSO_AUTHORITY, SSO_CLIENT_ID et SSO_CLIENT_SECRET. Un mot de passe maître reste demandé en plus de l’authentification par le fournisseur d’identité.

Faut-il ouvrir le port 3012 pour les notifications ? Non, plus depuis la version 1.31 : le trafic WebSocket est passé sur le port HTTP principal. Les variables WEBSOCKET_ENABLED et WEBSOCKET_PORT sont ignorées depuis la 1.29.

Vaultwarden est-il aussi sûr que le serveur officiel ? Le chiffrement des données est identique, puisque Vaultwarden réutilise le protocole Bitwarden et que le déchiffrement a lieu sur vos appareils. Le projet a fait l’objet de plusieurs audits, dont certains publics. La différence tient à l’exploitation : mises à jour, HTTPS, jeton d’administration et sauvegardes relèvent désormais de vous.

Combien de ressources faut-il prévoir ? Le conteneur est conçu pour de petites machines : un VPS d’entrée de gamme, un NAS ou un Raspberry Pi suffisent pour un usage personnel ou familial. L’image est multi-architecture et fonctionne sur ARM comme sur x86.

Conclusion

Vaultwarden rend le contrôle du coffre à son propriétaire sans sacrifier l’écosystème Bitwarden : mêmes applications, même chiffrement, hébergement sur votre matériel. L’installation elle-même est courte ; ce qui distingue une instance fiable d’une instance fragile tient à quatre décisions prises au moment de la configuration, et non après un incident.

Renseignez DOMAIN avec l’adresse HTTPS complète. Hachez le jeton d’administration en Argon2 et vérifiez qu’aucun config.json ne prime silencieusement sur votre compose.yml. Configurez les notifications push si vous utilisez un téléphone, faute de quoi la synchronisation mobile restera manuelle. Mettez en place une sauvegarde et restaurez-la au moins une fois pour la valider.

Pour prolonger sur le même serveur, le guide Nginx Proxy Manager cité plus haut traite le reverse proxy et le certificat automatique, et configurer un pare-feu avec UFW complète le durcissement décrit ici en fermant les ports que rien ne doit atteindre.

Sources officielles

Vincent est le créateur de MémoLinux. Venu de Windows par curiosité, il est resté sur Linux pour sa logique et le plaisir de comprendre ce qui se passe sous le capot. Il documente ici les commandes et les procédures qu’il utilise lui-même, avec leurs sources officielles et leur date de vérification.