Self-Host Bitwarden With Docker: Standard and Lite

Self-hosting Bitwarden gives you a password manager server you operate on your own machine, rather than relying on Bitwarden’s hosted service. This guide covers Bitwarden’s official self-hosted Docker deployment and the community-maintained Vaultwarden project, often called Bitwarden Lite; they are different products with different support and setup requirements.

What You’ll Need

• A Linux server or virtual machine with a supported Docker Engine and Docker Compose plugin, plus a stable address and enough disk space for application data and backups.
• A domain name pointed at the server, and access to its firewall or router settings if users will connect from outside your network.
• A valid HTTPS setup for public access. Do not expose a password manager over plain HTTP.
• For official Bitwarden self-hosting, a Bitwarden account and installation ID and key obtained from Bitwarden’s self-hosting setup process. Review current licensing and deployment requirements before proceeding.
• For Vaultwarden, Docker and its Compose plugin. Vaultwarden is an independent, unofficial server implementation, not an official Bitwarden product.
• Basic familiarity with a terminal, SSH, Docker Compose, and editing a configuration file.

Step-by-Step

1. Choose the server deliberately. Decide between the official Bitwarden self-hosted server and Vaultwarden. The official server is the supported option and uses Bitwarden’s documented installer. Vaultwarden is a lighter, community-developed alternative that implements compatible client APIs; compatibility and features can differ, and Bitwarden does not provide support for it. Do not run both against the same data directory or public address.
2. Prepare the host. Install Docker Engine and the Docker Compose plugin using instructions for your Linux distribution. Create a dedicated directory for the deployment, restrict access to it, and confirm Docker works with docker --version and docker compose version. Keep the operating system and Docker packages updated.
3. Set up a domain and HTTPS route. Point a DNS record, such as vault.example.com, to your server’s public IP. Configure a maintained reverse proxy to obtain and renew a trusted TLS certificate, then proxy requests to the selected application. Open only the required ports: normally 80 and 443 for certificate validation and HTTPS, plus SSH restricted to trusted access. Do not expose Docker’s management socket or an unencrypted application port to the internet.
4. Install the official Bitwarden server, if that is your choice. Follow the current official self-host installation documentation rather than copying an old Compose file: the installer and configuration can change. Obtain the installation ID and key through Bitwarden’s self-hosting setup, download and run the official installation script from its documented source, and provide the requested domain and settings. Configure the installation to work behind your chosen HTTPS reverse proxy, using the current documented proxy options. Treat the ID, key, configuration files, and any generated secrets as sensitive.
5. Alternatively, deploy Vaultwarden. Create a Compose file in the deployment directory using the current Vaultwarden image documentation. Define a persistent volume for /data, set the public domain to your HTTPS URL, and configure any required options through environment variables documented for the image version you select. Keep the admin interface disabled unless you need it; if enabled, protect it with a strong secret and restrict access. Do not enable open sign-ups on a publicly reachable instance. Set a deliberate user-registration policy before inviting anyone.
6. Start the selected deployment. In the directory containing the Compose file, run docker compose pull and then docker compose up -d. For the official server, use its documented installer and management commands instead if it generates or manages Compose configuration. Check status with docker compose ps and inspect logs with docker compose logs; redact secrets before sharing log output.
7. Test from a client. Open the HTTPS domain in a browser and verify the certificate is valid. Create a test account only after confirming the registration policy. Install the Bitwarden browser extension or mobile app, choose the self-hosted server option, enter your full HTTPS server URL, and sign in. Test vault access and syncing before moving important passwords.
8. Secure accounts and plan recovery. Use unique, strong master passwords and enable available multifactor authentication. Ensure registration is closed or restricted once intended users are enrolled. Back up the application’s persistent data and configuration to a separate, protected location, and test restoring a backup. A running container is not a backup.
9. Maintain the service. Read release notes before updating. Back up data first, then update images or run the official installer’s documented update process. Check logs and test login and sync afterward. Use a secure, documented procedure to roll back if an update fails; do not delete volumes to troubleshoot.

Common Mistakes

• Treating Vaultwarden as an official “Lite” edition. It is a separate community project. Confirm its maintenance status, compatibility, and risk suitability before entrusting it with a vault.
• Using HTTP or a mismatched server URL. Set clients to the exact HTTPS domain, including any path if your proxy uses one. A certificate warning is a stop signal, not something to ignore.
• Failing to persist data. Without a persistent volume or correct official-server data path, recreating a container can lose the vault.
• Leaving registration or administration exposed. Restrict sign-ups and protect or disable administrative interfaces. Do not publish secrets in a repository or support post.
• Updating without a backup. Back up first and verify that the backup can be restored. Avoid unpinned, unattended changes to production images.

Tips

• Use a dedicated host or isolated virtual machine, keep inbound access minimal, and use SSH keys and updates for host administration.
• Store Compose files and proxy configuration with tight permissions, but keep passwords, API tokens, and private keys out of public version control.
• Document the domain, data locations, backup schedule, and recovery steps somewhere you can access if the server is unavailable.
• Use a separate test account and verify recovery before relying on the service for your only copy of credentials.

Troubleshooting

Domain does not load: Check DNS resolution and the server’s public IP, then confirm the router and host firewall allow the required web ports. If you are behind carrier-grade NAT, ordinary port forwarding may not work; use a suitable hosting or private-access arrangement instead.

Certificate or HTTPS error: Confirm the DNS record points to the right host, ports needed for certificate validation are reachable, and the reverse proxy is configured for the same hostname. Check the proxy’s certificate-renewal logs. Do not bypass certificate validation.

Container exits or returns a gateway error: Run docker compose ps and inspect service logs. Check for invalid environment variables, port conflicts, incorrect proxy targets, and file permission problems on persistent data. Follow the selected project’s documentation for the exact settings; avoid changing ownership blindly.

Client cannot connect or sync: Enter the full HTTPS server URL in the client’s self-hosted server setting, then test that URL in a browser. Check proxy headers and WebSocket or request-size requirements against the project’s current documentation. Confirm the client and server versions are compatible.

Vault data appears missing: Stop before deleting or recreating volumes. Check that the expected persistent volume is mounted and that the service is using the intended data directory. Restore only from a known-good backup using the project’s documented recovery procedure.

Frequently Asked Questions

Is Vaultwarden the official Bitwarden Lite server?
No. Vaultwarden is an independent, unofficial implementation compatible with many Bitwarden clients. Bitwarden’s official self-hosted server is a separate deployment.

Can I use the Bitwarden apps with a self-hosted server?
Many official Bitwarden clients support connecting to a self-hosted server. Set the server URL before signing in, and check compatibility with your chosen server.

Do I need a domain name?
A domain is strongly recommended for reliable HTTPS and client access. Publicly trusted certificates generally require a hostname you control.

Can I run this only on my home network?
Yes, if clients can reach the server over a protected connection. Configure HTTPS and network access carefully; local-only does not remove the need for backups or updates.

Will Docker keep my vault safe if the server fails?
No. Docker runs the service but does not automatically provide a recoverable backup. Back up persistent data and configuration separately, protect the copies, and test restoration.

Related

• On-Device LLMs: How Hybrid AI Balances Privacy and Power
• Deno 2.5, Pragmatic Turn, Bytes and 423 Explained
• Convert AVI to PSP: Format, Settings, and Transfer