Så självhostar du Vaultwarden 2026: domäner, SMTP och säkra säkerhetskopior

Det finns två varianter av att ”köra Vaultwarden”: antingen finns en container, eller så utför tjänsten faktiskt sitt jobb. Det är bara det senare som spelar någon roll. Här är beviset att logga in från ett webbläsartillägg, skapa ett objekt, synkronisera en andra klient, ladda upp en bilaga och hämta ett Send efter omstart.

Vaultwarden fyller detta syfte: en kompakt lösenordsserver som är kompatibel med Bitwarden. Driftsättningen måste bevara delarna bakom detta beteende; en port, en volym och ett certifikat är förutsättningar, inte resultatet.

Volymer är bara det första återställningslagret

Den beständiga återställningsmängden består av databasen, bilagor, Sends, nycklar och konfiguration i /data. Montera /data före bootstrap, skriv ofarliga exempeldata och ersätt containern för att bevisa att sökvägen faktiskt är beständig. En volym skyddar data från att containern ersätts, men inte från att värden går förlorad, oavsiktlig radering eller korruption på applikationsnivå.

Ta säkerhetskopior som förstår datakällan: använd logiska dumpningar för aktiva databaser när det behövs och kopiera filer endast från ett konsistent tillstånd. Förvara en krypterad kopia separat från Vaultwarden-värden. Godkännandekriteriet för en återställning är specifikt — valvobjekt, bilagor, Sends och organisationsmedlemskap ska synkroniseras korrekt till en ren klient efter återställningen. Guiden om säkerhetskopior som har återställningstestats förklarar varför det inte räcker att jobbet rapporterar framgång.

Starta Vaultwarden utan att dölja de rörliga delarna

Starta Vaultwarden på ett sätt som håller routen privat tills bootstrap är klart.

docker run -d \
  --name vaultwarden \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v vaultwarden-data:/data \
  -e ADMIN_TOKEN=replace-with-a-long-random-value \
  vaultwarden/server:latest

Om processen startar om i en loop, jämför imagen användare med ägaren för varje monterad sökväg. Om den fortsätter köra testar du port 80 lokalt och går sedan direkt vidare till arbetsflödet: logga in från ett webbläsartillägg, skapa ett objekt, synkronisera en andra klient, ladda upp en bilaga och hämta ett Send efter omstart. Lås image-versionen först när denna end-to-end-kontroll har godkänts och dokumentera den exakta konfigurationen bredvid tjänsten.

Definiera Vaultwardens runtime-gränser

Definiera tre gränser runt Vaultwarden: inkommande trafik till port 80, beständigt tillstånd och stödkrav. Containern kan ersättas, men de andra två behöver tydliga ägare. Det externa kravet för Vaultwarden är fungerande SMTP om inbjudningar och e-post för emergency access krävs. Testa utgående DNS, TLS och leverantörens beteende utan att publicera ytterligare en inkommande tjänst.

Diagrammet är komplett när en ren klient kan logga in från ett webbläsartillägg, skapa ett objekt, synkronisera en andra klient, ladda upp en bilaga och hämta ett Send efter omstart. Samla in tids- och resursdata för bilagevolym, SQLite-skrivkonflikter eller begränsningar i database pool samt SMTP-latens under inbjudningar. Om transaktionen misslyckas visar den första gräns som inte beter sig enligt dokumentationen om du ska undersöka routing, lokal kapacitet eller en stödjande tjänst.

Håll interna och externa URL:er åtskilda

Undvik tillfälliga och permanenta publika origins för Vaultwarden. Ange i stället DOMAIN till exakt extern HTTPS-origin, peka det valda DNS-namnet på plattformens route och proxya endast till port 80.

Testa detta utifrån och inte från värden: logga in från ett webbläsartillägg, skapa ett objekt, synkronisera en andra klient, ladda upp en bilaga och hämta ett Send efter omstart. Om ingress misslyckas beskriver felsökningsguiden för 502 vanliga misstag med port och listener. Om Vaultwarden tar emot begäran men DOMAIN är HTTP medan webbläsaren kräver en säker origin för valvfunktioner, pekar bevisen nu bortom proxyn.

Ett produktionsgodkännande för Vaultwarden

En produktionsspärr för Vaultwarden ska kunna genomföras av någon som inte byggde driftsättningen. Ge personen den låsta versionen, ett icke-känsligt testkonto och denna uppgift: logga in från ett webbläsartillägg, skapa ett objekt, synkronisera en andra klient, ladda upp en bilaga och hämta ett Send efter omstart. Om instruktionerna kräver odokumenterad shell-åtkomst är tjänsten ännu inte redo ur ett driftsperspektiv.

Upprepa kontrollen efter att endast containern har ersatts. Återställ sedan databasen, bilagorna, Sends, nycklarna och konfigurationen i /data till en tom infrastruktur och bevisa att valvobjekt, bilagor, Sends och organisationsmedlemskap synkroniseras korrekt till en ren klient efter återställningen. Mät bilagevolym, SQLite-skrivkonflikter eller begränsningar i database pool samt SMTP-latens under inbjudningar vid båda lyckade körningarna; oväntade skillnader avslöjar ofta en saknad cache, ett saknat index, en worker eller en datamontering.

