How to Self-Host Vaultwarden in 2026: Domains, SMTP and Secure Backups

There are two versions of “running Vaultwarden”: a container exists, or the service completes its real job. Only the second matters. Here the proof is to sign in from a browser extension, create an item, sync a second client, upload an attachment and retrieve a Send after restart.

Vaultwarden serves this purpose: compact Bitwarden-compatible password server. The deployment has to preserve the pieces behind that behavior; a port, a volume and a certificate are inputs, not the result.

Volumes are only the first recovery layer

The durable recovery set is the database, attachments, sends, keys and configuration in /data. Mount /data before bootstrap, write harmless sample data and replace the container to prove that path is actually persistent. A volume protects data from container replacement, but not from host loss, accidental deletion or application-level corruption.

Take backups that understand the data source: use logical dumps for live databases when required and copy files only from a consistent state. Keep one encrypted copy away from the Vaultwarden host. The acceptance criterion for a restore is specific — vault items, attachments, Sends and organization membership sync correctly to a clean client after restore. The restore-tested backup guide explains why job success alone is insufficient.

Start Vaultwarden without hiding the moving parts

Start Vaultwarden in a way that leaves the route private until bootstrap is complete.

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

If the process loops, compare the image's expected user with the owner of each mounted path. If it stays up, test port 80 locally and then move directly to the workflow: sign in from a browser extension, create an item, sync a second client, upload an attachment and retrieve a Send after restart. Version-pin the image only after that end-to-end check passes, and record the exact configuration beside the service.

Draw the Vaultwarden runtime boundary

Draw three boundaries around Vaultwarden: ingress to port 80, durable state and supporting requirements. The container is replaceable, but the other two need explicit owners. The external requirement for Vaultwarden is working SMTP if invitations and emergency access mail are required. Test outbound DNS, TLS and provider behavior without publishing another inbound service.

The diagram is complete when a clean client can sign in from a browser extension, create an item, sync a second client, upload an attachment and retrieve a Send after restart. Capture timing and resource data for attachment volume, SQLite write contention or database pool limits, and SMTP latency during invitations. If the transaction fails, the first boundary that does not behave as documented identifies whether to investigate routing, local capacity or a supporting service.

Keep internal and external URLs straight

Avoid temporary and permanent public origins for Vaultwarden. Instead, set DOMAIN to the exact external HTTPS origin, point the chosen DNS name at the platform route and proxy only to port 80.

Exercise this action from outside the host: sign in from a browser extension, create an item, sync a second client, upload an attachment and retrieve a Send after restart. If ingress fails, the 502 troubleshooting guide covers port and listener mistakes. If Vaultwarden receives the request but DOMAIN is HTTP while the browser requires a secure origin for vault features, the evidence now points beyond the proxy.

A production acceptance run for Vaultwarden

A production gate for Vaultwarden should be executable by someone who did not build the deployment. Give that person the pinned version, a non-sensitive test account and this task: sign in from a browser extension, create an item, sync a second client, upload an attachment and retrieve a Send after restart. If the instructions require undocumented shell access, the service is not yet operationally ready.

Repeat the gate after replacing only the container. Then restore the database, attachments, sends, keys and configuration in /data into blank infrastructure and prove that vault items, attachments, Sends and organization membership sync correctly to a clean client after restore. Measure attachment volume, SQLite write contention or database pool limits, and SMTP latency during invitations during both successful runs; unexpected differences often reveal a missing cache, index, worker or data mount.

Add a failure drill: temporarily deny the test path used by working SMTP if invitations and emergency access mail are required. Vaultwarden should emit a useful error, preserve existing state and recover when the valid condition returns. Save the timestamps and relevant log lines, with secrets redacted. That evidence becomes the reference for the next image or configuration change.

Watch the workload, not only the container

A green container is necessary but not sufficient. The service-level indicator is successful completion of “sign in from a browser extension, create an item, sync a second client, upload an attachment and retrieve a Send after restart”, while the likely pressure signals are attachment volume, SQLite write contention or database pool limits, and SMTP latency during invitations.

Change control matters because Vaultwarden database migrations and Bitwarden client compatibility must be checked together; ADMIN_TOKEN rotation is an administrator-access change, not a vault-data migration. Preserve the old image, test migrations on copied state and document whether rollback is supported after the schema moves. If DOMAIN is HTTP while the browser requires a secure origin for vault features, diagnose the first boundary that differs from the working environment.

Close temporary setup access

A secure Vaultwarden deployment starts by removing authority. Avoid using a weak admin token or leaving sign-ups open; instead, disable open sign-up when enrollment ends, protect the admin page with a strong token and require HTTPS for every vault client.

Replace the sample ADMIN_TOKEN immediately, store it outside the image and rotate it like an administrator credential if it is exposed. Restrict administrative routes, use private DNS for dependencies and review every bind mount. When logs are shipped centrally, filter secrets and private content before they leave the server.

Use Dockup for the platform layer

Dockup removes manual reverse-proxy and lifecycle work around Vaultwarden. The service receives a stable HTTPS route to 80, injected configuration and persistent storage during replacements. An attached customer server follows the same model as Dockup-hosted compute.

After launch, satisfy the application contract: set DOMAIN to the exact external HTTPS origin, allow and verify working SMTP if invitations and emergency access mail are required and run this proof: sign in from a browser extension, create an item, sync a second client, upload an attachment and retrieve a Send after restart. This keeps the one-click experience useful without flattening the details that make Vaultwarden recoverable and secure.

Frequently asked questions

What does Vaultwarden need for a production deployment?

Route the Vaultwarden container on port 80 through one HTTPS origin. The external delivery requirement is working SMTP if invitations and emergency access mail are required. Do not call Vaultwarden ready until you can sign in from a browser extension, create an item, sync a second client, upload an attachment and retrieve a Send after restart.

Which Vaultwarden data belongs in a backup?

Persist /data and include the database, attachments, sends, keys and configuration in /data in the same recovery manifest. A clean Vaultwarden restore passes only when vault items, attachments, Sends and organization membership sync correctly to a clean client after restore.

Does Vaultwarden require HTTPS behind a reverse proxy?

Use HTTPS for the public Vaultwarden origin and keep port 80 on the internal route. Apply the Vaultwarden setting correctly: set DOMAIN to the exact external HTTPS origin. For Vaultwarden, HTTPS protects credentials or user content in transit and keeps origin-sensitive client behavior consistent.

How should a Vaultwarden upgrade be tested?

Restore current Vaultwarden state into an isolated deployment, apply the candidate version and repeat its acceptance transaction. Pay particular attention because Vaultwarden database migrations and Bitwarden client compatibility must be checked together; ADMIN_TOKEN rotation is an administrator-access change, not a vault-data migration. Keep the previous Vaultwarden image until its data-migration and rollback boundary are understood.