Slik drifter du Vaultwarden selv i 2026: domener, SMTP og sikre sikkerhetskopier

Det finnes to versjoner av «å kjøre Vaultwarden»: enten finnes det en container, eller så gjør tjenesten faktisk jobben den skal. Det er bare den siste som teller. Her er beviset at du kan logge på fra en nettleserutvidelse, opprette et element, synkronisere en ekstra klient, laste opp et vedlegg og hente en Send etter en omstart.

Vaultwarden har dette formålet: en kompakt, Bitwarden-kompatibel passordserver. Distribusjonen må bevare delene som ligger bak denne funksjonaliteten; en port, et volume og et sertifikat er forutsetninger, ikke resultatet.

Volumes er bare det første laget for gjenoppretting

Det varige gjenopprettingssettet består av databasen, vedlegg, sends, nøkler og konfigurasjon i /data. Monter /data før bootstrap, skriv ufarlige eksempeldata og erstatt containeren for å bevise at banen faktisk er persistent. Et volume beskytter data mot at containeren erstattes, men ikke mot tap av verten, utilsiktet sletting eller korrupsjon på applikasjonsnivå.

Ta sikkerhetskopier som forstår datakilden: bruk logiske dumps for aktive databaser når det kreves, og kopier filer bare fra en konsistent tilstand. Oppbevar én kryptert kopi et annet sted enn Vaultwarden-verten. Akseptansekriteriet for en gjenoppretting er konkret — vault-elementer, vedlegg, Sends og organisasjonstilhørighet skal synkroniseres korrekt til en ren klient etter gjenoppretting. Veiledningen for sikkerhetskopier som er testet med gjenoppretting forklarer hvorfor vellykkede jobber alene ikke er tilstrekkelig.

Start Vaultwarden uten å skjule de viktige delene

Start Vaultwarden på en måte som holder ruten privat til bootstrap er fullfø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 prosessen går i en loop, sammenligner du brukeren imaget forventer, med eieren av hver monterte bane. Hvis den holder seg oppe, tester du port 80 lokalt og går deretter direkte til arbeidsflyten: logg på fra en nettleserutvidelse, opprett et element, synkroniser en ekstra klient, last opp et vedlegg og hent en Send etter en omstart. Lås image-versjonen først etter at denne ende-til-ende-testen er bestått, og dokumenter den nøyaktige konfigurasjonen ved siden av tjenesten.

Tegn runtime-grensen for Vaultwarden

Tegn tre grenser rundt Vaultwarden: ingress til port 80, persistent state og støttende krav. Containeren kan erstattes, men de to andre trenger tydelige eiere. Det eksterne kravet for Vaultwarden er fungerende SMTP dersom invitasjoner og e-post for emergency access er nødvendig. Test utgående DNS, TLS og leverandørens oppførsel uten å publisere en annen inngående tjeneste.

Diagrammet er komplett når en ren klient kan logge på fra en nettleserutvidelse, opprette et element, synkronisere en ekstra klient, laste opp et vedlegg og hente en Send etter en omstart. Samle inn tids- og ressursdata for vedleggsmengde, SQLite-skrivekonflikter eller begrensninger i databasepoolen, samt SMTP-forsinkelse under invitasjoner. Hvis transaksjonen mislykkes, viser den første grensen som ikke oppfører seg som dokumentert, om du bør undersøke ruting, lokal kapasitet eller en støttetjeneste.

Hold interne og eksterne URL-er adskilt

Unngå midlertidige og permanente offentlige origins for Vaultwarden. Sett i stedet DOMAIN til den nøyaktige eksterne HTTPS-originen, pek det valgte DNS-navnet til plattformruten og proxyer bare til port 80.

Test denne handlingen utenfra verten: logg på fra en nettleserutvidelse, opprett et element, synkroniser en ekstra klient, last opp et vedlegg og hent en Send etter en omstart. Hvis ingress mislykkes, dekker veiledningen for feilsøking av 502 feil med porter og lyttere. Hvis Vaultwarden mottar forespørselen, men DOMAIN er HTTP mens nettleseren krever en sikker origin for vault-funksjoner, peker bevisene nå forbi proxyen.

En produksjonsgodkjenning for Vaultwarden

En produksjonsport for Vaultwarden bør kunne gjennomføres av noen som ikke bygget distribusjonen. Gi personen den låste versjonen, en ikke-sensitiv testkonto og denne oppgaven: logg på fra en nettleserutvidelse, opprett et element, synkroniser en ekstra klient, last opp et vedlegg og hent en Send etter en omstart. Hvis instruksjonene krever udokumentert shell-tilgang, er tjenesten ennå ikke driftsklar.

Gjenta testen etter å ha erstattet bare containeren. Gjenopprett deretter databasen, vedleggene, sends, nøklene og konfigurasjonen i /data til blank infrastruktur, og bevis at vault-elementer, vedlegg, Sends og organisasjonstilhørighet synkroniseres korrekt til en ren klient etter gjenoppretting. Mål vedleggsmengde, SQLite-skrivekonflikter eller begrensninger i databasepoolen, samt SMTP-forsinkelse under invitasjoner, under begge vellykkede kjøringer; uventede forskjeller avdekker ofte en manglende cache, indeks, worker eller datamontering.

