Hoste Vaultwarden på en Managed VPS: dine adgangskoder på din egen server

Hvad Vaultwarden gør

Vaultwarden er en server til administration af adgangskoder, skrevet i Rust og udviklet til selvhosting. Dens wiki henvender den til privatpersoner, familier og organisationer af overskuelig størrelse. Webboksen følger med i dens Docker-images.

Den implementerer et API, der er kompatibelt med de officielle Bitwarden-klienter i browseren, på computeren og på telefonen. README'en understreger, at projektet ikke er tilknyttet Bitwarden eller Bitwarden, Inc., og beder om, at man henvender sig direkte til projektet med enhver fejl, uanset hvilken klient der bruges, frem for til de officielle supportkanaler.

• Boksen: personlig boks, vedhæftede filer, ikoner for websites, personlig API-nøgle og Send til at videregive en tekst eller en fil.
• Organisationerne: samlinger, deling af adgangskoder, roller, grupper, hændelseslogge og politikker.
• Tofaktorgodkendelse: godkendelsesapp, e-mail, FIDO2 WebAuthn, YubiKey og Duo.
• Nødløsningerne: nødadgang og kontogendannelse, hvor sidstnævnte kræver, at e-mail er konfigureret.
• Administrationen: en side /admin til indstillinger, konti og diagnosticering.

Wikien opregner også, hvad der mangler i forhold til den officielle server, som login med adgangsnøgle, tilpassede roller og visse virksomhedspolitikker. Den understreger, at funktioner, der mest gavner store organisationer, ikke er en prioritet for projektet: læs listen, hvis du får brug for dem.

Hvad AGPL-3.0-licensen tillader

Vaultwarden udgives under GNU Affero General Public License, version 3. Teksten fastslår en ubegrænset tilladelse til at køre det uændrede program. Du kan altså bruge det image, projektet udgiver, til din virksomhed og dit team uden at skulle købe en licens.

Artikel 13 tilføjer en betingelse, der er særlig for AGPL: hvis du ændrer programmet, skal din version tilbyde alle, der bruger den på afstand, via netværket, en måde at få dens kildekode gratis.

Installation med Docker Compose

README'en anbefaler container-images. På en server, hvor Docker er installeret, opretter du en mappe og lægger denne compose.yaml i den, hentet fra README'en og wikien:

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "true"
    volumes:
      - ./vw-data/:/data/
    ports:
      - 127.0.0.1:8000:80

docker compose up -d

• En port, der publiceres på 127.0.0.1: som i README'en nås Vaultwarden kun via reverse proxyen, som er placeret på samme server.
• DOMAIN: basisadressen på din instans, i https. Wikien advarer om, at funktioner går i stykker uden den, blandt andet vedhæftede filer og invitationslinks.
• En mappe vw-data på en lokal disk: den rummer alle data. Wikien påpeger problemerne med SQLite på et CIFS- eller Samba-volumen, som ikke håndterer låsning.
• Tagget latest følger den senest udgivne version, og wikien anbefaler det til de fleste formål. Et tag som 1.37.5 fastlåser en version, og latest-alpine giver det samme på en Alpine-base.

Dit domænenavn peger på serveren med A- og AAAA-records, og de besøgende kommer ind på port 80 og 443. Så længe reverse proxyen ikke er på plads, kan webboksen ikke bruges: gå direkte videre til næste afsnit.

Projektet opgiver hverken hukommelse eller processor; det præsenterer sig blot som en løsning til de tilfælde, hvor den officielle tjeneste, der kræver mange ressourcer, ikke passer. Størrelsen afhænger af antallet af konti og af mængden af vedhæftede filer. På en Managed VPS beskriver du blot din brug for os, og vi anbefaler den størrelse, der passer.

HTTPS og WebSocket: reverse proxyen

Webboksen bygger på Web Crypto-API'et, som browserne forbeholder sikre kontekster: README'en angiver, at den kun fungerer, når HTTPS er slået til, og wikien betegner HTTPS som «pretty much required», det vil sige næsten obligatorisk. Projektet anbefaler en reverse proxy foran Vaultwarden og fraråder den TLS, der er indbygget i dets framework Rocket.

