Installer Vaultwarden sur un VPS européen : le guide complet (Hetzner, Docker, Caddy)

Vos mots de passe, vos clés SSH, vos codes de récupération : tout cela dort probablement chez un grand éditeur américain. Ce guide vous montre comment les rapatrier sur votre propre serveur, en Europe, avec Vaultwarden, un gestionnaire de mots de passe open source compatible avec toutes les applications Bitwarden.

On ne se contente pas de « faire marcher » Vaultwarden. On l'installe comme en production : serveur verrouillé, pare-feu en amont, HTTPS automatique, inscriptions fermées. Et surtout, sans jamais se retrouver enfermé dehors.

Ce guide accompagne la vidéo ci-dessous. Toutes les commandes montrées à l'écran sont ici, avec des explications en plus.

La vidéo est hébergée par YouTube : cliquer charge le lecteur YouTube. Voir la vidéo sur YouTube

Sommaire

1. Avant de commencer : ce qu'il vous faut
2. Vaultwarden, c'est quoi exactement ?
3. Pourquoi Hetzner ?
4. Étape 1 — Créer une clé SSH
5. Étape 2 — Le pare-feu Hetzner et la création du serveur
6. Étape 3 — Première connexion et tmux
7. Étape 4 — Mises à jour automatiques
8. Étape 5 — Un utilisateur dédié
9. Étape 6 — Verrouiller SSH sans s'enfermer dehors
10. Étape 7 — Docker, et le piège ufw
11. Étape 8 — Vaultwarden derrière Caddy
12. Étape 9 — Fermer la porte derrière soi
13. Étape 10 — Connecter vos applications Bitwarden
14. Bonus — Votre coffre dans le terminal
15. Dépannage
16. Et après ? Les sauvegardes

Avant de commencer : ce qu'il vous faut

• Un compte Hetzner Cloud (une carte bancaire suffit).
• Un nom de domaine dont vous gérez la zone DNS (chez OVH, Gandi, etc.). Dans ce guide, on utilise coffre.lecoqnumerique.fr : remplacez-le partout par le vôtre.
• Un terminal sur votre ordinateur : Terminal sous macOS ou Linux, PowerShell ou Windows Terminal sous Windows (SSH y est intégré).
• Environ une heure, si c'est votre première fois.

Vous n'avez pas besoin d'être administrateur système. Si un terme vous est inconnu, chaque notion importante renvoie vers une page dédiée qui l'explique simplement.

Ce que vous aurez à la fin :

Vaultwarden, c'est quoi exactement ?

Un gestionnaire de mots de passe est un coffre-fort chiffré : vous retenez un seul mot de passe, le mot de passe maître, et le coffre retient tous les autres. Il les remplit pour vous dans le navigateur et sur votre téléphone, et il en génère des nouveaux, longs et uniques.

Bitwarden est un gestionnaire de mots de passe open source très répandu. Il se compose de deux parties :

• les clients : l'application mobile, l'extension de navigateur, l'application de bureau, la ligne de commande ;
• le serveur, qui stocke votre coffre chiffré et le synchronise entre vos appareils.

Vaultwarden est une réécriture communautaire de ce serveur, en langage Rust. Elle est compatible avec les clients officiels Bitwarden, mais beaucoup plus légère : elle tourne confortablement sur le plus petit serveur du marché.

En clair : vous gardez les applications Bitwarden que vous connaissez, mais le serveur, c'est vous.

Est-ce sûr de l'héberger soi-même ? Le coffre est chiffré sur votre appareil, avant d'être envoyé au serveur. Même quelqu'un qui volerait le disque du serveur ne verrait que des données chiffrées. Votre vraie responsabilité, c'est de garder le serveur à jour, bien protégé, et sauvegardé. C'est tout l'objet de ce guide.

Pourquoi Hetzner ?

Hetzner est un hébergeur allemand, avec des centres de données en Allemagne et en Finlande. Vos données restent sous droit européen, hors de portée du Cloud Act américain.

Le plus petit serveur, le CX23, offre 2 processeurs virtuels, 4 Go de mémoire et 40 Go de disque. Il coûte environ 5,49 € HT par mois, plus 0,50 € pour l'adresse IPv4 (tarif d'octobre 2026, après la hausse de juin ; vérifiez le prix du jour sur la page tarifs de Hetzner). C'est largement assez : Vaultwarden consomme presque rien.