Legg til en feiløvelse: blokker midlertidig testbanen som brukes av fungerende SMTP når invitasjoner og e-post for emergency access er nødvendig. Vaultwarden skal rapportere en nyttig feil, bevare eksisterende state og gjenopprettes når den gyldige tilstanden kommer tilbake. Lagre tidsstemplene og relevante logglinjer, med hemmeligheter maskert. Dette bevismaterialet blir referansen for neste image- eller konfigurasjonsendring.

Følg med på arbeidsbelastningen, ikke bare containeren

En grønn container er nødvendig, men ikke tilstrekkelig. Tjenestens indikator er vellykket gjennomføring av «logg på fra en nettleserutvidelse, opprett et element, synkroniser en ekstra klient, last opp et vedlegg og hent en Send etter en omstart», mens de sannsynlige belastningssignalene er vedleggsmengde, SQLite-skrivekonflikter eller begrensninger i databasepoolen, samt SMTP-forsinkelse under invitasjoner.

Endringsstyring er viktig fordi Vaultwarden-databasemigreringer og Bitwarden-klientkompatibilitet må kontrolleres samlet; rotasjon av ADMIN_TOKEN er en endring i administratortilgang, ikke en migrering av vault-data. Bevar det gamle imaget, test migreringer på en kopi av state og dokumenter om rollback støttes etter at schemaet er flyttet. Hvis DOMAIN er HTTP mens nettleseren krever en sikker origin for vault-funksjoner, undersøker du den første grensen som avviker fra det fungerende miljøet.

Avslutt midlertidig oppsettstilgang

En sikker Vaultwarden-distribusjon begynner med å fjerne tilgang og privilegier. Unngå å bruke et svakt admin-token eller la registreringer stå åpne; deaktiver i stedet åpne registreringer når onboarding er fullført, beskytt admin-siden med et sterkt token og krev HTTPS for alle vault-klienter.

Bytt ut eksempelverdien for ADMIN_TOKEN umiddelbart, lagre den utenfor imaget og roter den som en administratorkredential hvis den blir eksponert. Begrens administrative ruter, bruk privat DNS for avhengigheter og gå gjennom hver bind mount. Når logger sendes til et sentralt system, filtrerer du bort hemmeligheter og privat innhold før de forlater serveren.

Bruk Dockup for plattformlaget

Dockup fjerner manuelt arbeid med reverse proxy og livssyklus rundt Vaultwarden. Tjenesten får en stabil HTTPS-rute til port 80, injisert konfigurasjon og persistent storage når den erstattes. En tilkoblet kundeserver følger samme modell som compute som driftes av Dockup.

Etter oppstart må du oppfylle applikasjonskontrakten: sett DOMAIN til den nøyaktige eksterne HTTPS-originen, tillat og verifiser fungerende SMTP dersom invitasjoner og e-post for emergency access er nødvendig, og kjør denne testen: logg på fra en nettleserutvidelse, opprett et element, synkroniser en ekstra klient, last opp et vedlegg og hent en Send etter en omstart. Slik forblir one-click-opplevelsen nyttig uten å skjule detaljene som gjør Vaultwarden gjenopprettbart og sikkert.

Ofte stilte spørsmål

Hva trenger Vaultwarden for en produksjonsdistribusjon?

Rout Vaultwarden-containeren på port 80 gjennom én HTTPS-origin. Det eksterne leveringskravet er fungerende SMTP dersom invitasjoner og e-post for emergency access er nødvendig. Ikke erklær Vaultwarden klar før du kan logge på fra en nettleserutvidelse, opprette et element, synkronisere en ekstra klient, laste opp et vedlegg og hente en Send etter en omstart.

Hvilke Vaultwarden-data skal inngå i en sikkerhetskopi?

Bevar /data og inkluder databasen, vedleggene, sends, nøklene og konfigurasjonen i /data i det samme gjenopprettingsmanifestet. En ren Vaultwarden-gjenoppretting er bare godkjent når vault-elementer, vedlegg, Sends og organisasjonstilhørighet synkroniseres korrekt til en ren klient etter gjenoppretting.

Krever Vaultwarden HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige Vaultwarden-originen, og behold port 80 på den interne ruten. Bruk Vaultwarden-innstillingen korrekt: sett DOMAIN til den nøyaktige eksterne HTTPS-originen. For Vaultwarden beskytter HTTPS påloggingsinformasjon eller brukerinnhold under overføring og sørger for konsistent klientoppførsel som er avhengig av origin.

Hvordan bør en Vaultwarden-oppgradering testes?

Gjenopprett gjeldende Vaultwarden-state i en isolert distribusjon, bruk kandidatversjonen og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom fordi Vaultwarden-databasemigreringer og Bitwarden-klientkompatibilitet må kontrolleres samlet; rotasjon av ADMIN_TOKEN er en endring i administratortilgang, ikke en migrering av vault-data. Behold det forrige Vaultwarden-imaget til grensen for datamigrering og rollback er forstått.