Sådan selvhoster du Vaultwarden i 2026: Domæner, SMTP og sikre backups
En praktisk guide til selvhosting af Vaultwarden med fokus på Docker, porte, persistent data, TLS, sikkerhed, backups og de fejl, der forhindrer produktionsbrug.
Der er to versioner af at “køre Vaultwarden”: Der findes en container, eller også udfører servicen faktisk sit arbejde. Det er kun den sidste, der tæller. Her er beviset, at du kan logge ind fra en browserudvidelse, oprette et element, synkronisere en ekstra klient, uploade en vedhæftning og hente en Send efter en genstart.
Vaultwarden har dette formål: en kompakt Bitwarden-kompatibel passwordserver. Deploymentet skal bevare de dele, der ligger bag denne funktionalitet; en port, et volume og et certifikat er input — ikke resultatet.
Volumes er kun det første recovery-lag
Det varige recovery-sæt består af databasen, vedhæftninger, sends, nøgler og konfigurationen i /data. Montér /data før bootstrap, skriv ufarlige testdata, og erstat containeren for at bevise, at stien faktisk er persistent. Et volume beskytter data mod udskiftning af containeren, men ikke mod tab af hosten, utilsigtet sletning eller korruption på applikationsniveau.
Tag backups, der forstår datakilden: Brug logical dumps til live-databaser, når det er nødvendigt, og kopiér kun filer fra en konsistent tilstand. Opbevar én krypteret kopi væk fra Vaultwarden-hosten. Acceptkriteriet for en restore er konkret — vault-elementer, vedhæftninger, Sends og organisationsmedlemskab skal synkronisere korrekt til en ren klient efter restore. Guiden om backups, der er testet med restore forklarer, hvorfor et vellykket job alene ikke er tilstrækkeligt.
Start Vaultwarden uden at skjule de bevægelige dele
Start Vaultwarden på en måde, der holder routen privat, indtil bootstrap er gennemført.
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
Hvis processen går i loop, skal du sammenligne imagets forventede bruger med ejeren af hver mountede sti. Hvis den forbliver kørende, skal du teste port 80 lokalt og derefter gå direkte til workflowet: Log ind fra en browserudvidelse, opret et element, synkronisér en ekstra klient, upload en vedhæftning, og hent en Send efter en genstart. Fastlås image-versionen, når dette end-to-end-tjek er bestået, og dokumentér den præcise konfiguration sammen med servicen.
Tegn Vaultwardens runtime-grænse
Tegn tre grænser omkring Vaultwarden: ingress til port 80, persistent state og understøttende krav. Containeren kan udskiftes, men de to andre kræver tydelige ejere. Det eksterne krav til Vaultwarden er fungerende SMTP, hvis invitationer og mails om emergency access er nødvendige. Test outbound DNS, TLS og providerens adfærd uden at publicere endnu en inbound-service.
Diagrammet er komplet, når en ren klient kan logge ind fra en browserudvidelse, oprette et element, synkronisere en ekstra klient, uploade en vedhæftning og hente en Send efter en genstart. Indsaml tids- og ressourcedata for mængden af vedhæftninger, SQLite write contention eller database-poolgrænser samt SMTP-latens under invitationer. Hvis transaktionen fejler, viser den første grænse, der ikke opfører sig som dokumenteret, om du skal undersøge routing, lokal kapacitet eller en understøttende service.
Hold interne og eksterne URL'er adskilt
Undgå midlertidige og permanente offentlige origins for Vaultwarden. Sæt i stedet DOMAIN til den præcise eksterne HTTPS-origin, peg det valgte DNS-navn på platformens route, og proxy kun til port 80.
Udfør denne handling uden for hosten: Log ind fra en browserudvidelse, opret et element, synkronisér en ekstra klient, upload en vedhæftning, og hent en Send efter en genstart. Hvis ingress fejler, gennemgår guiden til fejlfinding af 502 Bad Gateway fejl med porte og listeners. Hvis Vaultwarden modtager requesten, men DOMAIN er HTTP, mens browseren kræver en secure origin til vault-funktioner, peger beviserne nu et andet sted hen end proxyen.
En produktionsaccepttest for Vaultwarden
En production gate for Vaultwarden skal kunne udføres af en person, der ikke selv har bygget deploymentet. Giv personen den fastlåste version, en ikke-følsom testkonto og denne opgave: Log ind fra en browserudvidelse, opret et element, synkronisér en ekstra klient, upload en vedhæftning, og hent en Send efter en genstart. Hvis instruktionerne kræver udokumenteret shell-adgang, er servicen endnu ikke driftsklar.
Gentag testen efter kun at have udskiftet containeren. Gendan derefter databasen, vedhæftninger, sends, nøgler og konfigurationen i /data til blank infrastruktur, og bevis, at vault-elementer, vedhæftninger, Sends og organisationsmedlemskab synkroniserer korrekt til en ren klient efter restore. Mål mængden af vedhæftninger, SQLite write contention eller database-poolgrænser samt SMTP-latens under invitationer under begge vellykkede kørsler; uventede forskelle afslører ofte en manglende cache, et manglende index, en worker eller et datamount.
Tilføj en failure drill: Afvis midlertidigt den teststi, der bruges af fungerende SMTP, hvis invitationer og mails om emergency access er nødvendige. Vaultwarden skal rapportere en nyttig fejl, bevare den eksisterende state og gendanne funktionen, når den gyldige betingelse vender tilbage. Gem tidsstemplerne og relevante loglinjer med secrets redacted. Disse beviser bliver referencepunktet for det næste image eller den næste konfigurationsændring.
Overvåg workloadet, ikke kun containeren
En grøn container er nødvendig, men ikke tilstrækkelig. Serviceniveauindikatoren er en vellykket gennemførelse af “log ind fra en browserudvidelse, opret et element, synkronisér en ekstra klient, upload en vedhæftning, og hent en Send efter en genstart”, mens de sandsynlige belastningssignaler er mængden af vedhæftninger, SQLite write contention eller database-poolgrænser samt SMTP-latens under invitationer.
Change control er vigtigt, fordi Vaultwardens databasemigreringer og Bitwarden-klientkompatibilitet skal kontrolleres samlet; rotation af ADMIN_TOKEN er en ændring af administratoradgang, ikke en migration af vault-data. Bevar det gamle image, test migreringer på en kopi af state, og dokumentér, om rollback understøttes, efter at schemaet er flyttet. Hvis DOMAIN er HTTP, mens browseren kræver en secure origin til vault-funktioner, skal du diagnosticere den første grænse, der adskiller sig fra det fungerende miljø.
Luk midlertidig setup-adgang
Et sikkert Vaultwarden-deployment begynder med at fjerne rettigheder. Undgå at bruge et svagt admin-token eller lade sign-ups stå åbne; deaktivér i stedet open sign-up, når enrollment er afsluttet, beskyt admin-siden med et stærkt token, og kræv HTTPS for alle vault-klienter.
Erstat straks eksempelværdien for ADMIN_TOKEN, opbevar den uden for imaget, og rotér den som en administratorcredential, hvis den bliver eksponeret. Begræns administrative routes, brug private DNS-navne til dependencies, og gennemgå alle bind mounts. Når logs sendes centralt, skal du filtrere secrets og privat indhold fra, før de forlader serveren.
Brug Dockup til platformlaget
Dockup fjerner manuelt reverse-proxy- og lifecycle-arbejde omkring Vaultwarden. Servicen får en stabil HTTPS-route til port 80, injected configuration og persistent storage under udskiftninger. En tilknyttet kundeserver følger samme model som Dockup-hosted compute.
Efter launch skal du opfylde applikationskontrakten: Sæt DOMAIN til den præcise eksterne HTTPS-origin, tillad og verificér fungerende SMTP, hvis invitationer og mails om emergency access er nødvendige, og kør dette bevis: Log ind fra en browserudvidelse, opret et element, synkronisér en ekstra klient, upload en vedhæftning, og hent en Send efter en genstart. Det bevarer one-click-oplevelsen uden at udviske de detaljer, der gør Vaultwarden recoverable og sikker.
Ofte stillede spørgsmål
Hvad kræver Vaultwarden i et produktionsdeployment?
Route Vaultwarden-containeren på port 80 gennem én HTTPS-origin. Det eksterne delivery-krav er fungerende SMTP, hvis invitationer og mails om emergency access er nødvendige. Erklær ikke Vaultwarden klar, før du kan logge ind fra en browserudvidelse, oprette et element, synkronisere en ekstra klient, uploade en vedhæftning og hente en Send efter en genstart.
Hvilke Vaultwarden-data skal med i en backup?
Persistér /data, og medtag databasen, vedhæftninger, sends, nøgler og konfigurationen i /data i det samme recovery-manifest. En ren Vaultwarden-restore er kun godkendt, når vault-elementer, vedhæftninger, Sends og organisationsmedlemskab synkroniserer korrekt til en ren klient efter restore.
Kræver Vaultwarden HTTPS bag en reverse proxy?
Brug HTTPS til den offentlige Vaultwarden-origin, og behold port 80 på den interne route. Anvend Vaultwarden-indstillingen korrekt: Sæt DOMAIN til den præcise eksterne HTTPS-origin. For Vaultwarden beskytter HTTPS credentials eller brugerindhold under transport og sikrer en ensartet klientadfærd, der afhænger af origin.
Hvordan skal en Vaultwarden-opgradering testes?
Gendan den aktuelle Vaultwarden-state i et isoleret deployment, anvend kandidatversionen, og gentag accepttransaktionen. Vær særligt opmærksom, fordi Vaultwardens databasemigreringer og Bitwarden-klientkompatibilitet skal kontrolleres samlet; rotation af ADMIN_TOKEN er en ændring af administratoradgang, ikke en migration af vault-data. Behold det tidligere Vaultwarden-image, indtil grænsen for datamigration og rollback er forstået.