Brug et anerkendt certifikat, som dem fra Let's Encrypt, som wikien anbefaler: med et selvsigneret certifikat afviser visse platforme forbindelsen. Certifikatet skal indeholde hele sin kæde, ellers kan Android-enheder ikke oprette forbindelse.

WebSocket-notifikationerne, som er slået til som standard, giver browseren, skrivebordsappen og udvidelsen besked om, at en post er ændret. De går gennem den primære HTTP-port, og proxyen skal videresende headerne Upgrade og Connection. Mobilapps bruger deres systems egne native notifikationer, som konfigureres separat.

Med Caddy

Wikien råder til at se på Caddy først, hvis du ikke har nogen præference: den slår selv HTTPS til, henter certifikatet fra Let's Encrypt og understøtter WebSocket. Wikiens indstilling videregiver også den besøgendes rigtige adresse til Vaultwarden til dens logfiler:

vault.example.com {
  reverse_proxy 127.0.0.1:8000 {
    header_up X-Real-IP {remote_host}
  }
}

Med Nginx og Certbot

Denne blok bygger på wikiens Nginx-eksempel, begrænset til port 80, så Certbot kan sætte HTTPS op:

upstream vaultwarden-default {
  zone vaultwarden-default 64k;
  server 127.0.0.1:8000;
  keepalive 2;
}

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      "";
}

server {
    listen 80;
    listen [::]:80;
    server_name vault.example.com;

    client_max_body_size 525M;

    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    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;

    location / {
      proxy_pass http://vaultwarden-default;
    }
}

Certbot installerer derefter certifikatet og sørger for at forny det:

sudo certbot --nginx

Kontrollér WebSocket

Åbn browserens udviklerværktøjer, fanen netværk, filteret WS, og log derefter på boksen igen: et 101-svar på /notifications/hub bekræfter forbindelsen. En anden test fra wikien: åbn boksen i to browsere, omdøb en post i den ene, og ændringen vises straks i den anden.

Luk tilmeldingerne

Som standard kan enhver, der kan nå din instans, oprette en konto på den. Det er praktisk til din første konto, og wikien anbefaler derefter at lukke, så en angriber ikke kan oprette en.

1. Åbn din HTTPS-adresse, opret din konto, og forbind derefter dine apps til denne adresse.
2. Sæt SIGNUPS_ALLOWED til "false" i compose.yaml.
3. Genstart med docker compose up -d: en miljøvariabel er knyttet til containeren, som skal genskabes for at tage den i betragtning.

SIGNUPS_ALLOWED: "false"

• Invitationerne forbliver åbne efter lukningen: ejere og administratorer af en organisation kan invitere nye personer. INVITATIONS_ALLOWED sat til "false" fjerner denne mulighed, og wikien overlader valget til dig efter den tillid, du har til dine brugere.
• En domæneliste: SIGNUPS_DOMAINS_WHITELIST begrænser tilmeldingen til visse e-maildomæner, og SIGNUPS_VERIFY sat til true kræver så, at adressen bekræftes. Når denne liste er angivet, ignoreres SIGNUPS_ALLOWED.
• Administrationssiden gør det muligt at invitere hvem som helst, uanset disse begrænsninger.

Så snart du gemmer konfigurationen fra administrationssiden, opstår en fil config.json i datamappen, og den går forud for miljøvariablerne. De berørte indstillinger ændres så fra den side: det er ikke længere nok at ændre compose.yaml.

Administrationssiden og dens token

Siden /admin bruges til at konfigurere Vaultwarden, til at se og slette konti og organisationer, til at fjerne en brugers tofaktorgodkendelse, til at invitere og til at læse diagnosen. Uden ADMIN_TOKEN forbliver den deaktiveret: hvis du ikke har brug for den, så lad den være det.

Wikien anbefaler på det kraftigste at slå HTTPS til, før du bruger denne side. Tokenet fungerer som adgangskode, og det kan opbevares i hashet form, med argon2id, frem for i klartekst i konfigurationen. Vaultwarden leverer kommandoen: den spørger to gange efter adgangskoden og returnerer derefter en PHC-streng.

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

Læg denne streng i en .env-fil ved siden af compose.yaml, mellem apostroffer, og kald den derefter fra tjenesten:

VAULTWARDEN_ADMIN_TOKEN='$argon2id$...'

ADMIN_TOKEN: ${VAULTWARDEN_ADMIN_TOKEN}

Kontrollér resultatet, genstart, og log derefter ind på /admin med din adgangskode, og ikke med PHC-strengen:

docker compose config
docker compose up -d

• Sessionen varer 20 minutter som standard, og det kan justeres med ADMIN_SESSION_LIFETIME. En åben session forbliver gyldig efter et skift af token. For at afbryde dem alle skal du slette rsa_key.pem fra datamappen og genstarte, hvilket også logger brugerne af og annullerer igangværende invitationer.
• Begrænset adgang: wikiens proxy-eksempler viser, hvordan man kun åbner /admin for visse adresser eller tilføjer HTTP-godkendelse.
• DISABLE_ADMIN_TOKEN fjerner enhver kontrol: den er beregnet til et separat godkendelseslag foran, og wikien forbeholder den dem, der ved, hvad de gør.

Hvad der beskytter boksen

Den første beskyttelse er hovedadgangskoden. Boksens data er krypteret med personlige nøgler eller organisationsnøgler: den, der får en kopi af databasen eller overtager en session, skal stadig knække denne adgangskode for at læse dem. Dens styrke tæller derfor mest af alt. En administrationssession gør det i sig selv muligt at slette en konto eller fjerne en tofaktorgodkendelse uden at give adgang til boksens data.

Forbered dig på, at hovedadgangskoden bliver glemt, før det sker: slå nødadgang til for din konto og, i en organisation, kontogendannelse, som kræver, at e-mail er konfigureret.

Tre indstillinger mere, hentet fra hærdningsguiden

• En konto uden root: imaget kører som root som standard, og wikien finder det bedre at give det færrest mulige rettigheder. Tilføj user: 1000:1000 til tjenesten, med en mappe vw-data, der tilhører denne bruger.
• Proxyens logfiler: WebSocket-forbindelsen sender et token i adressen, i access_token. Hvis din proxy gemmer sine logfiler eller sender dem til en ekstern tjeneste, anbefaler wikien at skjule denne værdi der.
• Færrest mulige mounts: mount datamappen og intet andet, hverken din personlige mappe eller /var/run/docker.sock.

SQLite, MariaDB eller PostgreSQL

Det samme image understøtter alle tre databaser. Wikien beskriver SQLite som den mest brugte og mest testede og anbefaler den til de fleste formål, medmindre du har et præcist behov for en anden.

DATABASE_URL: "postgresql://user_name:user_password@db_host:5432/vaultwarden"

Opret en tom database og dens bruger: ved opstart lægger Vaultwarden selv sit skema i den. En adgangskode med specialtegn skrives med procentkodning i denne adresse.

Træf dette valg, før du fylder boksen. Wikien beskriver en overgang fra SQLite til PostgreSQL med pgloader og understreger, at denne vej ikke understøttes af projektet, at den sker på egen risiko, og at den begynder med en backup.

E-mails: SMTP-konfigurationen

Vaultwarden starter uden e-mail, men flere funktioner afhænger af den: invitationer, bekræftelse af adresser, udsendelse af adgangskodehints, tofaktorgodkendelse pr. e-mail og kontogendannelse.

På en Simafri VPS går afsendelsen gennem et autentificeret SMTP-relay på port 587: adressen på en mailkonto, du allerede har, eller Simafri Suite. Adgangskoden lægges i filen .env ligesom administratortokenet:

SMTP_HOST: "smtp.example.com"
SMTP_FROM: "vault@example.com"
SMTP_PORT: "587"
SMTP_SECURITY: "starttls"
SMTP_USERNAME: "vault@example.com"
SMTP_PASSWORD: ${VAULTWARDEN_SMTP_PASSWORD}

• Invitationslinkene bygges ud fra DOMAIN og forbliver gyldige i 5 dage.
• Microsoft: wikien oplyser, at Hotmail, Outlook og Office 365 nu kræver OAuth2, som Vaultwarden endnu ikke understøtter. Den fejl, du skal genkende, er No compatible authentication mechanism was found.
• Gmail: regn med en app-adgangskode, ifølge wikien.
• Testen: administrationssiden sender en test-e-mail. Hvis du ændrer en SMTP-indstilling der, skal du gemme først, for testen bruger de gemte indstillinger, og denne gemning opretter config.json.

