Auto-héberger Vaultwarden : Bitwarden en 20 minutes

Pour auto-héberger Vaultwarden, voici le tuto chronométré que j'aurais aimé qu'on me file : d'un VPS tout neuf à ton premier mot de passe enregistré en moins de 20 minutes. Vaultwarden est une toute petite réimplémentation en Rust du serveur Bitwarden, le tout tient dans un seul conteneur Docker, et il parle exactement le même protocole que le vrai serveur Bitwarden, donc chaque client officiel fonctionne tel quel avec lui. L'extension navigateur, les applis mobiles, le bureau, tous, sans build patché ni fork douteux. Puis vient la discipline barbante que tu te dois avant d'aller dormir. Les sauvegardes. fail2ban. Verrouiller cette route admin pour qu'elle ne te morde pas dans six mois.

Ça fait des années que je gère mes propres mots de passe sur Vaultwarden. Revenir à un coffre hébergé ailleurs me ferait bizarre à ce stade. C'est une toute petite réimplémentation en Rust du serveur Bitwarden, le tout tient dans un seul conteneur Docker, et voilà l'astuce maligne : il parle exactement le même protocole que le vrai serveur Bitwarden. Du coup chaque client officiel fonctionne tel quel avec lui. L'extension navigateur, les applis mobiles, le bureau, tous, sans build patché ni fork douteux. Le mien occupe peut-être 50 Mo sur le disque et quelques centaines de Mo de RAM, et la base SQLite se sent parfaitement bien sur un Raspberry Pi ou un petit serveur ARM Hetzner pas cher. J'ai testé les deux. Bref, voici le tuto chronométré que j'aurais aimé qu'on me file : d'un VPS tout neuf à ton premier mot de passe enregistré en moins de 20 minutes. Puis la discipline barbante que tu te dois à toi-même avant d'aller dormir. Les sauvegardes. fail2ban. Verrouiller cette route admin pour qu'elle ne te morde pas dans six mois.

Pourquoi Vaultwarden plutôt que Bitwarden Cloud

