Vaultwarden zelf hosten op een VPS met Docker

Wat u bouwt

Een wachtwoordmanager die volledig in uw eigen beheer is: Vaultwarden draait in één kleine container achter een reverse proxy die HTTPS afhandelt, waarbij de officiële Bitwarden-apps op uw telefoon, laptop en browser hiernaar verwijzen. Vaultwarden is een herimplementatie van de Bitwarden-server-API in Rust en gebruikt hetzelfde protocol als bitwarden.com. Hierdoor werken alle officiële clients zonder aanpassingen, terwijl de software slechts ongeveer 100 MB aan RAM verbruikt in plaats van de officiële stack die uit meerdere containers bestaat.

De installatie zelf bestaat uit een dozijn regels in Compose. De drie zaken die er werkelijk toe doen, en die voor problemen kunnen zorgen, zijn de volgende: TLS moet aanwezig zijn voordat u de web-vault voor het eerst laadt, openbare registraties moeten worden uitgeschakeld zodra uw eigen account is aangemaakt, en er moet een back-up van de datavolume worden gemaakt die u ook test op herstel, aangezien die ene map al uw wachtwoorden bevat.

Vereisten en de belangrijkste valkuilen

• Een VPS met Docker Engine en de Compose-plugin, op een schone Ubuntu 24.04 KVM-omgeving met root- of sudo-toegang. 512 MB RAM is ruim voldoende; 1 GB is comfortabel. Dit is een van de lichtste services die u kunt draaien; het staat hoog op de shortlist van services die de moeite waard zijn om zelf te hosten. Stem de grootte van de server echter af op andere services die u erop draait: het plaatsen van een zelfgehoste fotobibliotheek zoals PhotoPrism of Immich op dezelfde VPS verhoogt de minimale RAM-behoefte naar enkele gigabytes, terwijl Vaultwarden nauwelijks extra geheugen verbruikt. Dezelfde rekensom geldt voor media-front-ends die u later toevoegt, aangezien het inrichten van een Jellyfin-bibliotheek als een toegankelijke videotheek uit de jaren 90 betekent dat er een extra container continu draait, plus de benodigde rekenkracht voor transcoding binnen hetzelfde budget.
• Een domein met een A-record (en AAAA als u over IPv6 beschikt) dat vault.example.com naar de VPS wijst. Het TLS-certificaat wordt uitgegeven voor deze specifieke naam, dus de DNS-resolutie moet correct werken voordat u begint.
• Poorten 80 en 443 moeten openstaan naar het internet en worden afgehandeld door uw reverse proxy, nooit rechtstreeks door Vaultwarden. Poort 80 wordt uitsluitend gebruikt voor de ACME-certificaatuitdaging en een HTTP-naar-HTTPS-redirect.
• De grootste valkuil vooraf: de Bitwarden-clients weigeren te communiceren met een server die geen HTTPS gebruikt. Er is geen "eerst testen via http", dat pad werkt niet, om een concrete reden die hierna wordt behandeld.

Waarom Vaultwarden in plaats van de officiële Bitwarden-stack

Dezelfde clients, maar een fractie van de belasting. De officiële zelf-gehoste Bitwarden wordt geleverd als een bundel containers (MSSQL, Nginx, Identity, Api, Admin en meer) en vereist ongeveer 2 GB aan RAM. Vaultwarden is een enkel binair bestand dat standaard alles opslaat in een SQLite-database en in ruststand slechts enkele tientallen megabytes verbruikt. Voor één persoon, een gezin of een klein team is dit de logische keuze. Omdat het de Bitwarden API nauwkeurig implementeert, blijft uw data uitwisselbaar tussen Vaultwarden en bitwarden.com.

Wat u inlevert is het grootste deel van de enterprise-functionaliteit: er is geen SCIM-provisioning (hoewel experimentele OpenID Connect SSO is toegevoegd in 1.35.0), en u bent zelf de beheerder. Dit betekent dat het patchen, HTTPS en het maken van back-ups uw verantwoordelijkheid zijn. Deze handleiding behandelt die drie taken.