Un VPS (Virtual Private Server) est un serveur virtuel : une part d'une grosse machine physique, mais qui se comporte pour vous comme un ordinateur entier, allumé en permanence et joignable depuis Internet.

Étape 1 — Créer une clé SSH

SSH est le moyen de piloter votre serveur à distance, en ligne de commande. Pour vous connecter, on n'utilise pas de mot de passe mais une clé : un fichier secret qui reste sur votre ordinateur, et sa moitié publique qu'on dépose sur le serveur.

👉 Nouveau sur le sujet ? Lisez d'abord Clé SSH ED25519 : comprendre et créer la vôtre.

Sur votre ordinateur (pas sur le serveur) :

ssh-keygen -t ed25519 -a 100 -C "vous@votredomaine"

• -t ed25519 : le type de clé moderne, court et robuste.
• -a 100 : renforce la protection de la phrase de passe contre les attaques par force brute.
• -C : un simple commentaire pour reconnaître la clé.

Appuyez sur Entrée pour garder l'emplacement par défaut, puis choisissez une phrase de passe. Elle protège votre clé si quelqu'un met la main sur votre ordinateur.

Affichez ensuite la partie publique, celle qu'on peut partager :

cat ~/.ssh/id_ed25519.pub

Copiez la ligne entière (elle commence par ssh-ed25519), puis dans la console Hetzner : Security > SSH keys > Add SSH key, et collez-la.

Pourquoi faire ça avant de créer le serveur ? Parce que Hetzner va injecter cette clé au démarrage. Résultat : pas de mot de passe root envoyé par mail, et aucune connexion par mot de passe possible dès la première seconde.

Étape 2 — Le pare-feu Hetzner et la création du serveur

Le pare-feu cloud : votre premier rempart

Un pare-feu filtre le trafic réseau : il laisse passer ce que vous autorisez et rejette le reste. Il en existe deux sortes, et on va utiliser les deux :