Hvis intet bliver sendt, foreslår wikien at teste forbindelsen til relayet fra serveren. Kommandoen returnerer 0, når relayet svarer:

timeout 5 bash -c 'cat < /dev/null > /dev/tcp/smtp.example.com/587'; echo $?

Backup

README'en minder om, at projektet ikke kan holdes ansvarligt for tab af data, og anbefaler på det kraftigste regelmæssig backup. Wikien råder til, at den er automatisk, med mindst én kopi et andet sted. Her er, hvad datamappen indeholder med SQLite:

Databasen, mens tjenesten kører

Siden version 1.32.1 kan Vaultwarden selv tage backup af sin SQLite-database uden at stoppe tjenesten:

docker exec -it vaultwarden /vaultwarden backup

Kommandoen skriver en fil db_AAAAMMJJ_HHMMSS.sqlite3 ved siden af databasen, i vw-data. Imaget indeholder hverken sqlite3 eller cron: wikien råder til at planlægge opgaven på serveren, mindst én gang om dagen. Fjern i så fald -it, for en planlagt opgave har ikke noget terminalvindue, og ryd op i disse filer, som hober sig op.

Hele mappen, med tjenesten stoppet

Når databasen ikke er i brug, er en simpel kopi af alle dens filer nok. Det er den metode med stoppet tjeneste, som wikien giver som eksempel for Docker, og den tager også de vedhæftede filer med:

docker compose down
tar -czf vaultwarden-$(date +%F).tar.gz vw-data
docker compose up -d

Wikien finder et lag kryptering nyttigt, især når backuppen indeholder administratortokenet og SMTP-adgangene, og nævner rclone, restic og rustic til at sende kopierne et andet sted hen. Med MariaDB eller PostgreSQL tilføjer du en eksport af databasen til mappen vw-data.

Wikien beder om ikke kun at stole på diskens snapshots, som er sværere at gendanne. Behold derfor disse kopier, der er specifikke for applikationen: lagt på serverens disk indgår de også i dens natlige backup.

Gendan

1. Stop Vaultwarden.
2. Erstat hver fil eller mappe i vw-data med dens gemte version.
3. Hvis databasen stammer fra /vaultwarden backup, skal du give den navnet db.sqlite3 og først slette enhver eksisterende fil db.sqlite3-wal: en journal, der ikke passer, kan ødelægge databasen. Hvis den stammer fra en direkte kopi, skal du gendanne db.sqlite3 og dens db.sqlite3-wal sammen.
4. Genstart, og kontrollér derefter, at du kan åbne boksen.

Wikien råder til at gentage denne øvelse en gang imellem og beholde en kopi af de eksisterende data: sådan kontrollerer du, at en backup virker.

Opdateringer

Wikien giver to kommandoer, fra mappen med compose.yaml. Datamappen bliver, hvor den er:

docker compose pull
docker compose up -d

Disse opdateringer tæller mere end andre steder. Mobilapps og browserudvidelser opdaterer sig selv, og wikien advarer om, at en versionsforskel til serveren kan give pludselige nedbrud. Webboksen, der leveres i imaget, er altid afstemt efter sin server.

Projektet har ingen udgivelsesplan: følg dets versionsnoter, og tag en backup lige før hver opdatering. Nogle indeholder sikkerhedsrettelser, som 1.37.5 fra den 1. november 2026, hvis noter anbefaler at opdatere hurtigst muligt. Noterne advarer også om, at en ugyldig konfigurationsværdi siden 1.37.5 forhindrer Vaultwarden i at starte: gennemgå din miljøfil igen før opdateringen. Diagnosesiden under /admin viser, om der findes en nyere version.

Hvem gør hvad på en Managed VPS

Selvhosting kræver, at du holder serveren ud over selve applikationen. På en Managed VPS tager vores teams sig af serveren og følger din instans proaktivt; Vaultwarden forbliver din software, med dens indstillinger og data.

Hvis du foretrækker, at vores teams griber ind i selve applikationen, faktureres den ydelse pr. time eller som fast pris, med et overslag oplyst før indgrebet.