Vaultwarden zelf hosten op een VPS met Docker Compose

11 min leestijd·Matthieu·self-hostingfail2bansecuritypassword-managerdocker-composedockervaultwarden|

Zet een geharde Vaultwarden-wachtwoordmanager op je VPS neer. Docker Compose met read-only containers, fail2ban, SMTP voor 2FA, back-up en herstel, en noodtoegang.

Vaultwarden bewaart al je wachtwoorden. Een slordig deployment is erger dan helemaal geen deployment. Deze tutorial zet Vaultwarden op een VPS op met geharde Docker-containers, fail2ban, SMTP voor tweefactorauthenticatie en een back-up- en herstelprocedure.

We gaan ervan uit dat Docker Engine en een reverse proxy (Nginx of Caddy) al draaien op je server. Zo niet, begin dan met Docker in productie op een VPS: wat er misgaat en hoe je het oplost en Nginx configureren als reverse proxy.

Wat is Vaultwarden en wat is het verschil met Bitwarden?

Vaultwarden is een herimplementatie in Rust van de Bitwarden-server-API. Het draait als één Docker-container, gebruikt standaard SQLite, verbruikt ongeveer 50 MB RAM in rust en is volledig compatibel met alle officiële Bitwarden-clients (browserextensies, mobiele apps, desktop, CLI). Het officiële zelfgehoste Bitwarden-deployment vereist meer dan 11 containers en minstens 4 GB RAM.

Vaultwarden Bitwarden zelfgehost
Taal Rust C# (.NET)
Containers 1 11+
RAM (rust) ~50 MB ~2-4 GB
Database SQLite (standaard), MySQL, PostgreSQL MSSQL (vereist)
Bitwarden-clientondersteuning Volledig Volledig
SSO (OpenID Connect) Sinds versie 1.35.0 Alleen Enterprise-plan
Officiële ondersteuning Community Bitwarden Inc.
Licentie AGPL-3.0 Propriëtair (SSPL voor server)

Vaultwarden heette voorheen bitwarden_rs. Als je die naam in oudere handleidingen tegenkomt, gaat het om hetzelfde project.

Hoe deploy ik Vaultwarden met Docker Compose op een VPS?

Maak een mappenstructuur voor Vaultwarden-data en -configuratie. Alle persistente data staat in één map waar je later een back-up van maakt.

mkdir -p /opt/vaultwarden/data
cd /opt/vaultwarden

Genereer een argon2-gehasht admin-token. Sla het admin-token nooit op in platte tekst.

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

Het commando vraagt tweemaal om een wachtwoord en toont vervolgens een argon2id PHC-string:

Generate an Argon2id PHC string using the 'bitwarden' preset:

Password:
Confirm Password:
ADMIN_TOKEN='$argon2id$v=19$m=65540,t=3,p=4$S2mMOA8VnTtIOb3J8Gj9Jw$9cZ0YIKmGxfWEqSMKFMbORkBiW7hMGCls3SXAFXSIVE'

Bewaar die string. Je hebt hem nodig in het omgevingsbestand.

Maak het secretsbestand met beperkte rechten:

touch /opt/vaultwarden/.env
chmod 600 /opt/vaultwarden/.env

Bewerk /opt/vaultwarden/.env met je waarden:

DOMAIN=https://vault.example.com
ADMIN_TOKEN='$argon2id$v=19$m=65540,t=3,p=4$your-hash-here'

SIGNUPS_ALLOWED=true
INVITATIONS_ALLOWED=true
EMERGENCY_ACCESS_ALLOWED=true
ORG_CREATION_USERS=all

SHOW_PASSWORD_HINT=false
IP_HEADER=X-Real-IP
LOG_FILE=/data/vaultwarden.log
LOG_LEVEL=warn

SMTP_HOST=smtp.example.com
SMTP_FROM=vault@example.com
SMTP_PORT=587
SMTP_SECURITY=starttls
SMTP_USERNAME=vault@example.com
SMTP_PASSWORD=your-smtp-password