Quelques raisons, honnêtement, et elles ne se valent pas toutes. Le coût, c'est l'évidence. Chaque fonctionnalité que Bitwarden planque derrière un paywall (organisations, TOTP, accès d'urgence, pièces jointes), tu l'obtiens, pour le prix du VPS qui fait tourner tout ça. Ensuite il y a la souveraineté, qui compte plus pour moi que je ne l'aurais cru. Mon coffre chiffré ne quitte jamais ma propre machine, donc même quelqu'un assis sur l'intégralité de mes logs Cloudflare ne voit que du TLS vers mon domaine, rien d'autre. Et la vélocité : Vaultwarden a tendance à sortir les fonctionnalités avant que le serveur officiel ne daigne le faire. Argon2id était là d'office, le support FIDO2 WebAuthn est arrivé tôt, les notifications push transitent par le propre service de Bitwarden. Je ne vais pas prétendre que c'est gratuit, ceci dit. C'est désormais toi qui es sur le pont pour les mises à jour, les sauvegardes et le TLS, et c'est un projet bénévole, donc quand un truc casse à minuit, personne ne décroche le téléphone. Voilà le compromis. Je l'ai fait il y a des années et je n'ai jamais regretté, mais lance-toi en sachant ce que tu signes.

Prérequis, ce qu'il te faut avant de lancer le chrono

• Un VPS. Prends l'offre la moins chère qui existe sur Hetzner Cloud, OVH, peu importe. 1 vCPU avec 1 Go de RAM et un disque de 20 Go, c'est bien plus qu'il ne t'en faudra. Le mien tourne au ralenti autour de 80 Mo.
• Un nom de domaine avec un enregistrement A qui pointe vers le VPS. Pas question de zapper le HTTPS ici. Les clients Bitwarden modernes refusent catégoriquement le HTTP en clair, et il n'y a aucun repli pour négocier.
• Un accès SSH par clé, pas par mot de passe. Tu te connectes encore avec un mot de passe ? Corrige ça d'abord, puis reviens.
• 10 minutes de patience le temps que cet enregistrement A se propage vraiment. Précipite-toi et Caddy va tenter d'aller chercher un certificat Let's Encrypt sur un enregistrement à moitié propagé, puis se planter. Je l'ai vu se produire plus d'une fois.

L'installation en 20 minutes (docker compose + Caddy)

Dépose les deux fichiers dans le même dossier et tu y es quasiment. Deux conteneurs sur un réseau partagé, et c'est toute la stack. Une chose avant de coller, ceci dit. Ce ADMIN_TOKEN doit être une chaîne aléatoire vraiment longue, pas un placeholder. Génère-la avec openssl rand -base64 48. Quoi que tu fasses, ne tape pas « admin123 » en te promettant de le changer plus tard. Tu ne le feras pas.

# docker-compose.yml
services:
  vaultwarden:
    image: vaultwarden/server:latest
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "true"           # disable after first signup
      ADMIN_TOKEN: "<long-random-string>"
      WEBSOCKET_ENABLED: "true"
      LOG_FILE: "/data/vaultwarden.log"
    volumes:
      - ./data/vaultwarden:/data

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

# Caddyfile
vault.example.com {
    encode gzip
    reverse_proxy vaultwarden:80
    header {
        Strict-Transport-Security "max-age=31536000;"
        X-Frame-Options "DENY"
        X-Content-Type-Options "nosniff"
        Referrer-Policy "no-referrer"
    }
}

Maintenant, lance-le.

$ docker compose up -d
[+] Running 2/2
 ✔ Container vault-caddy Started
 ✔ Container vault-vaultwarden Started

$ docker logs --tail 20 vault-caddy | grep certificate
{"level":"info","msg":"certificate obtained successfully","identifier":"vault.example.com"}

Tu vois cette ligne ? Caddy est parti chercher le certificat auprès de Let's Encrypt entièrement tout seul. Pas de certbot, pas d'entrée cron, rien à surveiller de ton côté. C'est exactement pour ça que je le dégaine avant tout le reste. Ouvre https://vault.example.com maintenant et tu devrais tomber pile sur l'écran de connexion du Web Vault de Bitwarden. Tu obtiens un avertissement TLS à la place ? Neuf fois sur dix, ton DNS n'avait juste pas fini de se propager. Laisse-lui quelques minutes, redémarre Caddy, réessaie.

Première connexion admin et désactivation des inscriptions ouvertes

L'ordre compte ici, et le faire à l'envers est un grand classique. Crée d'abord ton propre compte via l'inscription publique. Puis claque la porte derrière toi. Fais-le dans l'autre sens et tu te retrouveras bel et bien verrouillé hors de ton propre serveur, ce qui est un type d'agacement bien particulier.

1. Clique sur Create account et mets ton email plus un mot de passe maître d'au moins 14 caractères. Vaultwarden l'impose de toute façon aux nouveaux comptes en 2026. Et écoute, c'est le seul mot de passe que tu ne pourras jamais réinitialiser, alors fais en sorte qu'il compte.
2. Connecte-toi, puis prouve que le coffre fonctionne vraiment en y planquant un identifiant jetable. Bien mieux de le découvrir maintenant qu'à mi-chemin de ta migration.
3. Reconnecte-toi en SSH, mets SIGNUPS_ALLOWED: "false" dans docker-compose.yml, et lance docker compose up -d pour redémarrer.
4. Va sur https://vault.example.com/admin et colle l'ADMIN_TOKEN de ton fichier compose. C'est ton tableau de bord à partir de maintenant. Les invitations, la gestion des utilisateurs, tout.

Laisse SIGNUPS_ALLOWED=true traîner là et ce n'est qu'une question de temps. Des bots scannent les instances Vaultwarden fraîches en continu, et à la seconde où l'un d'eux tombe sur une inscription ouverte, il va créer un compte et commencer à y entreposer des données (parfois des trucs bien plus glauques) dans ton serveur. Désactive-le dès l'instant où ton propre compte existe. On parle de minutes là, pas d'heures.

Pointer les clients Bitwarden vers ton serveur

Les gens se compliquent la vie sur cette partie. Chaque client Bitwarden officiel te laisse le pointer vers un serveur personnalisé. Le réglage se cache juste derrière l'écran de connexion, ce qui explique que personne ne le trouve. Touche l'engrenage, choisis Self-hosted, tape https://vault.example.com dans le champ Server URL, terminé. Les applis mobiles et l'extension le prennent en compte aussitôt. Un piège : fais ça avant de te connecter, jamais après.

• Extension navigateur (Chrome, Firefox, Edge, Safari) : Settings, Logged out, icône d'engrenage, Server URL.
• iOS / Android : touche Region sur l'écran de connexion, puis Self-hosted. Celui-là piège tout le monde, parce qu'il est rangé sous Region, pas sous Server. Aucune idée de pourquoi ils ont fait ça.
• Bureau (Win/macOS/Linux) : Settings, Server URL.
• CLI (bw) : bw config server https://vault.example.com puis bw login.

Durcissement jour 2 : fail2ban, sauvegardes, route admin

Le conteneur tourne, les clients se connectent, et tu n'as toujours pas fini. Ce qui suit, c'est ce qui sépare le « ça marche » du « je lui confierais toute ma vie numérique ». Fais-le ce soir. Pas un jour, pas le week-end prochain, ce soir, tant que tu as encore la tête dedans.

• fail2ban : Vaultwarden logge chaque échec de connexion dans /data/vaultwarden.log. Pointe fail2ban dessus avec le filtre Vaultwarden officiel (trois tentatives, puis un ban d'une heure) et le vacarme incessant des brute-force de passage cesse tout simplement d'apparaître dans tes logs. Dix minutes de configuration. Ça t'épargne des heures à plisser les yeux sur des lignes d'authentification plus tard.
• Restic en off-site : un snapshot nocturne du mount ./data/vaultwarden vers Backblaze B2 ou une storage box Hetzner, chiffré avec une passphrase de 32 octets. Voilà le truc que les gens ratent de façon catastrophique, alors lis-le deux fois. Cette passphrase ne peut pas vivre dans le coffre que tu sauvegardes. Si cette machine meurt, tu te retrouverais verrouillé hors de la seule chose qui détient la clé de tout le reste. Note-la quelque part hors ligne. Le bucket en lui-même ne coûte quasiment rien. 60 Go sur B2 me reviennent à environ 0,30 EUR par mois.
• Verrouille la route admin : le token admin à lui seul ne te sauvera pas. Ajoute un challenge basic_auth sur /admin dans le Caddyfile. Mieux encore, clôture-la à ton IP de domicile avec @admin path /admin* et respond @admin 403 pour tous les autres. Personne ne peut atteindre /admin en premier lieu ? Alors personne n'est là à brute-forcer ce token.

Comptes org et partage en famille

C'est là que le self-hosting se rembourse discrètement tout seul. Le tableau de bord te file des Organisations illimitées, exactement ce que Bitwarden te facture par siège, chacune avec ses propres collections, rôles (Owner, Admin, Manager, User) et sa politique d'accès d'urgence. Voici comment je l'ai câblé pour une famille de quatre :

1. Admin, Users, crée un utilisateur pour chaque personne, puis envoie le lien d'invitation.
2. Tout le monde accepte, et chacun atterrit sur son propre coffre personnel sur le même serveur.
3. Monte une org appelée « Family », invite les trois autres, et partage une unique collection de trucs du foyer. La connexion du routeur, le compte Netflix, la facture d'électricité, bref tout ce dont tout le monde a vraiment besoin.
4. Le truc vraiment sympa ? Les coffres personnels restent totalement privés pour chacun. Seule cette unique collection partagée apparaît pour tout le monde, donc personne ne fouine en douce dans les identifiants des autres.

Sources et pour aller plus loin

• Vaultwarden, wiki
• Bitwarden, aide

Questions fréquentes