Waarom HTTPS niet optioneel is

De Bitwarden web vault en browserextensies leiden uw encryptiesleutels af in de browser met behulp van de Web Crypto API (window.crypto.subtle). Browsers stellen crypto.subtle alleen beschikbaar in een veilige context, HTTPS, of het speciale geval van http://localhost. Via onbeveiligd http://vault.example.com is het undefined, dus zodra de app een sleutel probeert af te leiden, treedt er een fout op en toont de console:

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

De pagina blijft hangen of toont een algemene cryptofout en inloggen is niet mogelijk. De desktop-, mobiele en browserclients voeren hun eigen controle uit tegen een zelfgehoste URL, en bij een http- (of onbereikbaar) eindpunt weigeren zij de verbinding met:

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

Beide hebben dezelfde oorzaak: geen geldig HTTPS. Daarom zetten we eerst TLS op en openen we de vault nooit via http, zelfs niet voor een snelle blik.

Stap 1, DNS en de reverse proxy (eerst TLS)

Wijs het record naar uw VPS en controleer of het naar het juiste adres verwijst:

dig +short vault.example.com

De regel die wordt getoond moet het IP-adres van uw VPS zijn. Als deze leeg is of onjuist, corrigeer dan de DNS en wacht tot de TTL is verlopen; certificaatuitgifte mislukt als de naam niet naar het juiste adres verwijst.

Voor de HTTPS-front-end gebruikt deze handleiding Traefik, dat automatisch Let's Encrypt-certificaten uitgeeft en vernieuwt en direct in Compose past. Als u dit nog niet gebruikt, volg dan eerst de Traefik reverse proxy en automatische TLS-configuratie; dit creëert een extern Docker-netwerk (proxy hieronder) en een ACME-resolver (letsencrypt) waar de Vaultwarden-service aan wordt gekoppeld. Een standaard nginx met een handmatig uitgegeven certificaat werkt vanuit het perspectief van Vaultwarden identiek.

Geeft u de voorkeur aan nginx en Certbot in plaats van Traefik? Plaats Vaultwarden op 127.0.0.1:8080 (voeg ports: ["127.0.0.1:8080:80"] toe aan de service en verwijder de Traefik-labels), geef vervolgens een certificaat uit en proxy het verkeer hiernaartoe. Het gedeelte over certificaten wordt behandeld in Let's Encrypt-certificaten uitgeven met Certbot en nginx. Het cruciale extra onderdeel is de WebSocket-upgrade op het notificatiepad:

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";
    }
}

Let op de regel X-Real-IP; deze zorgt ervoor dat Fail2ban later de echte aanvaller ziet in plaats van 127.0.0.1. Al het overige in deze handleiding is identiek, ongeacht of Traefik of nginx als front-end fungeert.

Stap 2, het Compose-bestand

Maak eerst de projectmap aan. Deze handleiding gebruikt /opt/vaultwarden, wat de Compose-projectnaam, en daarmee het datavolume, vaultwarden_vw-data voorspelbaar maakt; de Fail2ban- en back-upstappen hieronder zijn afhankelijk van die exacte naam.

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

Maak een .env aan voor het admin-geheim en het Compose-bestand in die map.

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

Genereer dat token met openssl rand -base64 48 en plak het erin. (Een sterkere gehashte vorm wordt hierna behandeld; een lange willekeurige reeks is prima om mee te beginnen.)

# 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