SHOW_PASSWORD_HINT=false voorkomt dat hints uitlekken naar iedereen die een gebruikersnaam kent. IP_HEADER=X-Real-IP vertelt Vaultwarden om het client-IP te lezen uit de header van je reverse proxy, nodig zodat fail2ban het juiste adres blokkeert.

Maak nu het Compose-bestand.

Hoe hard ik de Vaultwarden Docker-container?

Het onderstaande Compose-bestand pinned de imageversie, verwijdert alle Linux-capabilities, schakelt een read-only root-bestandssysteem in, blokkeert privilege-escalatie en stelt geheugenlimieten in. Dit zijn de standaardinstellingen van deze handleiding, geen optionele toevoegingen.

Maak /opt/vaultwarden/compose.yaml:

services:
  vaultwarden:
    image: vaultwarden/server:1.35.4
    container_name: vaultwarden
    restart: unless-stopped
    env_file: .env
    user: "1000:1000"
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    read_only: true
    tmpfs:
      - /tmp
    volumes:
      - ./data:/data
    ports:
      - "127.0.0.1:8080:80"
    deploy:
      resources:
        limits:
          memory: 512M
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:80/alive"]
      interval: 30s
      timeout: 5s
      retries: 3
  • user: "1000:1000" draait het proces als niet-rootgebruiker in de container. Je moet het eigenaarschap van de datamap hierop afstemmen: chown -R 1000:1000 /opt/vaultwarden/data.
  • cap_drop: ALL verwijdert alle Linux-capabilities. Vaultwarden heeft er geen nodig omdat het luistert op poort 80 in de container (een onbevoegde poort in deze context, aangezien Docker de mapping regelt).
  • read_only: true voorkomt dat de container ergens schrijft behalve in expliciet gemounte volumes en tmpfs. Als iets Vaultwarden compromitteert, kan het niet naar het containerbestandssysteem schrijven.
  • ports: "127.0.0.1:8080:80" bindt alleen aan localhost. De reverse proxy handelt extern verkeer af. Stel Vaultwarden nooit rechtstreeks bloot aan het internet.
  • deploy.resources.limits.memory: 512M voorkomt dat een op hol geslagen proces al het server-RAM opeet. Vaultwarden gebruikt ~50 MB in rust en ~100-150 MB onder belasting. 512 MB biedt ruim voldoende marge.

Corrigeer het eigenaarschap van de datamap en start de container:

chown -R 1000:1000 /opt/vaultwarden/data
docker compose up -d

[+] Running 1/1
 ✔ Container vaultwarden  Started

Controleer de containerstatus:

docker compose ps

NAME          IMAGE                       COMMAND       SERVICE       CREATED          STATUS                    PORTS
vaultwarden   vaultwarden/server:1.35.4   "/start.sh"   vaultwarden   Up 30 seconds (healthy)   127.0.0.1:8080->80/tcp

De status (healthy) betekent dat de healthcheck geslaagd is. Bekijk de logs op opstartfouten:

docker compose logs --tail 20

De logs tonen Vaultwarden startend op poort 80 in de container, zonder fouten.

Reverse-proxyconfiguratie

Je reverse proxy stuurt HTTPS-verkeer door naar 127.0.0.1:8080. Hier is een minimaal Nginx-serverblok:

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

    ssl_certificate /etc/letsencrypt/live/vault.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/vault.example.com/privkey.pem;

    client_max_body_size 525M;
    server_tokens off;

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

client_max_body_size 525M staat uploads van bestandsbijlagen toe tot de Bitwarden-limiet. server_tokens off verbergt de Nginx-versie in responses, omdat versie-onthulling aanvallers helpt bij het richten op bekende kwetsbaarheden.

