Installer Vaultwarden sur un VPS avec Docker

Ce que vous allez construire

Un gestionnaire de mots de passe que vous contrôlez entièrement : Vaultwarden exécuté dans un petit conteneur derrière un reverse proxy qui termine les connexions HTTPS, avec les applications Bitwarden officielles configurées sur votre téléphone, votre ordinateur portable et votre navigateur pour l’utiliser. Vaultwarden réimplémente l’API serveur Bitwarden en Rust et utilise le même protocole que bitwarden.com. Tous les clients officiels fonctionnent donc avec lui sans modification, tandis qu’il utilise environ 100 MB de RAM au lieu de la pile officielle composée de plusieurs conteneurs.

L’installation elle-même tient en une douzaine de lignes Compose. Les trois points réellement importants, et qui provoquent les pannes, sont les suivants : TLS doit être opérationnel avant le premier chargement du coffre web ; les inscriptions publiques doivent être désactivées dès que votre propre compte existe ; le volume de données doit être sauvegardé et restauré lors d’un test, car ce répertoire contient tous les mots de passe dont vous disposez.

Prérequis et points importants à connaître

• Un VPS équipé de Docker Engine et du plugin Compose, sur une instance KVM Ubuntu 24.04 fraîchement installée, avec root ou sudo. 512 MB de RAM suffisent réellement ; 1 GB offre une marge confortable. C’est l’un des services les moins gourmands que vous puissiez exécuter, et il figure en bonne place dans la sélection des services qui méritent d’être auto-hébergés. Dimensionnez toutefois l’instance en fonction des autres services qui y seront installés : ajouter une bibliothèque photo auto-hébergée comme PhotoPrism ou Immich sur le même VPS fait passer le minimum de RAM à plusieurs gigaoctets, tandis que Vaultwarden l’augmente à peine. Le même calcul s’applique aux frontends multimédias que vous ajouterez ensuite : transformer une bibliothèque Jellyfin en vidéoclub des années 90 où l’on peut déambuler implique un conteneur supplémentaire toujours actif et une marge de RAM pour le transcodage, sur le même budget.
• Un domaine avec un enregistrement A (et AAAA si vous disposez d’IPv6) qui pointe vault.example.com vers le VPS. Le certificat TLS est délivré pour ce nom exact ; le DNS doit donc le résoudre avant le démarrage.
• Les ports 80 et 443 ouverts sur Internet et pris en charge par votre reverse proxy, jamais directement par Vaultwarden. Le port 80 sert uniquement au challenge du certificat ACME et à la redirection de HTTP vers HTTPS.
• Le principal point à connaître dès le départ : les clients Bitwarden refusent de communiquer avec un serveur qui n’utilise pas HTTPS. Il n’est pas possible de « tester d’abord en http » : cette méthode ne fonctionne pas, pour une raison précise expliquée dans la suite.

Pourquoi Vaultwarden plutôt que la stack Bitwarden officielle

Les mêmes clients, avec une empreinte bien plus faible. Bitwarden en auto-hébergement est distribué sous la forme d’un ensemble de conteneurs (MSSQL, Nginx, Identity, Api, Admin, entre autres) et nécessite environ 2 GB de RAM. Vaultwarden est un binaire unique qui stocke par défaut toutes les données dans une base SQLite et ne consomme que quelques dizaines de mégaoctets au repos. Pour une personne, une famille ou une petite équipe, c’est le choix évident. Comme il implémente fidèlement l’API Bitwarden, vos données restent portables entre Vaultwarden et bitwarden.com.

En contrepartie, vous renoncez à la plupart des fonctions destinées aux entreprises : pas de provisioning SCIM (même si la prise en charge expérimentale du SSO OpenID Connect a été ajoutée dans 1.35.0). Vous êtes aussi l’opérateur : les mises à jour, HTTPS et sauvegardes sont à votre charge. Ce guide couvre ces trois tâches.

Pourquoi HTTPS est obligatoire

Le coffre web Bitwarden et les extensions de navigateur dérivent vos clés de chiffrement dans le navigateur à l’aide de l’API Web Crypto (window.crypto.subtle). Les navigateurs n’exposent crypto.subtle que dans un contexte sécurisé, c’est-à-dire via HTTPS, ou dans le cas particulier de http://localhost. En http://vault.example.com non chiffré, cette fonctionnalité est undefined. Dès que l’application tente de dériver une clé, elle lève donc une erreur, et la console affiche :

Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'importKey')