Lägg till en failure drill: neka tillfälligt den testsökväg som används av fungerande SMTP när inbjudningar och e-post för emergency access krävs. Vaultwarden ska generera ett användbart fel, bevara det befintliga tillståndet och återhämta sig när det korrekta villkoret återställs. Spara tidsstämplarna och relevanta loggrader, med secrets borttagna. Dessa bevis blir referensen för nästa image- eller konfigurationsändring.

Övervaka arbetsbelastningen, inte bara containern

En grön container är nödvändig men inte tillräcklig. Tjänstens indikator är att ”logga in från ett webbläsartillägg, skapa ett objekt, synkronisera en andra klient, ladda upp en bilaga och hämta ett Send efter omstart” slutförs framgångsrikt, medan de sannolika belastningssignalerna är bilagevolym, SQLite-skrivkonflikter eller begränsningar i database pool samt SMTP-latens under inbjudningar.

Ändringshantering är viktig eftersom Vaultwardens databas-migreringar och Bitwarden-klienternas kompatibilitet måste kontrolleras tillsammans; rotation av ADMIN_TOKEN är en ändring av administratörsåtkomst, inte en migrering av valvdata. Bevara den gamla imagen, testa migreringar på en kopierad datamängd och dokumentera om rollback stöds efter att schemat har flyttats. Om DOMAIN är HTTP medan webbläsaren kräver en säker origin för valvfunktioner ska du diagnostisera den första gräns som skiljer sig från den fungerande miljön.

Stäng tillfällig åtkomst under konfigurationen

En säker Vaultwarden-driftsättning börjar med att ta bort behörigheter. Undvik att använda en svag admin-token eller lämna registrering öppen; inaktivera i stället öppen registrering när onboarding är klar, skydda admin-sidan med en stark token och kräv HTTPS för varje valvklient.

Ersätt exempelvärdet för ADMIN_TOKEN omedelbart, lagra det utanför imagen och rotera det som en administratörscredential om det exponeras. Begränsa administrativa routes, använd privat DNS för beroenden och granska varje bind mount. När loggar skickas centralt ska secrets och privat innehåll filtreras bort innan de lämnar servern.

Använd Dockup för plattformslagret

Dockup tar bort manuellt reverse-proxy- och lifecycle-arbete runt Vaultwarden. Tjänsten får en stabil HTTPS-route till port 80, injicerad konfiguration och persistent storage när containrar ersätts. En ansluten kundserver följer samma modell som compute i Dockup.

Efter lanseringen uppfyller du applikationskontraktet: ange DOMAIN till exakt extern HTTPS-origin, tillåt och verifiera fungerande SMTP om inbjudningar och e-post för emergency access krävs och kör detta test: logga in från ett webbläsartillägg, skapa ett objekt, synkronisera en andra klient, ladda upp en bilaga och hämta ett Send efter omstart. På så sätt förblir one-click-upplevelsen användbar utan att dölja detaljerna som gör Vaultwarden återställningsbart och säkert.

Vanliga frågor

Vad behöver Vaultwarden för en produktionsdriftsättning?

Routa Vaultwarden-containern på port 80 genom en enda HTTPS-origin. Det externa leveranskravet är fungerande SMTP om inbjudningar och e-post för emergency access krävs. Förklara inte Vaultwarden som redo förrän du kan logga in från ett webbläsartillägg, skapa ett objekt, synkronisera en andra klient, ladda upp en bilaga och hämta ett Send efter omstart.

Vilken Vaultwarden-data ska ingå i en säkerhetskopia?

Bevara /data och inkludera databasen, bilagor, Sends, nycklar och konfigurationen i /data i samma återställningsmanifest. En ren Vaultwarden-återställning är godkänd först när valvobjekt, bilagor, Sends och organisationsmedlemskap synkroniseras korrekt till en ren klient efter återställningen.

Kräver Vaultwarden HTTPS bakom en reverse proxy?

Använd HTTPS för den publika Vaultwarden-originen och behåll port 80 i den interna routen. Tillämpa Vaultwardens inställning korrekt: ange DOMAIN till exakt extern HTTPS-origin. För Vaultwarden skyddar HTTPS autentiseringsuppgifter eller användarinnehåll under transport och håller origin-känsligt klientbeteende konsekvent.

Hur bör en Vaultwarden-uppgradering testas?

Återställ det aktuella Vaultwarden-tillståndet till en isolerad driftsättning, tillämpa den nya versionen och upprepa dess godkännandetransaktion. Var särskilt uppmärksam eftersom Vaultwardens databas-migreringar och Bitwarden-klienternas kompatibilitet måste kontrolleras tillsammans; rotation av ADMIN_TOKEN är en ändring av administratörsåtkomst, inte en migrering av valvdata. Behåll den föregående Vaultwarden-imagen tills gränserna för datamigrering och rollback är klarlagda.