Twee aspecten van dit bestand vormen de kern van het ontwerp. Er is geen ports:-mapping, waardoor Vaultwarden alleen bereikbaar is via Traefik en diens TLS; het publiceren van de poort op de host is de manier waarop mensen per ongeluk de vault via http aanbieden. En DOMAIN moet de volledige publieke HTTPS-URL zijn: deze is verwerkt in bijlagelinks, WebAuthn 2FA en het notificatie-eindpunt, dus een onjuiste of http-waarde verstoort deze functies, zelfs als de site laadt. De latest-tag is een bewuste uitzondering op de gebruikelijke regel om nooit latest te gebruiken; Vaultwarden brengt zijn stabiele releases uit als een enkele rolling image, met :testing als het aparte pre-releasekanaal, dus update bewust en lees de release notes door voordat u een pull uitvoert. Die uitzondering is echter beperkt: de meeste langlopende containers kunnen beter worden vastgezet op een exacte tag, wat een altijd actieve agent die op dezelfde VPS wordt gehost voorspelbaar houdt bij reboots en pulls.

Start de container en monitor het logbestand:

docker compose up -d
docker compose logs -f vaultwarden

Een correcte start eindigt met een regel zoals Rocket has launched from http://0.0.0.0:80. Geef Traefik enkele seconden de tijd om het certificaat op te halen en laad vervolgens https://vault.example.com; u zou de Bitwarden web vault moeten zien met een geldig slotje en zonder certificaatwaarschuwing.

Stap 3, een sterk ADMIN_TOKEN en de $$ valkuil

ADMIN_TOKEN beveiligt /admin, het paneel dat elke gebruiker en instelling op uw instantie kan inzien; behandel dit dus als een root-wachtwoord. Er zijn twee manieren om dit te configureren.

De eenvoudige vorm is de willekeurige reeks die u al heeft gegenereerd met openssl rand -base64 48. Omdat base64 nooit een $ bevat, kan deze direct in .env worden geplaatst zonder dat escapen nodig is.

De robuuste vorm is een Argon2 PHC-hash, waardoor het plaintext-token nooit op schijf wordt opgeslagen. Genereer er een met dezelfde image:

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

U wordt tweemaal om invoer gevraagd en er wordt een reeks getoond die begint met $argon2id$v=19$.... Hier is de valkuil die mensen vaak een uur kost: Docker Compose behandelt $ als variabele-interpolatie, dus u moet elke $ verdubbelen naar $$ wanneer u de hash in het Compose-bestand plakt. Plaats deze direct onder environment:, niet via .env, en zet er geen aanhalingstekens omheen:

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

Als u de enkele $-tekens laat staan, geeft Compose de waarschuwing The "argon2id" variable is not set en wordt het token leeggemaakt, waarna /admin uw correcte wachtwoord weigert. Voer docker compose up -d uit en bewaar de plaintext die u bij de prompt heeft ingevoerd in uw eigen wachtwoordbeheerder.

Stap 4, registreer uw account en sluit de toegang af

Open met SIGNUPS_ALLOWED: "true" de URL https://vault.example.com, klik op Create account en registreer u met uw e-mailadres en een sterk hoofdwachtwoord. Dit hoofdwachtwoord kan nooit worden hersteld; er is geen resetmogelijkheid, dus sla het eerst op een duurzame locatie op.

Sluit nu de toegang af. Bewerk het Compose-bestand zodat registraties zijn uitgeschakeld:

      SIGNUPS_ALLOWED: "false"

Pas de wijzigingen opnieuw toe met docker compose up -d. Dit is geen beveiligingsmaatregel die u kunt uitstellen. Als de registratie open blijft staan, kan iedereen die de URL vindt — en crawlers doen dat — een account aanmaken op uw server. Zij kunnen uw eigen kluis niet inzien, maar zij verbruiken wel resources en veranderen uw privé-instantie in een openbare dienst. Het teken dat u de registratie open heeft laten staan: /admin toont accounts die u niet zelf heeft aangemaakt.

Gebruik de knop Invite User in /admin om later familieleden of teamgenoten toe te voegen zonder openbare registraties opnieuw in te schakelen; voor dit pad moet SMTP zijn geconfigureerd zodat de genodigde de link ontvangt.