• le pare-feu sur le serveur (ufw, qu'on verra plus loin) ;
• le pare-feu de Hetzner, placé devant le serveur, dans l'infrastructure de l'hébergeur.

Le second est le plus important. Il filtre le trafic avant qu'il n'atteigne votre machine. Même si vous vous trompez dans la configuration du serveur, ou si Docker ouvre un port dans votre dos (on y reviendra, c'est le piège n° 1), rien ne passe.

Dans la console Hetzner : Firewalls > Create Firewall, nommez-le fw-coffre et ajoutez ces règles entrantes :

N'ajoutez aucune règle sortante. Chez Hetzner, sans règle sortante, tout peut sortir : c'est ce qu'on veut, sinon les mises à jour et Let's Encrypt cesseraient de fonctionner.

📚 Documentation Hetzner : créer un pare-feu

Créer le serveur

Servers > Add Server, puis :

• Emplacement : Falkenstein, Nuremberg (Allemagne) ou Helsinki (Finlande) ;
• Image : Debian 13 ;
• Type : CX23 ;
• SSH key : la clé ajoutée à l'étape 1 ;
• Firewall : fw-coffre ;
• Nom : coffre.

Créez le serveur et notez son adresse IPv4. Dans la suite, IP_DU_SERVEUR désigne cette adresse.

Étape 3 — Première connexion et tmux

Connectez-vous en root, pour la première et la dernière fois :

ssh root@IP_DU_SERVEUR

À la première connexion, SSH vous demande de confirmer l'empreinte du serveur : tapez yes.

Pourquoi tmux avant tout le reste

Si votre connexion coupe en plein milieu d'une mise à jour (Wi-Fi capricieux, ordinateur en veille), votre session SSH meurt, et la commande en cours avec elle. Ça peut laisser le serveur dans un état bancal.

tmux garde vos sessions vivantes sur le serveur. Si la connexion coupe, vous vous reconnectez et vous retrouvez tout exactement où vous l'aviez laissé.

👉 Découvrez tmux en 10 minutes : tmux pour les débutants.

apt update && apt install -y tmux
tmux new -s chantier

Une organisation simple et efficace : trois fenêtres.

Dans la fenêtre « logs », lancez le suivi des journaux système en direct :

journalctl -f

Étape 4 — Mises à jour automatiques

Un serveur exposé sur Internet qu'on oublie de mettre à jour, c'est la première porte d'entrée des attaquants. On met donc tout à jour, puis on automatise les correctifs de sécurité.

apt update && apt full-upgrade -y
apt install -y sudo unattended-upgrades apt-listchanges needrestart
dpkg-reconfigure -plow unattended-upgrades

• unattended-upgrades installe tout seul les mises à jour de sécurité. À la question posée par dpkg-reconfigure, répondez Oui.
• apt-listchanges vous montre ce qui change lors des mises à jour.
• needrestart vous signale les services à redémarrer après une mise à jour.

On règle ensuite le fuseau horaire et le nom de la machine. Le nom apparaîtra dans votre invite de commande : ça vous évitera de vous tromper de serveur un soir de fatigue.

timedatectl set-timezone Europe/Paris
hostnamectl set-hostname coffre

Et on redémarre. Après la première mise à jour complète d'un serveur neuf, c'est systématique (un nouveau noyau a souvent été installé) :

reboot

Attendez une trentaine de secondes, reconnectez-vous en root et relancez tmux new -s chantier.

📚 Wiki Debian : UnattendedUpgrades

Étape 5 — Un utilisateur dédié

On ne travaille jamais en root : c'est le super-administrateur, qui a tous les droits. La moindre erreur de frappe peut tout casser, et c'est le compte que les robots attaquent en premier.

On crée un utilisateur normal, ici lecoqnumerique (choisissez votre propre nom), on lui donne le droit d'utiliser sudo (« exécuter cette commande en tant qu'administrateur »), et on lui copie la clé SSH de root :

adduser lecoqnumerique
usermod -aG sudo lecoqnumerique
rsync --archive --chown=lecoqnumerique:lecoqnumerique ~/.ssh /home/lecoqnumerique

adduser vous demande un mot de passe : il ne servira pas à vous connecter (la clé s'en charge), mais à confirmer vos commandes sudo. Choisissez-le solide et rangez-le… dans votre futur coffre.

rsync --chown copie le dossier .ssh en donnant les bons propriétaires. C'est important : SSH refuse une clé dont les droits sont incorrects.

Étape 6 — Verrouiller SSH sans s'enfermer dehors

C'est le moment où tout le monde s'enferme dehors au moins une fois dans sa vie. Règle d'or : ne fermez jamais la session qui fonctionne. On modifie, on teste depuis un deuxième terminal, et on ne ferme la première session qu'une fois sûr de soi.

Le fichier de durcissement

On ne modifie pas le fichier principal /etc/ssh/sshd_config. On dépose un fichier séparé dans le dossier prévu, et on le préfixe par 00- :

cat > /etc/ssh/sshd_config.d/00-durcissement.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowUsers lecoqnumerique
EOF

Pourquoi 00- ? Pour SSH, c'est la première valeur lue qui gagne, et les fichiers de ce dossier sont lus par ordre alphabétique. Si l'image de l'hébergeur (ou cloud-init) a déposé son propre fichier qui réactive les mots de passe, le vôtre passe avant et l'emporte.

Ce que fait chaque ligne :

• PermitRootLogin no : root ne peut plus se connecter.
• PasswordAuthentication no et KbdInteractiveAuthentication no : connexion par clé uniquement.
• AllowUsers lecoqnumerique : seul votre utilisateur est autorisé.

On vérifie la syntaxe, on affiche la configuration réellement appliquée, et seulement ensuite on recharge :

sshd -t && sshd -T | grep -Ei 'permitrootlogin|passwordauthentication|allowusers'
systemctl try-reload-or-restart ssh

Vous devez lire permitrootlogin no, passwordauthentication no et allowusers lecoqnumerique.

Le test dans un deuxième terminal

Sans fermer la session root, ouvrez un nouveau terminal sur votre ordinateur :

ssh lecoqnumerique@IP_DU_SERVEUR   # doit passer
sudo -v                            # doit accepter votre mot de passe

Puis, depuis un troisième onglet :

ssh root@IP_DU_SERVEUR             # doit répondre : Permission denied (publickey)

Les trois tests sont bons ? Alors, et seulement alors, fermez la session root. Dans votre session lecoqnumerique, relancez tmux sous ce nouvel utilisateur (sinon toute la suite tournerait encore en root) :

tmux new -s chantier

Faut-il changer le port 22 ?

Changer de port réduit le bruit dans les journaux, pas le risque. La vraie protection, c'est la clé et le pare-feu Hetzner.

Sur Debian 13, soyez prudent : le port peut être tenu par systemd (ssh.socket) plutôt que par SSH lui-même. Modifier la configuration de SSH ne suffit alors plus, et c'est exactement comme ça qu'on se coupe l'accès. Vérifiez qui tient le port avant toute chose :

systemctl is-active ssh.socket ssh.service

fail2ban contre les robots insistants

fail2ban lit les journaux et bannit temporairement les adresses IP qui échouent trop souvent à se connecter.

sudo apt install -y fail2ban
sudo fail2ban-client status sshd

Si la « prison » sshd ne démarre pas, c'est que Debian n'écrit plus le fichier /var/log/auth.log (les journaux sont dans systemd). Créez /etc/fail2ban/jail.local :

[sshd]
backend = systemd

puis sudo systemctl restart fail2ban.

📚 Pour aller plus loin : les recommandations de l'ANSSI pour un usage sécurisé d'OpenSSH.

Étape 7 — Docker, et le piège ufw

Docker fait tourner des applications dans des conteneurs : des boîtes isolées qui contiennent l'application et tout ce dont elle a besoin. Avantage : l'installation est identique partout, et une mise à jour se résume à télécharger une nouvelle image.

Installer Docker depuis le dépôt officiel

On n'utilise pas le paquet Docker de Debian, souvent en retard. On suit la procédure officielle de Docker pour Debian :

sudo apt install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/debian
Suites: $(. /etc/os-release && echo "$VERSION_CODENAME")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Le piège n° 1 : Docker passe par-dessus ufw

C'est le point le plus important du guide.

Quand Docker publie un port (la ligne ports: d'un fichier Compose), il écrit ses propres règles réseau, directement dans le noyau, et passe par-dessus ufw. Vous croyez avoir fermé un port avec ufw : il est en réalité ouvert au monde entier. La documentation de Docker le dit noir sur blanc.

C'est exactement pour ça qu'on a mis le pare-feu chez Hetzner, en dehors de la machine : Docker ne peut pas le contourner. Et dans notre installation, Vaultwarden ne publiera aucun port. Seul Caddy, le proxy, sera exposé sur 80 et 443.

👉 Le détail du mécanisme et les solutions : Docker contourne ufw : comprendre et se protéger.

Si vous voulez quand même ufw comme seconde ceinture (pour SSH notamment), activez-le avec une deuxième session SSH ouverte :

sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw allow 22/tcp && sudo ufw allow 80/tcp && sudo ufw allow 443
sudo ufw enable

Le groupe docker

Pour lancer Docker sans taper sudo à chaque fois, on ajoute votre utilisateur au groupe docker. À savoir : être dans ce groupe revient à avoir les droits root. Sur un serveur personnel, on l'assume, mais en connaissance de cause.

sudo usermod -aG docker lecoqnumerique
newgrp docker
docker run --rm hello-world

newgrp docker recharge vos groupes dans le terminal en cours, sans vous déconnecter. Pourquoi pas une simple déconnexion ? Parce que le serveur tmux garde les groupes qu'il avait au démarrage : se détacher puis revenir ne suffit pas.

Si hello-world affiche « Hello from Docker! », c'est gagné.

Étape 8 — Vaultwarden derrière Caddy

Le DNS d'abord

Chez votre registrar, créez un enregistrement A : coffre → IP_DU_SERVEUR. Le DNS, c'est l'annuaire d'Internet : il traduit un nom (coffre.lecoqnumerique.fr) en adresse IP.

Vérifiez depuis le serveur que le nom pointe bien au bon endroit (la propagation peut prendre quelques minutes) :

getent hosts coffre.lecoqnumerique.fr   # doit renvoyer l'IP du serveur

N'allez pas plus loin tant que ce n'est pas le cas. Sans DNS correct, Caddy ne pourra pas obtenir son certificat.

Caddy, le portier HTTPS

Caddy est un serveur web qui se place devant Vaultwarden. On appelle ça un reverse proxy (« proxy inverse ») : il reçoit les visites depuis Internet, gère le chiffrement HTTPS, et transmet les requêtes à Vaultwarden sur le réseau interne de Docker.

Son grand avantage : il va chercher tout seul un certificat Let's Encrypt (le cadenas du navigateur) et le renouvelle sans que vous y pensiez.

👉 Le reverse proxy expliqué simplement : Reverse proxy et HTTPS automatique avec Caddy.

Les deux fichiers

mkdir -p ~/vaultwarden && cd ~/vaultwarden
vim compose.yaml

Contenu de compose.yaml (remplacez le domaine) :

services:
  vaultwarden:
    image: vaultwarden/server:latest   # en prod : épinglez une version précise
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://coffre.lecoqnumerique.fr"
      SIGNUPS_ALLOWED: "true"   # passez à "false" juste après la création de votre compte
    volumes:
      - ./vw-data:/data
    # aucun "ports:" ici : Vaultwarden n'est joignable que par Caddy

  caddy:
    image: caddy:2
    container_name: caddy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - ./caddy-config:/config
      - ./caddy-data:/data

Ce qu'il faut comprendre :

• Deux conteneurs : Vaultwarden et Caddy. Docker Compose les met automatiquement sur le même réseau interne, où Caddy peut joindre Vaultwarden par son nom (vaultwarden).
• DOMAIN doit contenir l'adresse complète, avec https://. Sinon, les pièces jointes ne fonctionneront pas correctement.
• volumes : ./vw-data contient votre coffre (base de données, pièces jointes). C'est ce dossier qu'il faudra sauvegarder.
• restart: unless-stopped : les conteneurs redémarrent tout seuls après un redémarrage du serveur.
• Seul Caddy publie des ports. Vaultwarden reste invisible depuis Internet.

Puis le Caddyfile :

vim Caddyfile

coffre.lecoqnumerique.fr {
  encode zstd gzip
  reverse_proxy vaultwarden:80 {
    header_up X-Real-IP {remote_host}
  }
}

Quatre lignes utiles : le nom de domaine, la compression, et le renvoi vers Vaultwarden (qui écoute sur son port interne 80). X-Real-IP transmet à Vaultwarden la vraie adresse des visiteurs, utile dans ses journaux.

Le lancement

docker compose up -d
docker compose logs -f caddy     # dans la fenêtre « logs » de tmux

Dans les journaux, vous verrez Caddy obtenir son certificat : en général, quelques secondes suffisent. Ouvrez https://coffre.lecoqnumerique.fr dans votre navigateur : le cadenas est là.

Curieux de ce que consomme Vaultwarden ?

docker stats --no-stream

Écrit en Rust, il reste très léger : quelques dizaines de mégaoctets de mémoire.

📚 Wiki Vaultwarden : utiliser Docker Compose

Étape 9 — Fermer la porte derrière soi

Créer votre compte, puis fermer les inscriptions

Ouvrez l'adresse de votre coffre et cliquez sur Créer un compte. Choisissez un mot de passe maître long et unique. Une phrase de plusieurs mots aléatoires fonctionne très bien, par exemple quatre ou cinq mots sans rapport entre eux.

Juste après, fermez les inscriptions. Sinon, n'importe qui sur Internet peut se créer un compte sur votre serveur. Dans compose.yaml, passez la ligne à :

      SIGNUPS_ALLOWED: "false"

et appliquez :

docker compose up -d

Enfin, dans votre coffre web : Paramètres > Sécurité > Connexion en deux étapes, et activez la double authentification avec une application TOTP (Aegis, 2FAS, etc.). Conservez précieusement le code de récupération.

La page d'administration (facultative)

Vaultwarden propose une page /admin pour gérer le serveur. Deux options :

1. La plus sûre : ne pas l'activer du tout. C'est le cas par défaut tant qu'il n'y a pas de jeton.
2. Si vous en avez besoin : on ne met jamais le jeton en clair. On le hache en Argon2 avec la commande intégrée à Vaultwarden.

Un hachage, c'est une empreinte à sens unique : le serveur peut vérifier que vous tapez le bon mot de passe, sans jamais le stocker lui-même. Argon2 est l'algorithme recommandé aujourd'hui pour ça.

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

Le mot de passe vous est demandé deux fois. Copiez la chaîne qui commence par $argon2id$, puis créez le fichier .env dans ~/vaultwarden :

vim .env && chmod 600 .env

VW_ADMIN_TOKEN='$argon2id$v=19$m=65540,t=3,p=4$...'

Apostrophes simples obligatoires, et un seul $ à chaque fois : sinon, Docker Compose essaierait d'interpréter les $ comme des variables.

Dans compose.yaml, sous environment: de vaultwarden, ajoutez :

      ADMIN_TOKEN: ${VW_ADMIN_TOKEN}

Puis vérifiez et appliquez :

docker compose config | grep ADMIN   # voir les $ doublés ici est normal
docker compose up -d

Bonus sécurité : réservez /admin à votre seule adresse IP. Dans le Caddyfile, à l'intérieur du bloc du domaine, ajoutez (en remplaçant par votre IP) :

  @admin {
    path /admin*
    not remote_ip 203.0.113.10
  }
  respond @admin 403

puis docker compose restart caddy.

Le piège du config.json

Dès que vous enregistrez un réglage depuis la page admin, Vaultwarden crée un fichier vw-data/config.json, qui prend le dessus sur vos variables d'environnement. Si un réglage de compose.yaml semble ignoré, c'est presque toujours lui. Soit vous gérez vos réglages uniquement depuis la page admin, soit uniquement depuis compose.yaml, mais ne mélangez pas.

📚 Wiki Vaultwarden : activer la page admin

Étape 10 — Connecter vos applications Bitwarden

C'est ici que tout prend son sens : vous utilisez les applications officielles Bitwarden, simplement branchées sur votre serveur.

Sur l'application mobile, l'extension de navigateur ou l'application de bureau, sur l'écran de connexion :

1. Touchez le sélecteur de serveur (« Connexion sur : bitwarden.com ») ;
2. Choisissez Auto-hébergé ;
3. Saisissez l'URL de votre serveur : https://coffre.lecoqnumerique.fr ;
4. Enregistrez, puis connectez-vous avec votre adresse et votre mot de passe maître.

📚 Bitwarden : connecter les clients à un serveur auto-hébergé

Vous venez d'un autre gestionnaire ? La plupart (1Password, LastPass, Chrome, Firefox…) permettent d'exporter vos mots de passe. Dans votre coffre web : Outils > Importer des données. Une fois l'import vérifié, supprimez le fichier d'export : il contient tous vos mots de passe en clair.

Bonus — Votre coffre dans le terminal

C'est là que ça devient vraiment intéressant pour un développeur : récupérer un secret à la volée, directement dans un script, sans fichier .env qui traîne dans un dépôt Git.

Sur votre ordinateur :

npm install -g @bitwarden/cli      # ou : brew install bitwarden-cli
bw config server https://coffre.lecoqnumerique.fr
bw login
export BW_SESSION="$(bw unlock --raw)"
bw get password "GitHub"
GITHUB_TOKEN="$(bw get password 'GitHub token')" ./deploy.sh
bw lock

Étape par étape :

• bw config server indique votre serveur, avant de vous connecter.
• bw unlock --raw renvoie une clé de session. On la range dans la variable BW_SESSION : toutes les commandes suivantes l'utilisent, sans redemander le mot de passe.
• bw get password "Nom" récupère un secret. Il ne renvoie qu'un seul résultat : donnez des noms d'éléments uniques dans votre coffre.
• bw lock verrouille quand vous avez fini.

Soyons honnêtes : le secret passe quand même en clair dans votre shell et dans l'environnement du programme lancé. C'est bien mieux qu'un fichier oublié dans un dépôt, mais ce n'est pas de la magie. Ne faites jamais echo d'un secret, et verrouillez toujours à la fin.

📚 Documentation officielle du CLI Bitwarden

Dépannage

Mettre à jour Vaultwarden

cd ~/vaultwarden
docker compose pull
docker compose up -d
docker image prune -f

Faites-le régulièrement, et lisez les notes de version avant une mise à jour majeure. Sauvegardez avant.

Et après ? Les sauvegardes

Récapitulons : un serveur européen, un pare-feu en amont, SSH verrouillé sans s'être enfermé dehors, des mises à jour automatiques, et votre coffre en HTTPS, jusque dans votre terminal.

Il manque une pièce essentielle : les sauvegardes. Un coffre sans sauvegarde, c'est un coffre en sursis. Si le disque du serveur lâche, ou si vous faites une fausse manipulation, tout le contenu de vw-data disparaît. Ce sera le sujet du prochain épisode.

En attendant, une sécurité simple : dans votre coffre web, Outils > Exporter le coffre, choisissez le format JSON chiffré, et rangez le fichier hors du serveur. C'est une copie de secours de vos données, protégée par un mot de passe.

Une question, un blocage pendant l'installation ? Écrivez-moi, je lis tous les messages.

Vaultwarden est un serveur open source non officiel, compatible avec les applications Bitwarden. Bitwarden est une marque de Bitwarden Inc. Ce guide n'est pas sponsorisé. Tarifs Hetzner relevés en octobre 2026, susceptibles d'évoluer.

Pour aller plus loin sur Le Coq Numérique

• Clé SSH ED25519 : comprendre et créer la vôtre
• tmux pour les débutants : ne perdez plus jamais une session
• Docker contourne ufw : comprendre et se protéger
• Reverse proxy et HTTPS automatique avec Caddy