La page reste bloquée ou affiche une erreur cryptographique générique. La connexion échoue. Les clients desktop, mobiles et de navigateur vérifient eux-mêmes l’URL auto-hébergée. Avec un endpoint http ou inaccessible, ils refusent la connexion et affichent :

This is not a recognized Bitwarden server. You may need to check with your provider or update your server.

Les deux erreurs ont la même cause : HTTPS n’est pas configuré correctement. Configurez donc TLS en premier. N’ouvrez jamais le coffre via http, même une seule fois pour effectuer une vérification rapide.

Étape 1, DNS et reverse proxy (TLS en premier)

Pointez l’enregistrement vers votre VPS et vérifiez qu’il se résout vers la bonne adresse :

dig +short vault.example.com

La ligne affichée doit contenir l’adresse IP de votre VPS. Si elle est vide ou incorrecte, corrigez le DNS et attendez l’expiration du TTL. L’émission du certificat échoue si le nom ne se résout pas.

Pour le frontend HTTPS, ce guide utilise Traefik. Il émet et renouvelle automatiquement les certificats Let’s Encrypt et s’intègre directement à Compose. Si vous ne l’exécutez pas déjà, suivez d’abord la configuration du reverse proxy Traefik et du TLS automatique. Elle crée un réseau Docker externe (proxy ci-dessous) et un resolver ACME (letsencrypt) auquel le service Vaultwarden se connecte. Un nginx classique avec un certificat émis manuellement fonctionne de la même manière du côté de Vaultwarden.

Vous préférez nginx et Certbot à Traefik ? Connectez Vaultwarden à 127.0.0.1:8080 (ajoutez ports: ["127.0.0.1:8080:80"] au service et supprimez les labels Traefik), puis émettez un certificat et configurez le proxy vers Vaultwarden. La partie consacrée au certificat est détaillée dans l’émission de certificats Let’s Encrypt avec Certbot et nginx. Le point important supplémentaire concerne la mise à niveau WebSocket sur le chemin des notifications :

