Hosta Vaultwarden på en Managed VPS: dina lösenord på din egen server

Det Vaultwarden gör

Vaultwarden är en server för lösenordshantering, skriven i Rust och gjord för självhosting. Dess wiki riktar den till privatpersoner, familjer och organisationer av mänsklig storlek. Webbvalvet levereras i projektets Docker-avbilder.

Den tillhandahåller ett API som är kompatibelt med de officiella Bitwarden-klienterna, i webbläsaren, på datorn och i telefonen. README-filen anger att projektet inte är knutet till Bitwarden eller Bitwarden, Inc., och ber att få problem rapporterade direkt till projektet, oavsett vilken klient som används, i stället för till de officiella supportkanalerna.

• Valvet: personligt valv, bilagor, webbplatsikoner, personlig API-nyckel och Send för att överföra en text eller en fil.
• Organisationerna: samlingar, delning av lösenord, roller, grupper, händelseloggar och policyer.
• Tvåfaktorsautentiseringen: autentiseringsapp, e-post, FIDO2 WebAuthn, YubiKey och Duo.
• Nödvägarna: nödåtkomst och kontoåterställning, där den senare kräver att e-post är konfigurerad.
• Administrationen: en sida /admin för inställningar, konton och diagnostik.

Wikin listar också det som saknas jämfört med den officiella servern, som inloggning med passkey, anpassade roller och vissa företagspolicyer. Den anger att funktioner som främst är till nytta för stora organisationer inte är en prioritet för projektet: läs listan om du behöver dem.

Det som licensen AGPL-3.0 tillåter

Vaultwarden publiceras under GNU Affero General Public License, version 3. Texten slår fast en obegränsad rätt att köra det oförändrade programmet. Du kan alltså använda avbilden som projektet publicerar för ditt företag och ditt team, utan att köpa någon licens.

Artikel 13 lägger till ett villkor som är särskilt för AGPL: om du ändrar programmet måste din version ge alla som använder den på distans, över nätverket, möjlighet att kostnadsfritt få tag på dess källkod.

Installationen med Docker Compose

README-filen rekommenderar containeravbilderna. På en server där Docker är installerat skapar du en mapp och lägger denna compose.yaml i den, hämtad från README-filen och wikin:

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 som publiceras på 127.0.0.1: som i README-filen nås Vaultwarden bara via den omvända proxyn, installerad på samma server.
• DOMAIN: basadressen till din instans, i https. Wikin varnar för att funktioner slutar fungera utan den, bland andra bilagor och inbjudningslänkar.
• En mapp vw-data på en lokal disk: den innehåller alla data. Wikin varnar för problem med SQLite på en CIFS- eller Samba-volym, som inte hanterar fillåsning.
• Taggen latest följer den senast publicerade versionen, och wikin rekommenderar den för de flesta användningar. En tagg som 1.37.5 låser en version, och latest-alpine ger samma sak på en Alpine-bas.

Ditt domännamn pekar mot servern med A- och AAAA-poster, och besökarna kommer in på port 80 och 443. Så länge den omvända proxyn inte är på plats går webbvalvet inte att använda: gå direkt till nästa avsnitt.

Projektet anger varken minne eller processor; det beskriver sig bara som en lösning för de fall där den officiella, resurskrävande tjänsten inte passar. Storleken beror på antalet konton och volymen av bilagor. På en Managed VPS beskriver du hur du tänker använda den, så rekommenderar vi lämplig storlek.

HTTPS och WebSocket: den omvända proxyn

Webbvalvet bygger på API:et Web Crypto, som webbläsarna reserverar för säkra sammanhang: README-filen anger att det bara fungerar när HTTPS är aktiverat, och wikin bedömer HTTPS som ”pretty much required”, i det närmaste obligatoriskt. Projektet rekommenderar en omvänd proxy framför Vaultwarden och avråder från den inbyggda TLS i ramverket Rocket.

Ta ett erkänt certifikat, som de från Let’s Encrypt, vilka wikin rekommenderar: med ett självsignerat certifikat vägrar vissa plattformar anslutningen. Certifikatet måste ha hela sin kedja, annars ansluter inte Android-enheter.

WebSocket-aviseringarna, aktiva som standard, talar om för webbläsaren, skrivbordsappen och tillägget att en post har ändrats. De går över den huvudsakliga HTTP-porten, och proxyn måste vidarebefordra huvudena Upgrade och Connection. Mobilapparna använder systemets egna aviseringar, som konfigureras separat.

Med Caddy

Wikin råder dig att titta på Caddy först om du inte har någon preferens: den aktiverar HTTPS på egen hand, hämtar certifikatet från Let’s Encrypt och hanterar WebSocket. Wikins inställning skickar också besökarens verkliga adress vidare till Vaultwarden, för dess loggar:

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

Med Nginx och Certbot

Det här blocket bygger på wikins Nginx-exempel, begränsat till port 80 så att Certbot kan installera HTTPS:

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 installerar sedan certifikatet och sköter förnyelsen:

sudo certbot --nginx

Kontrollera WebSocket