Sinds Vaultwarden 1.29.0 wordt WebSocket-verkeer via dezelfde poort als HTTP bediend. Een apart /notifications/hub-proxypad is niet nodig. Als je WEBSOCKET_ENABLED in oudere tutorials ziet, negeer het. Die variabele werd deprecated in 1.29.0 en verwijderd in 1.31.0.

Voor details over Nginx-configuratie, zie Nginx configureren als reverse proxy en Let's Encrypt SSL/TLS instellen voor Nginx op Debian 12 en Ubuntu 24.04.

Hoe configureer ik SMTP-e-mail voor Vaultwarden?

Vaultwarden heeft SMTP nodig om e-mailverificatiecodes, 2FA-setupmails, organisatie-uitnodigingen en noodtoegangsnotificaties te versturen. Zonder SMTP werken functies als registratie via uitnodiging, e-mail-2FA en noodtoegang niet.

De belangrijkste omgevingsvariabelen zijn SMTP_HOST, SMTP_PORT, SMTP_SECURITY, SMTP_USERNAME, SMTP_PASSWORD en SMTP_FROM. Gebruik SMTP_PORT=587 met SMTP_SECURITY=starttls voor de meeste providers, of SMTP_PORT=465 met SMTP_SECURITY=force_tls voor impliciet TLS.

Deze variabelen staan al in het .env-bestand hierboven. Test na het starten van de container de e-mailbezorging: log in op de webkluis op https://vault.example.com, maak je account aan, ga naar Settings > Security > Two-step Login en schakel e-mail-2FA in. Als je de verificatiecode ontvangt, werkt SMTP.

Bekijk de logs als e-mail mislukt:

docker compose logs | grep -i smtp

Veelvoorkomende problemen:

  • Authenticatie mislukt: controleer SMTP_USERNAME en SMTP_PASSWORD. Speciale tekens in het wachtwoord vereisen mogelijk enkele aanhalingstekens in het .env-bestand.
  • Verbinding geweigerd op poort 587: sommige VPS-providers blokkeren standaard uitgaande poorten 25 en 587. Controleer bij je provider of probeer poort 465 met force_tls.
  • Certificaatfout: het TLS-certificaat van de SMTP-server moet geldig zijn. Zelfondertekende certificaten vereisen SMTP_ACCEPT_INVALID_CERTS=true (niet aanbevolen voor productie).
Variabele Doel Voorbeeld
SMTP_HOST Hostname van de mailserver smtp.example.com
SMTP_PORT Verbindingspoort 587
SMTP_SECURITY TLS-methode starttls of force_tls
SMTP_FROM Afzenderadres vault@example.com
SMTP_USERNAME Authenticatie-gebruikersnaam vault@example.com
SMTP_PASSWORD Authenticatie-wachtwoord (opgeslagen in .env, chmod 600)
SMTP_AUTH_MECHANISM Authenticatietype (optioneel) Login

Hoe beveilig ik het Vaultwarden-adminpaneel?

Het adminpaneel op /admin laat je gebruikers beheren, de configuratie bekijken en instellingen wijzigen. Het is beschermd door het ADMIN_TOKEN dat je eerder genereerde. De argon2-hash betekent dat het ruwe token nooit in je .env-bestand wordt opgeslagen. Zelfs als iemand het bestand leest, krijgt hij een hash, geen wachtwoord.

Na de eerste configuratie (account aanmaken, SMTP instellen, registraties uitschakelen) heb je twee opties:

Optie 1: Het adminpaneel volledig uitschakelen. Verwijder of becommentarieer ADMIN_TOKEN in .env en herstart:

docker compose down && docker compose up -d

Zonder ingesteld ADMIN_TOKEN geeft het /admin-endpoint een 404 terug. Dit is de veiligste optie voor single-user deployments.

Optie 2: Toegang beperken via de reverse proxy. Houd het adminpaneel actief maar blokkeer externe toegang:

