Vaultwarden zelf hosten op een VPS met Docker

Wat u bouwt

Een wachtwoordbeheerder die volledig uw eigendom is: Vaultwarden draaiend 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 implementeert de Bitwarden-server-API opnieuw in Rust en gebruikt hetzelfde protocol als bitwarden.com. Hierdoor werken de officiële clients ongewijzigd, mits u de server up-to-date houdt (nieuwe client-releases vereisen soms een bijbehorende Vaultwarden-release: 1.37.2 is vereist voor clients 2026.8.0 en nieuwer). Het verbruikt echter slechts ongeveer 100 MB aan RAM in plaats van de officiële stack die uit meerdere containers bestaat.

De installatie zelf bestaat uit een dozijn regels Compose. De drie zaken die er echt toe doen, en die vaak voor problemen zorgen, zijn: TLS moet aanwezig zijn voordat u de web vault laadt, openbare registraties moeten worden uitgeschakeld zodra uw eigen account bestaat, en het datavolume moet worden geback-upt en getest op herstel, omdat die ene map elk wachtwoord bevat dat u bezit.

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, en niet de officiële Bitwarden-stack

Dezelfde clients, maar een fractie van het geheugengebruik. De standaard officiële self-hosted Bitwarden-implementatie wordt uitgebracht als een bundel containers (MSSQL Express, Identity, Api, Admin en meer) en vereist minimaal 2 GB RAM. Bitwarden biedt ook Bitwarden lite aan, een enkele Docker-image die minimaal 200 MB RAM nodig heeft, maar deze is bedoeld voor persoonlijk gebruik en homelabs, niet voor zakelijke doeleinden, en laat het beheer van de database en back-ups volledig aan u over. 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, en omdat het de Bitwarden API nauwkeurig implementeert, blijft uw data uitwisselbaar tussen deze oplossing en bitwarden.com.

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

Waarom HTTPS niet optioneel is

De Bitwarden web vault en browserextensies leiden uw encryptiesleutels in de browser af 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 loopback-adressen zoals http://localhost en http://127.0.0.1. Via onversleuteld http://vault.example.com is dit 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 onmogelijk. De desktop-, mobiele en browserclients voeren hun eigen controle uit tegen een zelfgehoste URL, en bij een http- (of onbereikbaar) eindpunt weigeren ze 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 doen.

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 versterkte 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

Er wordt twee keer om invoer gevraagd en vervolgens wordt een reeks getoond die begint met $argon2id$v=19$.... Dit is de valkuil die mensen vaak een uur kost: Docker Compose behandelt $ als variabele-interpolatie. Als u de hash direct onder environment: in het Compose-bestand plakt, moet u elke $ verdubbelen naar $$. Het quoten van de waarde is prima; het escapen is wat telt:

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

Als u de hash liever in .env bewaart, draait de regel om: laat de enkele $-tekens staan, plaats de gehele waarde tussen enkele aanhalingstekens (ADMIN_TOKEN='$argon2id$v=19$...'), en de bestaande ${ADMIN_TOKEN}-regel in het Compose-bestand leest deze in. Verdubbel nooit de $ in .env. Als u enkele $-tekens in het Compose-bestand zelf laat staan, geeft Compose de waarschuwing The "argon2id" variable is not set en maakt het token leeg, waarna /admin uw correcte wachtwoord afwijst. Voer docker compose up -d uit en bewaar de plaintext die u bij de prompt heeft getypt 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 weergeven, instellingen aanpassen, een test-e-mail versturen en een database-snapshot maken.

Als de pagina in plaats daarvan The admin panel is disabled, please configure the 'ADMIN_TOKEN' variable to enable it weergeeft, is ADMIN_TOKEN leeg of niet ingesteld. Dit schakelt het paneel volledig uit, wat een geldige keuze is als u het nooit nodig heeft. Als de pagina wel laadt maar uw token weigert, raadpleeg dan de valkuil met $$-escaping 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-eindpunt

