Vaultwarden Docker Compose Setup: Secure It Before First Login

Treat TLS, backups, SMTP, and the admin token as operational controls. This sequence keeps a small deployment usable while limiting avoidable exposure.

Table of Contents

This guide covers the decision, preflight checks, Compose configuration, HTTPS, first-account setup, verification, backups, updates, rollback, and failures.

• Decide first
• Preflight
• Compose file explained
• TLS and reverse proxy
• Create the account, then close signups
• Verify clients and WebSocket behavior
• Backup
• Update and rollback
• Common failures
• Choose the next step
• Frequently Asked Questions

Decide first

Vaultwarden is a lightweight, self-hosted server compatible with Bitwarden clients. It is unofficial and not associated with Bitwarden, so you own storage, HTTPS, backups, updates, and account access. Review the official project README before choosing it.

Use this rule:

• Choose Vaultwarden for a compact homelab or small-team deployment you can operate.
• Choose the official Bitwarden Server when official project identity matters most.
• Browse the password-manager directory when comparing options.

A container running on a local port is not a finished password-manager deployment. The public URL, reverse proxy, persistent storage, signup state, and recovery plan all matter.

Preflight

Before creating an account, confirm that:

• A hostname resolves to the reverse proxy or server publishing Vaultwarden.
• The final HTTPS URL is known and will match DOMAIN exactly.
• /data is mapped to durable storage.
• The proxy can issue and renew certificates.
• The /data storage is included in a backup plan.
• SMTP credentials and any admin token have private storage.
• Public signup can be closed immediately after the first account is created.

The official Using Docker Compose guidance uses /data, sets DOMAIN, and recommends disabling SIGNUPS_ALLOWED after account creation. Make these initial-run controls part of the deployment plan.

Compose file explained

Define one Vaultwarden service, persist /data, set the public DOMAIN, and control signup state through environment settings.

Compose concern	Decision	Reason
Image	Use the image from the official example	Aligns with project guidance
Storage	Mount durable storage at /data	Preserves data across replacement
DOMAIN	Set the exact HTTPS URL	Keeps clients and server consistent
SIGNUPS_ALLOWED	Enable only during setup	Removes open registration afterward
Restart behavior	Restart after routine interruptions	Reduces manual recovery
Network	Join the proxy network	Avoids an unnecessary public app port

Render the configuration first:

docker compose config

Confirm the storage mapping and environment values, then start the service:

docker compose up -d
docker compose ps

A running container proves only that the process started. The proxy, URL, signup, and backup decisions still determine whether the deployment is ready. Use Using Docker Compose as the project baseline.

TLS and reverse proxy

Put Vaultwarden behind an HTTPS reverse proxy before storing real credentials. The proxy must forward normal HTTP traffic and WebSocket traffic, and the public URL must match DOMAIN.

Use this workflow:

1. Create the DNS record for the hostname.
2. Configure TLS termination and certificate renewal.
3. Forward requests to Vaultwarden over the internal network.
4. Preserve the host and forwarding information expected by the application.
5. Enable WebSocket support.
6. Open the public HTTPS URL and inspect the certificate.

Do not use an unencrypted public endpoint as the normal client URL. HTTPS protects credentials in transit and avoids relying on a local-network assumption that may fail for mobile devices, remote users, or shared Wi-Fi. Adapt the relevant configuration from the project’s Proxy examples.

Create the account, then close signups

Create the intended primary account while signups are enabled. Verify it, then close registration:

1. Start the Compose project with signup enabled.
2. Open the HTTPS DOMAIN in a browser.
3. Create the first account with a strong, unique master password.
4. Sign in and confirm that the web vault loads.
5. Set SIGNUPS_ALLOWED to false.
6. Restart or recreate the service so the change is applied.
7. Confirm that a new registration attempt is rejected.

Closing signup is an access-control step. If another user needs access, use the supported invitation or organization workflow instead of leaving public registration open.

SMTP credentials and the admin token are secrets. Keep them out of screenshots, shared notes, and copied logs. Test SMTP with a controlled account after HTTPS works, because a broken mail path can resemble an authentication problem. Keep administrative access private unless it is intentionally protected; the Proxy examples include relevant security considerations.