Vaultwarden zelf hosten in 2026: domeinen, SMTP en veilige back-ups

Er zijn twee versies van ‘Vaultwarden draaien’: er bestaat een container, of de service doet daadwerkelijk waarvoor hij bedoeld is. Alleen dat tweede telt. Het bewijs bestaat hieruit dat je kunt inloggen vanuit een browserextensie, een item kunt aanmaken, een tweede client kunt synchroniseren, een bijlage kunt uploaden en na een herstart een Send kunt ophalen.

Vaultwarden is bedoeld als compacte, met Bitwarden compatibele wachtwoordserver. De deployment moet de onderdelen achter dat gedrag behouden; een poort, een volume en een certificaat zijn invoer, niet het resultaat.

Volumes zijn alleen de eerste herstel-laag

De complete herstelset bestaat uit de database, bijlagen, sends, sleutels en configuratie in /data. Koppel /data vóór de bootstrap, schrijf onschuldige testdata en vervang de container om te bewijzen dat dit pad daadwerkelijk persistent is. Een volume beschermt data tegen het vervangen van een container, maar niet tegen verlies van de host, onbedoelde verwijdering of corruptie op applicatieniveau.

Maak back-ups die rekening houden met de databron: gebruik waar nodig logical dumps voor live databases en kopieer bestanden alleen vanuit een consistente toestand. Bewaar één versleutelde kopie buiten de Vaultwarden-host. Het acceptatiecriterium voor een restore is specifiek: vault-items, bijlagen, Sends en lidmaatschap van organisaties synchroniseren na de restore correct naar een schone client. De handleiding voor geteste restores legt uit waarom alleen het slagen van een job niet voldoende is.

Start Vaultwarden zonder de bewegende onderdelen te verbergen

Start Vaultwarden op een manier waarbij de route privé blijft totdat de bootstrap is voltooid.

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

Als het proces blijft herstarten, vergelijk dan de verwachte user van de image met de eigenaar van elk gekoppeld pad. Als de container actief blijft, test je lokaal poort 80 en ga je daarna direct door naar de workflow: log in vanuit een browserextensie, maak een item aan, synchroniseer een tweede client, upload een bijlage en haal na een herstart een Send op. Pin de imageversie pas nadat deze end-to-endcontrole slaagt en leg de exacte configuratie naast de service vast.

Breng de runtimegrenzen van Vaultwarden in kaart

Breng drie grenzen rond Vaultwarden in kaart: ingress naar poort 80, persistente state en ondersteunende vereisten. De container kan worden vervangen, maar voor de andere twee zijn expliciete eigenaars nodig. De externe vereiste voor Vaultwarden is werkende SMTP als uitnodigingen en e-mail voor emergency access nodig zijn. Test uitgaande DNS, TLS en het gedrag van de provider zonder een extra inkomende service te publiceren.

Het diagram is compleet wanneer een schone client kan inloggen vanuit een browserextensie, een item kan aanmaken, een tweede client kan synchroniseren, een bijlage kan uploaden en na een herstart een Send kan ophalen. Verzamel timing- en resourcegegevens voor het volume aan bijlagen, SQLite-write contention of limieten van de databasepool, en SMTP-latency tijdens uitnodigingen. Als de transactie mislukt, geeft de eerste grens die zich niet gedraagt zoals gedocumenteerd aan of je routing, lokale capaciteit of een ondersteunende service moet onderzoeken.

Houd interne en externe URL's uit elkaar

Vermijd tijdelijke en permanente publieke origins voor Vaultwarden. Stel in plaats daarvan DOMAIN in op de exacte externe HTTPS-origin, laat de gekozen DNS-naam naar de platformroute verwijzen en proxy alleen naar poort 80.

Voer deze actie uit buiten de host: log in vanuit een browserextensie, maak een item aan, synchroniseer een tweede client, upload een bijlage en haal na een herstart een Send op. Als ingress mislukt, behandelt de handleiding voor het oplossen van 502-fouten fouten met poorten en listeners. Als Vaultwarden het verzoek ontvangt maar DOMAIN HTTP is terwijl de browser een secure origin vereist voor vault-functies, wijst het bewijs nu verder dan de proxy.

Een productieacceptatietest voor Vaultwarden

Een productiegate voor Vaultwarden moet uitvoerbaar zijn door iemand die de deployment niet heeft gebouwd. Geef die persoon de gepinde versie, een niet-gevoelig testaccount en deze taak: log in vanuit een browserextensie, maak een item aan, synchroniseer een tweede client, upload een bijlage en haal na een herstart een Send op. Als de instructies ongedocumenteerde shell-toegang vereisen, is de service operationeel nog niet klaar.

Herhaal de gate nadat je alleen de container hebt vervangen. Restore daarna de database, bijlagen, sends, sleutels en configuratie in /data naar lege infrastructuur en bewijs dat vault-items, bijlagen, Sends en lidmaatschap van organisaties na de restore correct naar een schone client synchroniseren. Meet tijdens beide succesvolle runs het volume aan bijlagen, SQLite-write contention of limieten van de databasepool, en SMTP-latency tijdens uitnodigingen; onverwachte verschillen wijzen vaak op een ontbrekende cache, index, worker of datamount.

