Vaultwarden vs Bitwarden Self-Hosted: Choose Your Vault

Decide whether owning the server solves your problem

A self-hosted password manager makes sense when controlling the deployment is a requirement you can explain. Perhaps you need to choose where backups live or integrate the service into an existing operational policy. If your reason is simply that you already have a VPS, we would keep the vault in Bitwarden Cloud.

Your password manager sits underneath other operational work. Losing access during a server incident can stop you reaching the accounts needed to repair that incident. Treat that dependency more seriously than the convenience of adding another container.

Self-hosting also does not remove outside dependencies. You still depend on your infrastructure provider, and usually on domain registration and email delivery. Write down what control you gain and what operational work you accept before choosing an implementation.

Separate Vaultwarden from official Bitwarden deployments

Vaultwarden is an independent server implementation written in Rust that works with official Bitwarden clients. It is not a configuration option inside the official server, and Bitwarden does not provide its support. The Vaultwarden project directs users to its own community channels for problems.

That distinction matters when an application update changes behavior. You need to determine whether the problem belongs to the client or the compatible server before asking for help. We would accept that responsibility for a personal deployment; we would be more cautious when coworkers depend on a defined support arrangement.

Do not assume official Bitwarden always means a large collection of containers. Its self-hosting documentation includes Bitwarden Lite, a single-container option intended for personal use and lightweight sharing, alongside the standard deployment. Compare the deployment you would actually operate rather than dismissing every official option as too heavy.

For Vaultwarden on a single VPS running Ubuntu 24.04 LTS, we would start with SQLite and Docker Compose. Adding a separate database service creates another recovery dependency without automatically improving your deployment. If you choose official Bitwarden, follow the database and backup requirements of that specific deployment method.

Choose support and features before choosing a container

Write down the workflows your household or team actually needs. Shared credentials may be straightforward, while organizational recovery and identity integration need closer inspection. A feature with a familiar name is not enough evidence that your required workflow behaves identically.

• For personal use, verify browser autofill and mobile access with your normal devices.
• For shared vaults, verify invitations, collection permissions and removal of a departing member.
• For organizational controls, verify the exact policy behavior and recovery permissions you require.
• For support, decide who diagnoses a failed client update and which project or vendor will handle the report.

Hosting the official server does not automatically unlock every Bitwarden capability. Some features require a license file associated with a subscription, as explained in the self-hosted licensing documentation. Confirm those requirements before building an organizational rollout around an assumed entitlement.

We would choose official Bitwarden when the organization needs its documented behavior and an applicable vendor support arrangement. We would choose Vaultwarden when its supported workflows fit and someone explicitly owns compatibility problems. Neither decision should depend on a promise that every future client feature will work immediately.

Design the VPS around a small attack surface

For Vaultwarden, use a persistent data directory and put the application behind an HTTPS reverse proxy. Its web vault requires a secure browser context. With a proxy running directly on the host, bind the application port to loopback so the public path goes through the proxy.

Keep the vault away from experimental applications that frequently change privileges or mounts. A separate VPS can make the boundary easier to understand, although it still requires maintenance. When choosing a machine, prioritize recoverable storage and dependable console access in your Docker hosting selection.

Our Docker Compose production checklist covers service ownership and persistent storage. Use the Caddy versus Nginx guide to choose a proxy you can maintain. Avoid changing the proxy and the vault application during the same maintenance window, because failures become harder to isolate.

• Close public registration after the intended accounts exist, then verify that an unrelated visitor cannot register.
• Keep administrative endpoints private where practical and require strong authentication whenever they are enabled.
• Enable multifactor authentication and store recovery material somewhere accessible without the vault.
• Configure and verify email delivery for the workflows you intend to use.

Encrypted vault storage does not make a compromised server harmless. An attacker controlling the web application could alter what a browser receives, while stolen encrypted data can remain a target for password guessing. Infrastructure control helps only when you maintain the infrastructure.

Make recovery independent of the running vault

Prepare recovery access before importing valuable credentials. You need a way to reach the VPS provider and retrieve backups when the vault itself is unavailable. Keep the necessary recovery instructions and authentication material outside that dependency.

For Vaultwarden with SQLite, use a database-aware backup rather than copying only the live database file. Attachments live outside the database, and configuration can contain sensitive credentials. The Vaultwarden backup documentation explains which files belong in a recoverable backup.

For a small deployment, we prefer a brief planned stop while capturing the complete persistent data directory when that interruption is acceptable. A live database backup is also possible, but you must account for associated files changing during the capture. Whichever approach you choose, encrypt the backup and keep a copy outside the VPS.

Use your chosen official Bitwarden deployment's documented backup procedure rather than applying Vaultwarden file assumptions to it. In either case, server restoration and account recovery solve different problems. Restoring encrypted data does not supply a forgotten master password.

1. Restore a backup into an isolated temporary deployment with outbound email disabled and access restricted.
2. Sign in with a disposable test account and inspect an item that existed before the backup.
3. Open a restored attachment and verify access to a shared item if those workflows are enabled.
4. Record the procedure and keep its location accessible without signing into the production vault.

A backup job reporting success proves less than a restore you can complete. Schedule another drill after changes to storage or backup tooling. Our VPS backup guide explains how to keep recovery separate from the machine you might lose.

Keep updates and Claude Code within explicit limits

Use a deliberately selected container image digest and review updates regularly. Pinning makes changes intentional, but it is not permission to leave security fixes unattended. Keep the previous image reference and a compatible pre-update backup together.

Before an update, confirm that the backup is available outside the server and review migration notes. Afterward, verify a fresh sign-in and synchronization between your normal clients. If the application migrated its database, rolling back the image alone may be insufficient, so prepare restoration of the matching data.

We recommend Claude Code for bounded operational work such as reviewing a Compose diff or investigating a failed health check. Give it redacted configuration and an explicit command scope. Keep decrypted vault contents and recovery codes out of its context.

Keep the approval boundary at actions that change access or persistent data. An agent can propose an update and prepare verification steps, while a human authorizes the maintenance window. Treat Docker socket access as privileged host access, and use SSH guardrails for an agent with a key before allowing remote operations.

Run a disposable pilot before moving your real passwords

Create a pilot deployment containing invented credentials and a harmless attachment. Keep your current password manager authoritative while you evaluate it. The pilot should answer whether you can operate the service and whether your daily clients behave as expected.

1. Choose the candidate that matches your support requirements and deploy it with HTTPS.
2. Configure the self-hosted server address in each client you actually use, then create and edit dummy entries across devices.
3. Verify multifactor sign-in, sharing permissions and email workflows that apply to your deployment.
4. Back up the pilot, restore it in isolation and complete the recovery checks before importing real credentials.

When you migrate, check the export format's coverage rather than assuming attachments and every item type transfer automatically. Treat any unencrypted export as a sensitive temporary file and avoid placing it in a broadly synchronized folder. Reconcile the imported data before retiring the old vault, then remove temporary migration files.