Stap 5, toegang tot /admin

Navigeer naar https://vault.example.com/admin en voer het plaintext admin-token in (de willekeurige reeks of het wachtwoord dat u heeft gehasht, niet de hash zelf). Binnen de interface kunt u gebruikers beheren, instellingen aanpassen, een test-e-mail versturen en een database-snapshot maken.

Als de pagina 404 Not Found teruggeeft, is ADMIN_TOKEN leeg of niet ingesteld. Dit schakelt het paneel volledig uit, wat een geldige keuze is als u het niet nodig heeft. Als de pagina wel laadt maar uw token weigert, raadpleeg dan de $$-escape-val in de onderstaande lijst met fouten. Token vergeten? Er is geen hersteloptie; bewerk .env of het Compose-bestand, stel een nieuw token in en voer docker compose up -d uit.

Stap 6, de Bitwarden-clients verbinden

Elke officiële client kan verbinding maken met een zelfgehoste server. Installeer de Bitwarden-desktop-, mobiele of browserclient via de gebruikelijke app-stores; u heeft geen speciale Vaultwarden-build nodig.

Open vóór het inloggen het instellingen-tandwiel op het inlogscherm (gelabeld als Self-hosted of Region → Self-hosted), stel de Server URL in op https://vault.example.com en sla deze op. Log vervolgens in met het e-mailadres en het hoofdwachtwoord dat u heeft geregistreerd; de client zou direct verbinding moeten maken en aanbieden om inloggegevens in te vullen en op te slaan.

Als een client This is not a recognized Bitwarden server. You may need to check with your provider or update your server. toont, is de URL onjuist, wordt http gebruikt of is het certificaat niet vertrouwd. Controleer eerst of https://vault.example.com correct laadt in een browser. Trage updates op andere apparaten worden veroorzaakt door WebSocket-push, wat hieronder wordt behandeld.

Stap 7, een Fail2ban-jail voor het inlog-endpoint

Vaultwarden logt elke mislukte inlogpoging naar het bestand dat is ingesteld via LOG_FILE; precies wat nodig is voor bescherming tegen brute-force-aanvallen. Als u nog geen Fail2ban gebruikt, vindt u de installatie en basisprincipes in de handleiding voor het beveiligen van SSH met Fail2ban; hier voegen we één jail toe voor de vault.

Zoek eerst op waar het named volume zich op de host bevindt, zodat Fail2ban het logbestand kan lezen:

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

Dit geeft een resultaat zoals /var/lib/docker/volumes/vaultwarden_vw-data/_data; het logbestand bevindt zich op vaultwarden.log daarbinnen. Maak het filter aan:

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

En de 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

Herlaad met sudo systemctl restart fail2ban en controleer met sudo fail2ban-client status vaultwarden.

Drie Docker-details bepalen of dit daadwerkelijk bescherming biedt. Ten eerste: als het logbestand bij elke mislukte poging IP: 127.0.0.1 of het adres van uw proxy toont, bant Vaultwarden de proxy. Stel IP_HEADER in op de header die uw proxy daadwerkelijk meestuurt (X-Forwarded-For voor Traefik, X-Real-IP voor het nginx-blok hierboven, CF-Connecting-IP achter Cloudflare). Ten tweede: de juiste iptables-chain hangt af van uw proxy. Als Traefik als container met gepubliceerde poorten draait, verloopt het verkeer via het FORWARD-pad van Docker, dus moet de ban in DOCKER-USER staan zoals hierboven. Als u echter koos voor de host-nginx-optie uit Stap 1, eindigen de verbindingen bij nginx op de INPUT-chain van de host en ziet een DOCKER-USER-ban ze nooit; verwijder in dat geval de chain = DOCKER-USER-regel zodat Fail2ban de standaard INPUT-chain gebruikt. Ten derde: gebruik banaction = iptables-allports in plaats van de standaard op basis van poorten. Deze jail definieert geen poort, en een ban voor alle poorten in DOCKER-USER blokkeert de aanvaller effectief voor elke gepubliceerde service op de server.