Vaultwarden logt elke mislukte inlogpoging naar het bestand dat is ingesteld via LOG_FILE; precies wat nodig is voor een brute-force-beveiliging. Als u Fail2ban nog niet gebruikt, vindt u de installatie en basisprincipes in de Fail2ban SSH-hardening handleiding; 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 bevestig 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). Sinds versie 1.37.4 gebruikt Vaultwarden met X-Forwarded-For het meest rechtse adres dat niet in IP_HEADER_TRUSTED_PROXIES staat (standaard local, wat een proxy op dezelfde host of hetzelfde Docker-netwerk dekt). Als er een CDN voor uw proxy staat, vermeld de adressen daarvan dan ook in die lijst. Ten tweede: de juiste iptables-chain hangt af van uw proxy. Bij Traefik als container met gepubliceerde poorten passeert verkeer het FORWARD-pad van Docker, dus de ban moet in DOCKER-USER staan zoals hierboven. Als u echter voor de host-nginx-optie uit Stap 1 heeft gekozen, eindigen 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 poortgebaseerde standaard. Deze jail definieert geen poort, en een ban op alle poorten in DOCKER-USER blokkeert de aanvaller effectief voor elke gepubliceerde service op de server.

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

Het vw-data volume is uw wachtwoordbeheerder. 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 koude 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 correcte manier om dit te verplaatsen is via een dagelijkse restic-back-up naar een andere server of object storage, die het archief versleutelt en dubbele snapshots ontdubbelt. De knop Backup Database in het beheerderspaneel is een handige hot-snapshot van enkel het SQLite-bestand, maar deze laat bijlagen en sleutels achterwege.

Voer nu het ritueel uit dat een echte back-up onderscheidt van een hoopvolle back-up: herstel deze éé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 (of http://127.0.0.1:8888). Omdat loopback-adressen gelden als een veilige context, is crypto.subtle beschikbaar en wordt de kluis hier ontsleuteld via plain http; dit is het enige type adres waar dit is toegestaan. Log in met uw hoofdwachtwoord en bevestig dat uw items aanwezig zijn: als dat zo is, werken uw database, RSA-sleutels en hoofdwachtwoord correct en kunt u binnen enkele minuten op een nieuwe VPS alles opnieuw opbouwen. Stop de container met Ctrl-C en verwijder /tmp/vw-restore. Houd deze tunnelgewoonte aan voor elke andere beheer-UI op de server die nooit direct aan het internet blootgesteld mag worden; op deze manier bereikt u bijvoorbeeld 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 ongedefinieerd 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 is zijn escaping verloren; elke $ moet in het Compose-bestand worden geschreven als $$ (maar gebruik een enkele $ binnen enkele aanhalingstekens in .env), 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 staat 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. Hierdoor werken de officiële desktop-, mobiele, browser- en CLI-clients ermee, terwijl het slechts een fractie van de resources van de officiële stack verbruikt. Het kluisformaat is identiek, waardoor u in beide richtingen kunt migreren door middel van 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 loopback-test. De Bitwarden webkluis en extensies gebruiken de Web Crypto API van de browser, die alleen beschikbaar is in een beveiligde context. Via onbeveiligd http geeft de client de foutmelding Cannot read properties of undefined en kunt u niet inloggen. De enige http-adressen die werken zijn loopback-adressen zoals http://localhost of http://127.0.0.1; dit is de reden waarom de hersteltest in Stap 8 gebruikmaakt van 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 kortstondig 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 cronjob. 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 deze handleiding behandelt: 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 onthult uw gegevens niet zonder dit wachtwoord. De server bevat nog wel account-e-mailadressen en een salted hash afgeleid van elk hoofdwachtwoord, die een aanvaller offline zou kunnen proberen te kraken. Beveilig daarom het databasebestand en elke kopie daarvan. 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 zijn geregeld, is een nadere blik op waar een zelfgehoste kluis daadwerkelijk kan worden aangevallen de nuttige volgende stap. Omdat de gegevens zelf in de client worden versleuteld, is het enige wat overblijft om te verdedigen het admin-token en het back-uparchief.