server {
    listen 443 ssl;
    server_name vault.example.com;

    client_max_body_size 525M;

    location / {
        proxy_pass http://127.0.0.1:8080;
        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_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Notez la ligne X-Real-IP. Elle permet à Fail2ban d’identifier ensuite l’attaquant réel plutôt que 127.0.0.1. Tout le reste de ce guide est identique, que Traefik ou nginx soit placé devant Vaultwarden.

Étape 2, le fichier Compose

Créez d’abord le répertoire du projet. Ce guide utilise /opt/vaultwarden, ce qui rend prévisible le nom du projet Compose et donc celui du volume de données, vaultwarden_vw-data. Les étapes concernant Fail2ban et les sauvegardes ci-dessous dépendent précisément de ce nom.

sudo mkdir -p /opt/vaultwarden
cd /opt/vaultwarden

Créez un .env pour le secret d’administration et le fichier Compose dans ce répertoire.

# .env
ADMIN_TOKEN=paste-a-strong-token-here

Générez ce token avec openssl rand -base64 48, puis collez-le dans le fichier. (Une forme hachée plus robuste est présentée ensuite ; une longue chaîne aléatoire convient pour commencer.)

# docker-compose.yml
services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "true"          # closed in Step 4, keep true just to register
      ADMIN_TOKEN: "${ADMIN_TOKEN}"
      IP_HEADER: "X-Forwarded-For"     # X-Real-IP if your proxy sends that instead
      LOG_FILE: "/data/vaultwarden.log"
      LOG_LEVEL: "warn"
    volumes:
      - vw-data:/data
    networks:
      - proxy
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.vw.rule=Host(`vault.example.com`)"
      - "traefik.http.routers.vw.entrypoints=websecure"
      - "traefik.http.routers.vw.tls.certresolver=letsencrypt"
      - "traefik.http.services.vw.loadbalancer.server.port=80"

volumes:
  vw-data:

networks:
  proxy:
    external: true

Deux éléments de ce fichier portent toute l’architecture. Il n’y a aucun mapping ports: : Vaultwarden est donc accessible uniquement via Traefik et TLS. Publier son port sur l’hôte permettrait de servir le coffre en HTTP par erreur. DOMAIN doit également être l’URL HTTPS publique complète. Elle est intégrée aux liens des pièces jointes, à l’authentification 2FA WebAuthn et à l’endpoint de notifications. Une valeur incorrecte ou en HTTP casse donc ces fonctions, même si le site se charge. Le tag latest constitue une exception délibérée à la règle habituelle qui consiste à ne jamais utiliser latest. Vaultwarden publie ses versions stables sous la forme d’une seule image évolutive, avec :testing comme canal distinct pour les préversions. Effectuez donc les mises à jour volontairement et parcourez les notes de version avant de tirer l’image. Cette exception reste limitée : pour la plupart des conteneurs qui doivent rester actifs longtemps, il vaut mieux utiliser un tag exact. C’est ce qui permet à un agent auto-hébergé toujours actif sur le même VPS de rester prévisible après les redémarrages et les téléchargements d’images.

Démarrez les conteneurs et surveillez le journal :

docker compose up -d
docker compose logs -f vaultwarden

Un démarrage correct se termine par une ligne comme Rocket has launched from http://0.0.0.0:80. Attendez quelques secondes que Traefik récupère le certificat, puis ouvrez https://vault.example.com. Vous devriez obtenir le coffre web Bitwarden avec un cadenas valide et sans avertissement de certificat.

Étape 3, un ADMIN_TOKEN robuste et le piège de $$

ADMIN_TOKEN protège /admin, le panneau qui peut lire tous les utilisateurs et tous les paramètres de votre instance. Traitez-le donc comme un mot de passe root. Deux formats fonctionnent.

Le format simple est la chaîne aléatoire que vous avez déjà générée avec openssl rand -base64 48. Comme base64 ne contient jamais de $, elle peut être insérée directement dans .env sans échappement.

Le format renforcé est un hash Argon2 PHC. Le token en clair n’est donc jamais enregistré sur le disque. Générez-en un avec la même image :

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

La commande demande le token deux fois, puis affiche une chaîne qui commence par $argon2id$v=19$.... Voici le piège qui fait perdre une heure : Docker Compose interprète $ comme une interpolation de variable. Vous devez donc doubler chaque $ en $$ lorsque vous collez le hash dans le fichier Compose. Placez-le directement sous environment:, sans passer par .env, et ne le mettez pas entre guillemets :

    environment:
      ADMIN_TOKEN: $$argon2id$$v=19$$m=19456,t=2,p=1$$c29tZXNhbHQ$$RdescudvJCsgt3ub+b+dWRWJTmaaJObG

Si vous laissez les simples signes $, Compose affiche l’avertissement The "argon2id" variable is not set et vide le token. /admin rejette alors votre mot de passe correct. Exécutez docker compose up -d et conservez le token en clair saisi à l’invite dans votre gestionnaire de mots de passe.

Étape 4, créez votre compte, puis fermez l’accès

Avec SIGNUPS_ALLOWED: "true", ouvrez https://vault.example.com, cliquez sur Create account, puis créez votre compte avec votre adresse e-mail et un mot de passe maître robuste. Ce mot de passe maître est impossible à récupérer et aucune réinitialisation n’est disponible. Stockez-le d’abord dans un emplacement durable.

Fermez maintenant l’accès. Modifiez le fichier Compose pour désactiver les inscriptions :

      SIGNUPS_ALLOWED: "false"

Réappliquez la configuration avec docker compose up -d. Ce n’est pas une mesure de sécurisation que vous pouvez reporter. Si les inscriptions restent ouvertes, toute personne qui trouve l’URL, y compris les crawlers, peut créer un compte sur votre serveur. Elle ne peut pas lire votre coffre-fort, mais elle consomme des ressources et transforme votre instance privée en service ouvert. Pour vérifier que les inscriptions sont restées activées, /admin répertorie des comptes que vous n’avez jamais créés.

Pour ajouter ultérieurement des membres de votre famille ou de votre équipe sans rouvrir les inscriptions publiques, utilisez le bouton Invite User dans /admin. Cette méthode nécessite une configuration SMTP afin que l’invité reçoive son lien.

Étape 5 : accéder à /admin

Accédez à https://vault.example.com/admin et saisissez le token admin en clair (la chaîne aléatoire ou le mot de passe dont vous avez calculé le hash, et non le hash lui-même). Vous pouvez ensuite lister les utilisateurs, ajuster les paramètres, envoyer un e-mail de test et créer un snapshot de la base de données.

Si la page renvoie 404 Not Found, ADMIN_TOKEN est vide ou non défini, ce qui désactive entièrement le panneau. C’est un choix valide si vous n’en avez jamais besoin. Si le panneau se charge, mais refuse votre token, consultez le problème d’échappement de $$ dans la liste des problèmes ci-dessous. Vous avez oublié le token ? Aucun prompt de récupération n’est prévu. Modifiez .env ou le fichier Compose, définissez un nouveau token, puis docker compose up -d.

Étape 6, connecter les clients Bitwarden

Chaque client officiel peut pointer vers un serveur auto-hébergé. Installez donc le client Bitwarden pour ordinateur, mobile ou navigateur depuis les boutiques habituelles. Vous n’avez pas besoin d’une version spéciale de Vaultwarden.

Avant de vous connecter, ouvrez la roue dentée des paramètres sur l’écran de connexion (intitulée Self-hosted ou Region → Self-hosted), définissez Server URL sur https://vault.example.com, puis enregistrez. Connectez-vous ensuite avec l’adresse e-mail et le mot de passe maître que vous avez enregistrés. Le client devrait se connecter immédiatement et proposer de remplir et d’enregistrer les identifiants.

Si un client affiche This is not a recognized Bitwarden server. You may need to check with your provider or update your server., l’URL est incorrecte, utilise http ou le certificat n’est pas approuvé. Vérifiez d’abord que https://vault.example.com se charge correctement dans un navigateur. Les mises à jour lentes sur les autres appareils utilisent le push WebSocket, présenté ci-dessous.

Étape 7, une jail Fail2ban pour le endpoint de connexion

Vaultwarden journalise chaque échec de connexion dans le fichier défini par LOG_FILE, exactement ce qu’il faut pour se protéger contre les attaques par force brute. Si Fail2ban n’est pas déjà installé, l’installation et les notions de base sont présentées dans le guide de durcissement de Fail2ban pour SSH ; nous allons ici ajouter une jail pour le vault.

Commencez par trouver l’emplacement du volume nommé sur l’hôte, afin que Fail2ban puisse lire le journal :

docker volume inspect vaultwarden_vw-data --format '{{ .Mountpoint }}'

Cette commande affiche une sortie similaire à /var/lib/docker/volumes/vaultwarden_vw-data/_data ; le journal se trouve dans vaultwarden.log. Créez le filtre :

# /etc/fail2ban/filter.d/vaultwarden.conf
[Definition]
failregex = ^.*Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$
ignoreregex =

Puis la jail :

# /etc/fail2ban/jail.d/vaultwarden.local
[vaultwarden]
enabled   = true
filter    = vaultwarden
logpath   = /var/lib/docker/volumes/vaultwarden_vw-data/_data/vaultwarden.log
banaction = iptables-allports
chain     = DOCKER-USER
maxretry  = 5
findtime  = 600
bantime   = 3600

Rechargez la configuration avec sudo systemctl restart fail2ban et vérifiez le résultat avec sudo fail2ban-client status vaultwarden.

Trois détails liés à Docker déterminent l’efficacité de cette protection. Premièrement, si le journal affiche IP: 127.0.0.1 ou l’adresse de votre proxy à chaque tentative échouée, Vaultwarden bloque le proxy. Définissez IP_HEADER avec l’en-tête réellement envoyé par votre proxy (X-Forwarded-For pour Traefik, X-Real-IP pour le bloc nginx ci-dessus, CF-Connecting-IP derrière Cloudflare). Deuxièmement, la chaîne iptables correcte dépend de votre proxy : avec Traefik exécuté dans un conteneur dont les ports sont publiés, le trafic passe par le chemin FORWARD de Docker. Le blocage doit donc être placé dans DOCKER-USER, comme ci-dessus. En revanche, si vous avez choisi l’option host-nginx de l’étape 1, les connexions se terminent sur nginx dans la chaîne INPUT de l’hôte. Un blocage DOCKER-USER ne les intercepte jamais. Dans ce cas, supprimez la ligne chain = DOCKER-USER afin que Fail2ban utilise la chaîne INPUT par défaut. Troisièmement, utilisez banaction = iptables-allports plutôt que la valeur par défaut basée sur le port. Cette jail ne définit aucun port, et un blocage de tous les ports dans DOCKER-USER empêche proprement l’attaquant d’accéder à tous les services publiés sur le serveur.

Étape 8, sauvegardez le coffre, puis restaurez-le réellement

Le volume vw-data est votre gestionnaire de mots de passe. Il contient db.sqlite3 (toutes les entrées), les répertoires attachments/ et sends/, les fichiers rsa_key.* qui signent les sessions de connexion, ainsi que config.json depuis le panneau d’administration. Une sauvegarde qui en ignore un seul échoue au moment où vous en avez besoin.

Copier db.sqlite3 pendant que Vaultwarden y écrit peut produire un fichier partiellement écrit et corrompu. Effectuez donc un snapshot à froid. L’interruption ne dure que quelques secondes :

#!/usr/bin/env bash
set -euo pipefail
STAMP=$(date +%F)
DEST=/root/vw-backups
VOL=$(docker volume inspect vaultwarden_vw-data --format '{{ .Mountpoint }}')
mkdir -p "$DEST"
docker compose -f /opt/vaultwarden/docker-compose.yml stop vaultwarden
tar czf "$DEST/vw-$STAMP.tgz" -C "$VOL" .
docker compose -f /opt/vaultwarden/docker-compose.yml start vaultwarden

Exécutez cette opération chaque nuit avec cron et copiez .tgz hors du serveur. Une sauvegarde conservée uniquement sur le serveur que vous protégez n’est pas une sauvegarde. La méthode propre consiste à l’envoyer avec une sauvegarde restic nocturne vers un autre serveur ou un stockage objet, qui chiffre l’archive et déduplique automatiquement les snapshots répétés. Le bouton Backup Database du panneau d’administration fournit un snapshot à chaud pratique du seul fichier SQLite, mais il exclut les pièces jointes et les clés.

Voici maintenant l’opération qui distingue une vraie sauvegarde d’un simple espoir : restaurez-la une fois et vérifiez qu’elle fonctionne :

mkdir -p /tmp/vw-restore
tar xzf /root/vw-backups/vw-2026-07-15.tgz -C /tmp/vw-restore
docker run --rm -p 127.0.0.1:8888:80 -v /tmp/vw-restore:/data vaultwarden/server

Depuis votre ordinateur portable, créez un tunnel vers le serveur avec ssh -L 8888:127.0.0.1:8888 you@your-vps, puis ouvrez http://localhost:8888. Comme localhost est un contexte sécurisé, crypto.subtle est disponible et le coffre est déchiffré via http en clair ici, ce qui est le seul emplacement autorisé. Connectez-vous avec votre mot de passe principal et vérifiez que vos entrées sont présentes. Si c’est le cas, votre base de données, vos clés RSA et votre mot de passe principal sont bien restaurés, et vous pouvez reconstruire l’installation sur un VPS vierge en quelques minutes. Arrêtez le conteneur avec Ctrl-C, puis supprimez /tmp/vw-restore. Utilisez cette méthode de tunnel pour toute autre interface d’administration du serveur qui ne doit jamais être exposée sur Internet. C’est également ainsi que vous accéderiez à un scanner de sécurité open-kritt auto-hébergé sur le port 5173.

Modes d’échec et messages affichés

Cannot read properties of undefined (reading 'importKey') dans la console du navigateur. Le coffre a été chargé via http, donc crypto.subtle est indéfini. Accédez-y uniquement via https:// et ajoutez la redirection HTTP vers HTTPS sur le proxy.

This is not a recognized Bitwarden server... dans un client. L’URL du serveur utilise http, contient une erreur ou le certificat n’est pas approuvé. Vérifiez que https://vault.example.com affiche un cadenas valide, puis saisissez à nouveau cette URL dans les paramètres d’auto-hébergement du client.

/admin refuse le mot de passe correct. Le hash Argon2 a perdu ses caractères d’échappement. Chaque $ doit être $$ dans Compose. Il est également possible que vous ayez saisi le hash au lieu du texte en clair correspondant.

Synchronisation lente entre les appareils ; la console affiche WebSocket connection to 'wss://vault.example.com/notifications/hub' failed. Le proxy ne transmet pas les en-têtes Upgrade/Connection. Traefik le fait automatiquement ; nginx nécessite les deux lignes de mise à niveau de l’étape 1. Le coffre reste fonctionnel, mais la synchronisation ne se fait qu’à l’ouverture. L’ancien port dédié 3012 n’existe plus depuis la version v1.31.0. Aucune route WebSocket distincte n’est donc nécessaire.

Fail2ban signale un bannissement, mais l’attaquant continue à se connecter. Il bannit 127.0.0.1 parce que IP_HEADER est incorrect, ou le bannissement se trouve dans la mauvaise chaîne iptables. Définissez chain = DOCKER-USER et banaction = iptables-allports.

Mises à niveau

Téléchargez la nouvelle image et recréez le conteneur ; le volume nommé et toutes vos données sont conservés :

docker compose pull
docker compose up -d

Vaultwarden publie fréquemment de nouvelles versions. Consultez les notes de version du projet au lieu de figer une version de correctif, car certaines versions contiennent des instructions de migration. Effectuez une nouvelle sauvegarde avant toute mise à niveau majeure ; vous pouvez revenir à la version précédente en restaurant l’archive tar dans un nouveau volume.

FAQ

Vaultwarden est-il identique à Bitwarden ?

C’est un serveur compatible et indépendant, pas le serveur officiel. Vaultwarden réimplémente l’API serveur de Bitwarden en Rust. Les clients officiels pour ordinateur, mobile, navigateur et CLI fonctionnent donc avec lui, pour une consommation de ressources très inférieure à celle de la stack officielle. Le format du coffre est identique. Vous pouvez donc migrer dans les deux sens en exportant puis en important les données.

Ai-je vraiment besoin de HTTPS, ou puis-je l’exécuter en http sur mon LAN ?

Vous avez besoin de HTTPS pour tout sauf un test localhost. Le coffre web et les extensions Bitwarden utilisent l’API Web Crypto du navigateur. Celle-ci n’est disponible que dans un contexte sécurisé. En http simple, le client renvoie Cannot read properties of undefined et la connexion échoue. La seule adresse http qui fonctionne est http://localhost. C’est pourquoi le test de restauration de l’étape 8 utilise un tunnel SSH.

Comment empêcher des inconnus de créer un compte sur mon serveur ?

Définissez SIGNUPS_ALLOWED: "false" dans le fichier Compose, puis exécutez docker compose up -d immédiatement après avoir créé votre propre compte. Ensuite, ajoutez les personnes via le bouton Invite User dans /admin. SMTP doit être configuré pour qu’elles reçoivent le lien d’invitation. Consultez régulièrement la liste des utilisateurs administrateurs pour vérifier qu’aucun compte inattendu n’est apparu.

Comment sauvegarder mon coffre Vaultwarden ?

Arrêtez brièvement le conteneur et archivez l’intégralité du volume vw-data, ainsi que db.sqlite3, attachments/, sends/, config.json et les fichiers rsa_key.*. Copiez ensuite l’archive hors du serveur, idéalement avec un cron nightly. Copier le fichier SQLite pendant que le serveur fonctionne peut produire un snapshot corrompu. Effectuez donc une sauvegarde à froid. Surtout, restaurez-la une fois dans un conteneur temporaire et connectez-vous pour vérifier que la sauvegarde est valide avant de vous y fier.

Est-il réellement sûr d’auto-héberger mes mots de passe ?

Oui, si vous faites les trois choses présentées dans ce guide : utiliser un vrai HTTPS, désactiver les inscriptions et définir un admin token robuste, puis tester les sauvegardes. Votre coffre est chiffré côté client avec votre mot de passe principal. Même le serveur ne voit donc jamais vos mots de passe en clair. Un db.sqlite3 volé est inutilisable sans ce mot de passe. En contrepartie, les mises à jour correctives et les sauvegardes relèvent désormais de votre responsabilité. C’est pourquoi Fail2ban et la procédure de restauration ne sont pas facultatifs ici. Une fois ces éléments en place, examinons de plus près les points d’attaque réels d’un coffre auto-hébergé constitue l’étape suivante. Les entrées étant chiffrées côté client, il reste surtout à protéger l’admin token et l’archive de sauvegarde.