Stap 8, maak een back-up van de vault en voer vervolgens een herstel uit

Het vw-data volume is uw wachtwoordmanager. Het bevat db.sqlite3 (elk item), de attachments/ en sends/ mappen, de rsa_key.* bestanden die inlogsessies ondertekenen, en config.json vanuit het beheerderspaneel. Een back-up die een van deze onderdelen overslaat, faalt op het moment dat u deze nodig heeft.

Het kopiëren van db.sqlite3 terwijl Vaultwarden schrijft, kan leiden tot een half geschreven, corrupt bestand. Maak daarom een cold snapshot; de downtime bedraagt slechts enkele seconden:

#!/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

Voer dit dagelijks uit via cron en kopieer de .tgz buiten de server; een back-up die alleen op de server staat die u beveiligt, is geen back-up. De juiste manier om dit te verplaatsen is een dagelijkse restic-back-up naar een andere server of object storage, wat het archief versleutelt en dubbele snapshots voor u ontdubbelt. De knop Backup Database in het beheerderspaneel is een handige hot snapshot van alleen het SQLite-bestand, maar deze slaat bijlagen en sleutels over.

Voer nu het ritueel uit dat een echte back-up onderscheidt van een hoopvolle poging: herstel de back-up één keer en bewijs dat het werkt:

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

Maak vanaf uw laptop een tunnel naar de server met ssh -L 8888:127.0.0.1:8888 you@your-vps en open http://localhost:8888. Omdat localhost een veilige context is, is crypto.subtle beschikbaar en wordt de vault hier ontsleuteld via plain http, de enige plek waar dit is toegestaan. Log in met uw hoofdwachtwoord en bevestig dat uw items aanwezig zijn: als dat zo is, zijn uw database, RSA-sleutels en hoofdwachtwoord correct verwerkt en kunt u binnen enkele minuten herbouwen op een nieuwe VPS. Stop de container met Ctrl-C en verwijder /tmp/vw-restore. Houd deze tunnelgewoonte aan voor elke andere admin-UI op de server die nooit direct aan het internet blootgesteld mag worden; op deze manier bereikt u ook een zelfgehoste open-kritt beveiligingsscanner op poort 5173.

Foutmodi en de bijbehorende meldingen

Cannot read properties of undefined (reading 'importKey') in de browserconsole. De vault is geladen via http, waardoor crypto.subtle niet gedefinieerd is; benader deze alleen via https:// en voeg de HTTP-naar-HTTPS-redirect toe bij de proxy.

This is not a recognized Bitwarden server... in een client. De Server URL is http, bevat een typefout of het certificaat is niet vertrouwd; controleer of https://vault.example.com een geldig slotje toont en voer de URL opnieuw in bij de self-hosted instellingen van de client.

/admin weigert het juiste wachtwoord. De Argon2-hash heeft zijn escaping verloren; elke $ moet in Compose worden geschreven als $$, of u heeft de hash ingevoerd in plaats van de plaintext die deze vertegenwoordigt.

Trage synchronisatie tussen apparaten; console toont WebSocket connection to 'wss://vault.example.com/notifications/hub' failed. De proxy stuurt de Upgrade/Connection-headers niet door; Traefik doet dit automatisch, maar voor nginx zijn de twee upgrade-regels uit stap 1 vereist. De vault werkt nog steeds, maar synchroniseert alleen bij het openen. De oude toegewezen poort 3012 is sinds v1.31.0 komen te vervallen, dus een aparte WebSocket-route is niet nodig.

Fail2ban meldt een ban, maar de aanvaller blijft verbinding maken. Het systeem bant 127.0.0.1 omdat IP_HEADER onjuist is, of de ban bevindt zich in de verkeerde iptables-chain; stel chain = DOCKER-USER en banaction = iptables-allports in.