Öppna webbläsarens utvecklarverktyg, fliken nätverk, filtret WS, och anslut sedan till valvet igen: ett svar 101 på /notifications/hub bekräftar anslutningen. Ett annat test från wikin: öppna valvet i två webbläsare, byt namn på en post i den ena, så syns ändringen genast i den andra.

Stänga registreringarna

Som standard kan vem som helst som når din instans skapa ett konto där. Det är praktiskt för ditt första konto, och wikin rekommenderar att stänga därefter, så att ingen angripare kan skapa ett.

1. Öppna din HTTPS-adress och skapa ditt konto, och koppla sedan dina appar till den adressen.
2. Sätt SIGNUPS_ALLOWED till "false" i compose.yaml.
3. Starta om med docker compose up -d: en miljövariabel är knuten till containern, som måste skapas på nytt för att den ska gälla.

SIGNUPS_ALLOWED: "false"

• Inbjudningarna förblir öppna efter stängningen: en organisations ägare och administratörer kan bjuda in nya personer. INVITATIONS_ALLOWED satt till "false" tar bort den möjligheten, och wikin överlåter valet åt dig, efter det förtroende du har för dina användare.
• En domänlista: SIGNUPS_DOMAINS_WHITELIST begränsar registreringen till vissa e-postdomäner, och SIGNUPS_VERIFY satt till true kräver då att adressen verifieras. När den listan är satt ignoreras SIGNUPS_ALLOWED.
• Administrationssidan låter dig bjuda in vem som helst, oavsett dessa begränsningar.

Så snart du sparar konfigurationen från administrationssidan skapas en fil config.json i datamappen, och den går före miljövariablerna. De berörda inställningarna ändras då från den sidan: det räcker inte längre att ändra compose.yaml.

Administrationssidan och dess token

Sidan /admin används för att konfigurera Vaultwarden, se och ta bort konton och organisationer, ta bort en användares tvåfaktorsautentisering, bjuda in och läsa diagnostiken. Utan ADMIN_TOKEN förblir den avstängd: har du ingen användning för den, låt den vara så.

Wikin rekommenderar starkt att aktivera HTTPS före den här sidan. Token fungerar som ett lösenord, och den kan förvaras i hashad form, med argon2id, i stället för i klartext i konfigurationen. Vaultwarden tillhandahåller kommandot: det frågar efter lösenordet två gånger och ger sedan tillbaka en PHC-sträng.

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

Lägg den strängen i en fil .env, bredvid compose.yaml, inom apostrofer, och anropa den sedan från tjänsten:

VAULTWARDEN_ADMIN_TOKEN='$argon2id$...'

ADMIN_TOKEN: ${VAULTWARDEN_ADMIN_TOKEN}

Kontrollera resultatet, starta om och logga sedan in på /admin med ditt lösenord, inte med PHC-strängen:

docker compose config
docker compose up -d

• Sessionen varar 20 minuter som standard, justerbart med ADMIN_SESSION_LIFETIME. En öppen session förblir giltig efter ett byte av token. För att avbryta alla tar du bort rsa_key.pem ur datamappen och startar om, vilket också loggar ut användarna och upphäver pågående inbjudningar.
• Begränsad åtkomst: wikins proxyexempel visar hur du öppnar /admin bara för vissa adresser, eller lägger till HTTP-autentisering.
• DISABLE_ADMIN_TOKEN tar bort all kontroll: den är avsedd för ett separat autentiseringslager framför, och wikin reserverar den för dem som vet vad de gör.

Det som skyddar valvet

Det första skyddet är huvudlösenordet. Valvets data krypteras med personliga nycklar eller organisationsnycklar: den som får en kopia av databasen eller tvingar sig in i en session måste fortfarande knäcka det lösenordet för att läsa dem. Dess styrka är därför det viktigaste. En administrationssession i sig gör det möjligt att ta bort ett konto eller en tvåfaktorsautentisering, utan att ge åtkomst till valvets data.

Förbered dig på att huvudlösenordet glöms bort innan det händer: aktivera nödåtkomsten för ditt konto och, i en organisation, kontoåterställningen, som kräver att e-post är konfigurerad.

Tre inställningar till, hämtade ur härdningsguiden

• Ett konto utan root: avbilden körs som root som standard, och wikin anser det bättre att ge den så få rättigheter som möjligt. Lägg till user: 1000:1000 i tjänsten, med en mapp vw-data som tillhör den användaren.
• Proxyns loggar: WebSocket-anslutningen för över en token i adressen, i access_token. Om din proxy sparar sina loggar eller skickar dem till en extern tjänst rekommenderar wikin att dölja det värdet där.
• Så få monteringar som möjligt: montera datamappen och inget annat, varken din personliga mapp eller /var/run/docker.sock.

SQLite, MariaDB eller PostgreSQL

Samma avbild hanterar alla tre databaserna. Wikin beskriver SQLite som den mest använda och mest testade, och rekommenderar den för de flesta användningar, om du inte har ett särskilt behov av en annan.

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

Skapa en tom databas och dess användare: vid start lägger Vaultwarden själv dit sitt schema. Ett lösenord med specialtecken skrivs med procentkodning i den adressen.