Voeg een failure drill toe: blokkeer tijdelijk het testpad dat door werkende SMTP wordt gebruikt als uitnodigingen en e-mail voor emergency access nodig zijn. Vaultwarden moet een bruikbare foutmelding geven, de bestaande state behouden en herstellen zodra de geldige toestand terugkeert. Sla de timestamps en relevante logregels op, waarbij je secrets redigeert. Dat bewijs wordt de referentie voor de volgende wijziging aan de image of configuratie.

Bewaak de workload, niet alleen de container

Een groene container is noodzakelijk, maar niet voldoende. De service-level indicator is het succesvol voltooien van ‘inloggen vanuit een browserextensie, een item aanmaken, een tweede client synchroniseren, een bijlage uploaden en na een herstart een Send ophalen’, terwijl het volume aan bijlagen, SQLite-write contention of limieten van de databasepool, en SMTP-latency tijdens uitnodigingen de waarschijnlijke druksignalen zijn.

Change control is belangrijk omdat Vaultwarden-databasemigraties en Bitwarden-clientcompatibiliteit gezamenlijk moeten worden gecontroleerd; het roteren van ADMIN_TOKEN is een wijziging in administrator-toegang, geen migratie van vault-data. Bewaar de oude image, test migraties op een kopie van de state en documenteer of rollback wordt ondersteund nadat het schema is gewijzigd. Als DOMAIN HTTP is terwijl de browser een secure origin vereist voor vault-functies, onderzoek je de eerste grens die afwijkt van de werkende omgeving.

Tijdelijke toegang voor de setup afsluiten

Een veilige Vaultwarden-deployment begint met het verwijderen van bevoegdheden. Gebruik geen zwak admin-token en laat sign-ups niet openstaan; schakel open sign-up uit zodra de inschrijving is voltooid, beveilig de adminpagina met een sterk token en vereist HTTPS voor elke vault-client.

Vervang de voorbeeldwaarde van ADMIN_TOKEN onmiddellijk, sla deze buiten de image op en roteer het token zoals een administratorcredential als het is blootgesteld. Beperk administratieve routes, gebruik private DNS voor dependencies en controleer elke bind mount. Wanneer logs centraal worden verzonden, filter je secrets en private content voordat ze de server verlaten.

Gebruik Dockup voor de platformlaag

Dockup neemt het handmatige werk rond reverse proxy en lifecycle voor Vaultwarden uit handen. De service krijgt tijdens vervangingen een stabiele HTTPS-route naar 80, geïnjecteerde configuratie en persistente storage. Een gekoppelde klantserver volgt hetzelfde model als compute die door Dockup wordt gehost.

Voldoe na de launch aan het applicatiecontract: stel DOMAIN in op de exacte externe HTTPS-origin, sta werkende SMTP toe en verifieer deze als uitnodigingen en e-mail voor emergency access nodig zijn, en voer dit bewijs uit: log in vanuit een browserextensie, maak een item aan, synchroniseer een tweede client, upload een bijlage en haal na een herstart een Send op. Zo blijft de one-click-ervaring bruikbaar zonder de details af te vlakken die Vaultwarden herstelbaar en veilig maken.

Veelgestelde vragen

Wat heeft Vaultwarden nodig voor een productiedeployment?

Routeer de Vaultwarden-container op poort 80 via één HTTPS-origin. De externe leveringsvereiste is werkende SMTP als uitnodigingen en e-mail voor emergency access nodig zijn. Beschouw Vaultwarden pas als gereed wanneer je kunt inloggen vanuit een browserextensie, een item kunt aanmaken, een tweede client kunt synchroniseren, een bijlage kunt uploaden en na een herstart een Send kunt ophalen.

Welke Vaultwarden-data hoort in een back-up?

Maak /data persistent en neem de database, bijlagen, sends, sleutels en configuratie in /data op in hetzelfde herstelmanifest. Een schone Vaultwarden-restore is pas geslaagd wanneer vault-items, bijlagen, Sends en lidmaatschap van organisaties na de restore correct naar een schone client synchroniseren.

Heeft Vaultwarden HTTPS achter een reverse proxy nodig?

Gebruik HTTPS voor de publieke Vaultwarden-origin en houd poort 80 op de interne route. Pas de Vaultwarden-instelling correct toe: stel DOMAIN in op de exacte externe HTTPS-origin. Voor Vaultwarden beschermt HTTPS credentials of gebruikerscontent tijdens transport en zorgt het ervoor dat origin-afhankelijk clientgedrag consistent blijft.

Hoe moet een Vaultwarden-upgrade worden getest?

Restore de huidige Vaultwarden-state naar een geïsoleerde deployment, pas de kandidaatversie toe en herhaal de acceptatietransactie. Let hier extra op, omdat Vaultwarden-databasemigraties en Bitwarden-clientcompatibiliteit gezamenlijk moeten worden gecontroleerd; het roteren van ADMIN_TOKEN is een wijziging in administrator-toegang, geen migratie van vault-data. Houd de vorige Vaultwarden-image beschikbaar totdat de grenzen voor datamigratie en rollback duidelijk zijn.