Upgrades

Haal de nieuwe image op en maak de container opnieuw aan; het named volume en al uw data blijven behouden:

docker compose pull
docker compose up -d

Vaultwarden brengt regelmatig nieuwe versies uit. Monitor de release notes van het project in plaats van een specifieke patchversie vast te pinnen, aangezien sommige releases migratie-instructies bevatten. Maak een nieuwe back-up voordat u een grote update uitvoert; u kunt een rollback uitvoeren door het tar-bestand terug te zetten in een nieuw volume.

FAQ

Is Vaultwarden hetzelfde als Bitwarden?

Het is een compatibele, onafhankelijke server, niet de officiële versie. Vaultwarden implementeert de Bitwarden server-API opnieuw in Rust, waardoor de officiële desktop-, mobiele, browser- en CLI-clients er allemaal mee werken, met een fractie van de systeembronnen van de officiële stack. Het formaat van de kluis is identiek, dus u kunt in beide richtingen migreren door te exporteren en importeren.

Heb ik echt HTTPS nodig, of kan ik het via http op mijn LAN draaien?

U heeft HTTPS nodig voor alles behalve een localhost test. De Bitwarden webkluis en extensies gebruiken de Web Crypto API van de browser, die alleen beschikbaar is in een beveiligde context. Via onversleuteld http geeft de client daarom Cannot read properties of undefined en kunt u niet inloggen. Het enige http-adres dat werkt is http://localhost; daarom gebruikt de hersteltest in Stap 8 een SSH-tunnel.

Hoe voorkom ik dat vreemden zich registreren op mijn server?

Stel SIGNUPS_ALLOWED: "false" in het Compose-bestand in en voer docker compose up -d uit, direct nadat u uw eigen account heeft aangemaakt. Voeg vanaf dat moment nieuwe personen toe via de knop Invite User in /admin. Hiervoor moet SMTP geconfigureerd zijn zodat zij de uitnodigingslink ontvangen. Controleer regelmatig de lijst met beheerdersgebruikers om te bevestigen dat er geen onverwachte accounts zijn verschenen.

Hoe maak ik een back-up van mijn Vaultwarden-kluis?

Stop de container kort en archiveer het volledige vw-data volume, db.sqlite3, attachments/, sends/, config.json en de rsa_key.* bestanden. Kopieer het archief vervolgens van de server, bij voorkeur via een dagelijkse cron-taak. Het kopiëren van het actieve SQLite-bestand terwijl de server draait, brengt het risico op een corrupt snapshot met zich mee; maak de back-up daarom terwijl de server gestopt is. Het belangrijkste is dat u de back-up eenmaal herstelt naar een testcontainer en inlogt, zodat u zeker weet dat de back-up bruikbaar is voordat u ervan afhankelijk bent.

Is het daadwerkelijk veilig om mijn wachtwoorden zelf te hosten?

Ja, mits u de drie zaken uitvoert die in deze handleiding worden behandeld: echte HTTPS, gesloten registraties in combinatie met een sterk admin-token, en geteste back-ups. Uw kluis wordt aan de clientzijde versleuteld met uw hoofdwachtwoord, waardoor zelfs de server uw wachtwoorden nooit in leesbare vorm ziet; een gestolen db.sqlite3 is zonder dit wachtwoord waardeloos. De keerzijde is dat het patchen en maken van back-ups nu uw verantwoordelijkheid is; daarom zijn Fail2ban en het herstelritueel hier niet optioneel. Zodra deze zaken op orde zijn, is een nadere blik op waar een zelfgehoste kluis daadwerkelijk aangevallen kan worden de nuttige volgende stap. Omdat de gegevens zelf in de client worden versleuteld, blijft alleen het admin-token en het back-uparchief over om te verdedigen.