location /admin {
    allow 127.0.0.1;
    deny all;

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

Open het adminpaneel via een SSH-tunnel wanneer nodig:

ssh -L 8888:127.0.0.1:443 user@your-vps

Open vervolgens https://127.0.0.1:8888/admin in je browser.

Openbare registratie uitschakelen

Zodra je account bestaat, schakel open registraties uit. Bewerk /opt/vaultwarden/.env:

SIGNUPS_ALLOWED=false

Herstart de container:

cd /opt/vaultwarden && docker compose down && docker compose up -d

Nieuwe gebruikers kunnen nog steeds toetreden via organisatie-uitnodigingen als INVITATIONS_ALLOWED=true. Zo kun je teamleden toevoegen zonder de registratie voor iedereen open te zetten.

Hoe stel ik fail2ban in voor Vaultwarden in Docker?

Fail2ban monitort het logbestand van Vaultwarden op mislukte inlogpogingen en blokkeert overtredende IP's. Omdat Vaultwarden in Docker draait, moet de blokkeerregel de iptables-keten DOCKER-USER targeten. Standaard INPUT-ketenregels hebben geen effect op Docker-gerouteerd verkeer.

De Vaultwarden-container schrijft logs naar /opt/vaultwarden/data/vaultwarden.log (gemapt vanaf /data/vaultwarden.log in de container) omdat we LOG_FILE=/data/vaultwarden.log in de omgeving hebben ingesteld.

Voor een gedetailleerde fail2ban-installatiehandleiding, zie Fail2Ban installeren en configureren op een Linux VPS.

Loginfilter

Maak /etc/fail2ban/filter.d/vaultwarden.local:

[INCLUDES]
before = common.conf

[Definition]
failregex = ^.*?Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$
ignoreregex =

Adminpaneelfilter

Maak /etc/fail2ban/filter.d/vaultwarden-admin.local:

[INCLUDES]
before = common.conf

[Definition]
failregex = ^.*?Invalid admin token\. IP: <ADDR>.*$
ignoreregex =

Jailconfiguratie

Maak /etc/fail2ban/jail.d/vaultwarden.local:

[vaultwarden]
enabled = true
port = http,https
filter = vaultwarden
action = iptables-allports[name=vaultwarden, chain=DOCKER-USER]
logpath = /opt/vaultwarden/data/vaultwarden.log
maxretry = 3
bantime = 14400
findtime = 14400
backend = pyinotify

[vaultwarden-admin]
enabled = true
port = http,https
filter = vaultwarden-admin
action = iptables-allports[name=vaultwarden-admin, chain=DOCKER-USER]
logpath = /opt/vaultwarden/data/vaultwarden.log
maxretry = 3
bantime = 14400
findtime = 14400
backend = pyinotify
Parameter Waarde Waarom
chain DOCKER-USER Docker omzeilt de INPUT-keten. Regels moeten in DOCKER-USER staan om containerverkeer te beïnvloeden.
maxretry 3 Drie mislukte pogingen triggeren een blokkade. Legitieme gebruikers falen zelden meer dan twee keer.
bantime 14400 Blokkade van vier uur. Lang genoeg om brute-force te ontmoedigen, kort genoeg om een legitieme gebruiker niet permanent buiten te sluiten.
findtime 14400 Telt mislukkingen binnen een venster van vier uur.
backend pyinotify Bestandsgebaseerde logmonitoring. De standaard systemd-backend kan geen Docker-containerlogbestanden lezen.

Herstart fail2ban en controleer de jail:

systemctl restart fail2ban
fail2ban-client status vaultwarden

Status for the jail: vaultwarden
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- File list:        /opt/vaultwarden/data/vaultwarden.log
`- Actions
   |- Currently banned: 0
   |- Total banned:     0
   `- Banned IP list:

Test de regex tegen het werkelijke logformaat:

fail2ban-regex /opt/vaultwarden/data/vaultwarden.log /etc/fail2ban/filter.d/vaultwarden.local

Als er nog geen mislukte logins bestaan, toont de output 0 matched. Dat is verwacht. Veroorzaak een mislukte login via de webkluis en voer opnieuw uit om te bevestigen dat de regex matcht.

Hoe verbind ik browserextensies en mobiele apps met Vaultwarden?

Alle officiële Bitwarden-clients werken met Vaultwarden. De enige wijziging is ze naar je server-URL wijzen in plaats van naar bitwarden.com.

Browserextensie (Chrome, Firefox, Safari):

  1. Installeer de Bitwarden-extensie vanuit de add-onwinkel van je browser
  2. Klik op het inlogscherm op het tandwielpictogram (of "Self-hosted" in nieuwere versies)
  3. Stel Server URL in op https://vault.example.com
  4. Sla op en log in met je inloggegevens

Mobiele app (iOS, Android):

  1. Installeer de Bitwarden-app vanuit de App Store of Google Play
  2. Tik voor het inloggen op het tandwielpictogram op het inlogscherm
  3. Stel Server URL in op https://vault.example.com
  4. Sla op en log in

Desktop-app:

  1. Klik voor het inloggen op het tandwielpictogram
  2. Stel Server URL in op https://vault.example.com

CLI:

bw config server https://vault.example.com
bw login

Alle clients synchroniseren via je Vaultwarden-instantie. Kluisdata raakt nooit de servers van Bitwarden.

Hoe stel ik noodtoegang in bij Vaultwarden?

Noodtoegang (Emergency Access) laat een vertrouwd contact je kluis openen of overnemen als je onbereikbaar wordt. SMTP moet geconfigureerd zijn omdat Vaultwarden tijdens het proces notificatie-e-mails verstuurt.

Bevestig dat de functie is ingeschakeld in je .env:

EMERGENCY_ACCESS_ALLOWED=true

Een vertrouwd contact instellen:

  1. Log in op de webkluis op https://vault.example.com
  2. Ga naar Settings > Emergency Access
  3. Klik op Add emergency contact
  4. Voer het e-mailadres in van de vertrouwde persoon (die moet een account hebben op je Vaultwarden-instantie)
  5. Kies het toegangsniveau:
    • View: het contact kan je kluisitems bekijken (alleen-lezen)
    • Takeover: het contact kan je hoofdwachtwoord resetten en volledige controle overnemen
  6. Stel de wachttijd in (1 tot 90 dagen). Dit is de vertraging tussen het verzoek van het contact en het daadwerkelijk krijgen van toegang. Je ontvangt een e-mailnotificatie en kunt het verzoek gedurende deze periode afwijzen.
  7. Klik op Save

Het vertrouwde contact ontvangt een uitnodigingsmail. Na acceptatie verschijnt het als wachtend noodcontact. De wachttijd werkt als een veiligheidsmechanisme: als je niet reageert binnen het geconfigureerde aantal dagen, wordt toegang automatisch verleend.

Voor een persoonlijke kluis is 7 dagen wachttijd met View-toegang redelijk. Voor gedeelde teaminfrastructuur kun je kortere wachttijden overwegen.

Hoe maak ik een back-up en herstel ik een Vaultwarden-instantie?

Vaultwarden slaat alles op in de /data-map: de SQLite-database (db.sqlite3), bestandsbijlagen, iconcache en configuratie. Een goede back-up vangt dit alles consistent op.

De SQLite-database moet worden geback-upt met sqlite3 .backup, niet door het bestand direct te kopiëren. Het kopiëren van een actief SQLite-bestand kan een corrupte back-up opleveren als er tijdens het kopiëren wordt geschreven. Het .backup-commando maakt een consistente snapshot.

Wat back-uppen Locatie Methode Frequentie
SQLite-database /opt/vaultwarden/data/db.sqlite3 sqlite3 .backup Dagelijks
Bijlagen /opt/vaultwarden/data/attachments/ rsync of cp -a Dagelijks
Iconcache /opt/vaultwarden/data/icon_cache/ Overslaan (wordt automatisch geregenereerd) -
Omgevingsbestand /opt/vaultwarden/.env cp Bij wijziging
Compose-bestand /opt/vaultwarden/compose.yaml cp Bij wijziging

Back-upscript

Voor geautomatiseerde back-ups gebruikt het script age met een ontvangersleutelbestand. Dit vermijdt interactieve wachtwoordzinprompts zodat het script vanuit cron kan draaien.

Genereer een sleutelpaar (eenmalig):

apt install age
age-keygen -o /opt/vaultwarden/backup-key.txt
chmod 600 /opt/vaultwarden/backup-key.txt

Het commando toont de publieke sleutel op stdout. Sla die op in een ontvangerbestand:

age-keygen -y /opt/vaultwarden/backup-key.txt > /opt/vaultwarden/backup-key.pub

Bewaar een kopie van backup-key.txt (de privésleutel) buiten de server. Je hebt hem nodig om back-ups te ontsleutelen. Als je deze sleutel verliest, zijn je versleutelde back-ups onherstelbaar.

Maak /opt/vaultwarden/backup.sh:

#!/bin/bash
set -euo pipefail

BACKUP_DIR="/opt/vaultwarden/backups"
DATA_DIR="/opt/vaultwarden/data"
DATE=$(date +%Y-%m-%d_%H%M)
BACKUP_FILE="${BACKUP_DIR}/vaultwarden-${DATE}.tar"
RECIPIENT="/opt/vaultwarden/backup-key.pub"

mkdir -p "${BACKUP_DIR}"

# Back up SQLite database consistently
sqlite3 "${DATA_DIR}/db.sqlite3" ".backup '${BACKUP_DIR}/db-${DATE}.sqlite3'"

# Package database + attachments + config
tar cf "${BACKUP_FILE}" \
  -C "${BACKUP_DIR}" "db-${DATE}.sqlite3" \
  -C "${DATA_DIR}" attachments/ \
  -C /opt/vaultwarden .env compose.yaml 2>/dev/null || true

# Encrypt with age recipient key (non-interactive)
age -R "${RECIPIENT}" -o "${BACKUP_FILE}.age" "${BACKUP_FILE}"

# Clean up unencrypted files
rm -f "${BACKUP_FILE}" "${BACKUP_DIR}/db-${DATE}.sqlite3"

# Remove backups older than 30 days
find "${BACKUP_DIR}" -name "*.age" -mtime +30 -delete

echo "Backup complete: ${BACKUP_FILE}.age"

chmod 700 /opt/vaultwarden/backup.sh

Voor geautomatiseerde dagelijkse back-ups, voeg een cronjob toe:

echo "0 3 * * * root /opt/vaultwarden/backup.sh >> /var/log/vaultwarden-backup.log 2>&1" > /etc/cron.d/vaultwarden-backup
chmod 644 /etc/cron.d/vaultwarden-backup

Voor offsite-kopieën, push de versleutelde back-up naar een externe server of objectopslag:

rsync -az /opt/vaultwarden/backups/*.age backup-user@remote-server:/backups/vaultwarden/

Herstelprocedure

Een back-up die je nooit hebt hersteld is een back-up die je niet kunt vertrouwen. De volledige procedure:

# Stop the container
cd /opt/vaultwarden && docker compose down

# Decrypt the backup
age -d -i /opt/vaultwarden/backup-key.txt -o /tmp/vaultwarden-restore.tar /opt/vaultwarden/backups/vaultwarden-2026-03-20_0300.tar.age

# Extract
mkdir -p /tmp/vaultwarden-restore
tar xf /tmp/vaultwarden-restore.tar -C /tmp/vaultwarden-restore

# Replace the database (delete WAL files first)
rm -f /opt/vaultwarden/data/db.sqlite3-wal /opt/vaultwarden/data/db.sqlite3-shm
cp /tmp/vaultwarden-restore/db-2026-03-20_0300.sqlite3 /opt/vaultwarden/data/db.sqlite3
chown 1000:1000 /opt/vaultwarden/data/db.sqlite3

# Restore attachments
rsync -a /tmp/vaultwarden-restore/attachments/ /opt/vaultwarden/data/attachments/
chown -R 1000:1000 /opt/vaultwarden/data/attachments/

# Start the container
docker compose up -d

# Clean up
rm -rf /tmp/vaultwarden-restore /tmp/vaultwarden-restore.tar

Je moet de WAL- (Write-Ahead Log) en SHM-bestanden verwijderen voor het herstellen. Deze bestanden horen bij de oude databasestatus. Vaultwarden starten met een herstelde database maar verouderde WAL-bestanden leidt tot datacorruptie.

Log na het herstel in op de webkluis en controleer of je items aanwezig zijn.

Hoe werk ik Vaultwarden veilig bij?

Pin je image op een specifieke versietag (wij gebruikten 1.35.4). Gebruik nooit :latest in productie omdat je niet kunt bijhouden wat er is veranderd of betrouwbaar kunt terugdraaien.

Om bij te werken:

cd /opt/vaultwarden

# Back up first
./backup.sh

# Pull the new version
docker compose pull

# Recreate the container
docker compose up -d

Bewerk voor het pullen compose.yaml om de imagetag naar de nieuwe versie te wijzigen. Bekijk de release notes voor breaking changes.

docker compose logs --tail 30

Als de update problemen veroorzaakt, herstel vanuit je back-up:

# Revert compose.yaml to the old version tag
docker compose down
# Follow the restore procedure above
docker compose up -d

Gaat er iets mis?

Container stopt onmiddellijk:

docker compose logs

Zoek naar rechtenfouten. De directive user: 1000:1000 vereist overeenkomend eigenaarschap op /opt/vaultwarden/data. Voer chown -R 1000:1000 /opt/vaultwarden/data uit en probeer opnieuw.

Geen toegang tot de webkluis:

Controleer of de reverse proxy doorstuurt naar 127.0.0.1:8080:

curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:8080/alive

Een 200-respons betekent dat Vaultwarden draait. Het probleem zit in je reverse-proxyconfiguratie.

Fail2ban blokkeert niet:

fail2ban-regex /opt/vaultwarden/data/vaultwarden.log /etc/fail2ban/filter.d/vaultwarden.local

Als de regex nul regels matcht, controleer of LOG_FILE=/data/vaultwarden.log is ingesteld in .env en of het logbestand bestaat op /opt/vaultwarden/data/vaultwarden.log.

E-mails worden niet verzonden:

docker compose logs | grep -i "smtp\|mail\|email"

Controleer of je VPS uitgaande verbindingen op de SMTP-poort toestaat:

nc -zv smtp.example.com 587

Database-locked-fouten:

Dit kan gebeuren als je het databasebestand kopieert terwijl Vaultwarden draait. Gebruik altijd sqlite3 .backup voor back-ups en stop altijd de container voor het herstellen.

Loglocaties:

# Application logs
docker compose logs -f

# Log file (if LOG_FILE is set)
tail -f /opt/vaultwarden/data/vaultwarden.log

# Fail2ban logs
journalctl -u fail2ban -f

Voor Docker-containerbeveiliging die verder gaat dan deze tutorial, zie Docker Security Hardening: Rootless Mode, Seccomp, AppArmor op een VPS. Voor back-upstrategieën voor al je Docker-services, zie Docker-volumes back-uppen en herstellen op een VPS.

Copyright 2026 Virtua.Cloud. Alle rechten voorbehouden. Deze inhoud is een origineel werk van het Virtua.Cloud-team. Reproductie, herpublicatie of herdistributie zonder schriftelijke toestemming is verboden.

Klaar om het zelf te proberen?

Deploy uw eigen server in seconden. Linux, Windows of FreeBSD.

Bekijk VPS-aanbod