Gör det här valet innan du fyller valvet. Wikin beskriver ett byte från SQLite till PostgreSQL med pgloader, och anger att den vägen inte stöds av projektet, att den sker på egen risk och att den börjar med en säkerhetskopia.

E-post: SMTP-konfigurationen

Vaultwarden startar utan e-post, men flera funktioner beror på den: inbjudningar, verifiering av adresser, utskick av lösenordshintar, tvåfaktorsautentisering med e-post och kontoåterställning.

På en VPS från Simafri går utskicken via ett autentiserat SMTP-relä, på port 587: adressen till ett e-postkonto som du redan har, eller Simafri Suite. Lösenordet läggs i filen .env, som administratörstoken:

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}

• Inbjudningslänkarna byggs utifrån DOMAIN och förblir giltiga i 5 dagar.
• Microsoft: wikin anger att Hotmail, Outlook och Office 365 numera kräver OAuth2, som Vaultwarden ännu inte stöder. Felet att känna igen är No compatible authentication mechanism was found.
• Gmail: räkna med ett applösenord, enligt wikin.
• Testet: administrationssidan skickar ett testmeddelande. Om du ändrar en SMTP-inställning där, spara först, eftersom testet använder de sparade inställningarna och den sparningen skapar config.json.

Om inget skickas föreslår wikin att testa anslutningen till reläet från servern. Kommandot ger 0 när reläet svarar:

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

Säkerhetskopiorna

README-filen påminner om att projektet inte kan hållas ansvarigt för dataförlust och rekommenderar starkt regelbundna säkerhetskopior. Wikin råder att göra dem automatiska, med minst en kopia på annat håll. Så här ser datamappen ut med SQLite:

Databasen, med tjänsten igång

Sedan version 1.32.1 kan Vaultwarden säkerhetskopiera sin SQLite-databas själv, utan att tjänsten stoppas:

docker exec -it vaultwarden /vaultwarden backup

Kommandot skriver en fil db_AAAAMMJJ_HHMMSS.sqlite3 bredvid databasen, i vw-data. Avbilden innehåller varken sqlite3 eller cron: wikin råder att schemalägga uppgiften på servern, minst en gång om dagen. Ta då bort -it, eftersom en schemalagd uppgift saknar terminal, och gallra bland filerna, som hopar sig.

Hela mappen, med tjänsten stoppad

När databasen inte används räcker det med en enkel kopia av alla dess filer. Det är metoden med stoppad tjänst som wikin ger som exempel för Docker, och den tar också med bilagorna:

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

Wikin anser ett krypteringslager användbart, särskilt när säkerhetskopian innehåller administratörstoken och SMTP-uppgifterna, och nämner rclone, restic och rustic för att skicka kopiorna långt bort. Med MariaDB eller PostgreSQL lägger du till en export av databasen till mappen vw-data.

Wikin ber dig att inte förlita dig enbart på diskavbilder, som är krångligare att återställa. Behåll därför de här kopiorna som hör till applikationen: lagda på serverns disk ingår de också i dess nattliga säkerhetskopior.

Återställa

1. Stoppa Vaultwarden.
2. Ersätt varje fil eller mapp i vw-data med dess säkerhetskopierade version.
3. Om databasen kommer från /vaultwarden backup, döp den till db.sqlite3 och ta först bort varje befintlig fil db.sqlite3-wal: en journal som inte stämmer kan förstöra databasen. Om den kommer från en direkt kopia återställer du db.sqlite3 och dess db.sqlite3-wal tillsammans.
4. Starta om och kontrollera sedan att du kan öppna valvet.

Wikin råder att upprepa övningen då och då, med en kopia av de befintliga data i behåll: så kontrollerar du att en säkerhetskopia fungerar.

Uppdateringarna

Wikin anger två kommandon, från mappen med compose.yaml. Datamappen ligger kvar:

docker compose pull
docker compose up -d

De här uppdateringarna väger tyngre än annars. Mobilapparna och webbläsartilläggen uppdaterar sig själva, och wikin varnar för att en versionsskillnad mot servern kan orsaka plötsliga fel. Webbvalvet, som levereras i avbilden, är alltid i takt med sin server.

Projektet har ingen utgivningskalender: följ dess versionsanteckningar och ta en säkerhetskopia strax före varje uppdatering. Vissa innehåller säkerhetsrättelser, som 1.37.5 från den 1 november 2026, vars anteckningar rekommenderar att uppdatera så snart som möjligt. Anteckningarna varnar också för att ett ogiltigt konfigurationsvärde sedan 1.37.5 hindrar Vaultwarden från att starta: läs igenom din miljöfil innan du uppdaterar. Diagnostiksidan i /admin visar om en nyare version finns.

Vem gör vad på en Managed VPS

Att självhosta innebär att sköta servern utöver applikationen. På en Managed VPS tar våra team hand om servern och följer din instans proaktivt; Vaultwarden förblir din programvara, med sina inställningar och sina data.

Om du föredrar att våra team ingriper i själva applikationen faktureras den tjänsten per timme eller som fast pris, med en offert som lämnas före ingreppet.