Self-hosted Bitwarden vs Vaultwarden: which to choose

Self-hosted Bitwarden vs Vaultwarden: when each one fits

Vaultwarden fits small, lightly regulated groups that accept community support and will run their own backups. Official self-hosted Bitwarden fits organizations that need licensed enterprise features and a vendor support path. Both servers are compatible with the Bitwarden clients, so the choice turns on four things: which paid features you need, what support obligations you carry, how much resource budget you can give the server, and which database you must run. Both server codebases are licensed under AGPL-3.0, but the official paid modules in the bitwarden_license directory, including the SSO integration modules, fall under the Bitwarden License, a source-available license that is not open source under the OSI definition. Production use of that code requires a paid subscription, so the open-source label alone does not tell you what you will pay for.

Start by listing the features your organization must have on day one. Check the Admin Console, Billing and Subscription pages in the Bitwarden cloud web app to see which enterprise controls, policies and SSO options are tied to a license, and confirm the current terms with Bitwarden before you commit. Vaultwarden added single sign-on with OpenID Connect in version 1.35.0, released on December 27, 2025, and later releases through 1.37.3 added SSO fixes and settings such as SSO_SIGNUPS_ALLOWED. Test those settings against your identity provider in a staging instance rather than assuming parity with the licensed Bitwarden feature set. Then check your resource budget. The official Linux install guide sets a minimum of 2 GB of RAM and 12 GB of storage, and recommends 4 GB and 25 GB, while Vaultwarden is aimed at deployments where the heavier official service is not ideal.

Decide on support and databases last, because they carry the most risk. Vaultwarden's README asks users to report bugs to the Vaultwarden project rather than to Bitwarden's support channels, states that its maintainers cannot be held liable for data loss, and urges regular backups of files and the database. If your team cannot own that recovery work, Vaultwarden is a poor fit. On the database side, Vaultwarden uses SQLite by default and can use MySQL or PostgreSQL through DATABASE_URL, with PostgreSQL marked as recommended in its .env.template. The official standard installation ships an MSSQL Express image by default with a 10 GB database limit. Confirm which database your backup and audit processes already support before you choose, and ask Bitwarden for the support scope in writing if a vendor path is required.

Which platform fits which scenario

This table matches four common situations to the platform that usually fits better, and names the condition that would reverse the answer. Read each row as a starting point: the deciding factors are usually licensing needs, the support you require, and the hosting you can give the server.

Scenario	Better fit	Why, and what would change the answer
Small family or team, personal and shared vaults	Vaultwarden	Vaultwarden's README says its maintainers focus on individuals, families and small organizations, and it runs on modest hosts with SQLite by default. This changes if the team needs paid Bitwarden features or vendor-backed support.
Regulated organization needing auditable, supported software	Self-hosted Bitwarden	Bitwarden offers licensed paid features and vendor support, and Vaultwarden's README directs bug reports to its own project and disclaims liability for data loss. Production use of the Bitwarden License code requires a paid subscription, so budget for that from the start.
IT department with many users and directory sync	Self-hosted Bitwarden	Bitwarden's Directory Connector syncs AD, LDAP, Azure, Google Workspace or Okta users, and Vaultwarden also lists Directory Connector support. Confirm which directory features your license tier includes and test sync against your own directory before deciding.
Constrained host with limited memory and disk	Vaultwarden	Bitwarden's Linux install guide lists 2 GB of RAM as a minimum and recommends 4 GB, with Docker Engine 26 or later and a 10 GB MSSQL Express database limit. Vaultwarden is positioned as lighter-weight, but confirm your own sizing with a pilot, and remember that Bitwarden lite also exists for home labs but is not for business use.

How each server is built and deployed

Both servers speak the Bitwarden client API, but they are packaged very differently. The official server is a multi-container stack with a licensing and installation step, while Vaultwarden is a single service with lighter requirements. The choices below determine what you install, what you maintain and how upgrades reach your users.

Official standard multi-container installation

The official self-hosted deployment runs several containers and ships an MSSQL Express image by default, with a 10 GB database size limit. Before installing, you retrieve an installation ID and installation key using a valid email address from bitwarden.com/host. Confirm with Bitwarden how the bundled database limit affects your user count and attachment volume before you commit to the default layout.

Installation ID and key requirement

A standard Bitwarden installation cannot start without an installation ID and key tied to a valid email address. This identifier also links any paid feature license you later download from the cloud admin console, so it becomes part of your long-term operating record. Plan who holds that email account and where the credentials are stored, because a lost or orphaned identifier complicates licensing and support.

Lite single-container option

Bitwarden lite runs as one container and supports MSSQL, PostgreSQL, SQLite and MySQL or MariaDB, needing at least 200 MB of RAM. Bitwarden positions it for personal use and home labs rather than business use, so it is a poor fit for a company rollout even though it is simpler to start. Check the lite guide against your intended user count before choosing it for any shared team vault.

Vaultwarden single Rust service

Vaultwarden is one Rust service that uses SQLite by default, while its configuration template recommends PostgreSQL and accepts MySQL through the DATABASE_URL setting. Its project positions it for individuals, families and small organizations, and it is designed to be lighter than the official service. Decide early whether SQLite is acceptable for your team size, because moving databases later is an additional maintenance task.

Docker, resources and storage sizing

The official Linux install requires Docker Engine 26 or later, a 1.4 GHz x64 processor, and at least 2 GB of RAM and 12 GB of storage, with 4 GB of RAM and 25 GB recommended. Vaultwarden recommends installing from its container images on ghcr.io, docker.io or quay.io. Measure your own baseline in a pilot, since storage growth from attachments and logs depends on how your organization uses the vault.

HTTPS and reverse proxy requirement

Vaultwarden requires HTTPS for the web vault because the browser Web Crypto API depends on a secure context, and it recommends running behind a reverse proxy. Your certificate lifecycle, proxy configuration and renewal monitoring become part of the deployment, whichever server you choose. Confirm whether your platform team already operates a reverse proxy that meets this requirement before selecting Vaultwarden.

What is free and what needs a paid license

The main Bitwarden server code is licensed under AGPL-3.0, so the core server can be read, modified and run under that license. The files in the bitwarden_license directory, including Commercial.Core and the SSO integration modules, fall under the Bitwarden License instead. That license is source-available, and Bitwarden's license FAQ states it does not qualify as open source under the OSI definition. Code under the Bitwarden License may be used for development and testing, but production use requires a paid subscription.

Main server code: AGPL-3.0, outside the bitwarden_license directory.
Licensed modules: Commercial.Core and SSO integration code under the Bitwarden License.
Development and testing: permitted under the Bitwarden License without a subscription.
Production use of licensed code: requires a paid subscription.
Source-available status: the license is not open source under the OSI definition, so it cannot be treated as open source in procurement documents.

Before you commit, confirm with Bitwarden which features in your planned edition sit in the licensed directory and whether your production use case needs a subscription.

Capabilities side by side

This table compares the two servers on license, paid features, databases, SSO, directory sync, two-factor methods, organizations, event logs, Helm charts and release cadence. Use it to see which items need a Bitwarden license and which items to confirm with each project or vendor before you commit. The main takeaway is that Vaultwarden's features are community-supported, while Bitwarden's paid modules come with a license and vendor support.

Capability	Self-hosted Bitwarden	Vaultwarden
License	Server core under AGPL-3.0; bitwarden_license directory under the Bitwarden License	AGPL-3.0, with no paid tier or license file
Paid features	Require a license file tied to the installation ID, plus a paid subscription for production use	Feature set documented in the README; no vendor license required. Confirm any features you need
Supported databases	Standard install ships MSSQL Express by default with a 10 GB limit; confirm other options with Bitwarden	SQLite by default; MySQL or PostgreSQL through DATABASE_URL, with PostgreSQL marked recommended
SSO support	SSO integration modules sit in the Bitwarden License directory, so check they are covered by your subscription	OpenID Connect SSO added in 1.35.0; later releases through 1.37.3 added fixes and settings
Directory sync	Directory Connector (GPL-3.0) syncs AD, LDAP, Azure, Google Workspace or Okta users	README lists Directory Connector support; confirm the sources and version you plan to use
Two-factor methods	Confirm the full list for your edition with Bitwarden	Authenticator app, email, FIDO2 WebAuthn, YubiKey and Duo, plus emergency access
Organizations, collections, event logs	Organizations, collections and enterprise policies; confirm which event log and policy features need a license	Organizations with collections, member roles, groups, event logs and policies
Helm charts	Official charts in the bitwarden/helm-charts repository under AGPL-3.0	No supplied Helm chart fact; confirm with the project before planning Kubernetes
Release cadence	Monthly releases; server v2026.10.0 on October 14, 2026 and self-host v2026.10.0 on October 15, 2026	Latest supplied release is 1.37.4 on October 5, 2026, after 1.37.3 and 1.37.2

How SSO and directory sync differ in practice

The practical difference is where SSO sits and who maintains it. Vaultwarden 1.35.0 added single sign-on with OpenID Connect, and releases through 1.37.3 added SSO fixes and settings such as SSO_SIGNUPS_ALLOWED. Official Bitwarden SSO integration modules live in the bitwarden_license directory, which is under the Bitwarden License and requires a paid subscription for production use. Before you choose either path, confirm with each vendor which SSO protocols, claim mappings and enforcement policies your identity provider needs, because the feature sets are not the same and the supplied facts do not establish a full comparison. Test the login flow end to end with your actual provider, including first-time user sign-up, forced single sign-on, session expiry and what happens when the provider is unreachable.

Directory sync is a separate question from login. Bitwarden's Directory Connector, which syncs AD, LDAP, Azure, Google Workspace or Okta users, is GPL-3.0 and is the component to inspect for provisioning and deprovisioning. Vaultwarden's README lists Directory Connector support, so the client-side tool is not the differentiator. Run a test with a disposable group: add a user, move them between groups, remove them from the directory and confirm that the vault membership, collection access and account state change as your policy expects. Ask who fixes a sync defect in each stack, since the Vaultwarden README directs bug reports to the Vaultwarden project and not to Bitwarden support.

SSO gaps matter most when access is revoked late or when policies depend on the identity provider. If your offboarding process relies on the directory disabling an account, a sync or login gap can leave a former employee with a working vault session until the session expires. If your organization requires enforced single sign-on or relies on group-based roles, a missing or partially supported setting becomes a control gap rather than an inconvenience. Illustrative example: a team that disables a leaver in the identity provider but has no tested deprovisioning path should treat that as a blocking finding before go-live. Document the expected behavior for each scenario and keep the test results as evidence for your access review.

Moving between Vaultwarden and official Bitwarden

This sequence gives you a verified backup, a clean export, and a documented route into the official server, so you know exactly what carries over and what has to be rebuilt. No supplied fact documents a direct Vaultwarden to Bitwarden migration path, so confirm that route with Bitwarden before you commit to a date.

Back up the Vaultwarden database and files
The administrator takes a full copy of the Vaultwarden data directory and the database, whether SQLite, MySQL or PostgreSQL, before touching anything else. Vaultwarden's README says the maintainers cannot be held liable for data loss and highly recommends regular backups of files and the database, so this copy is the rollback point for the whole move. Done means a restore has been test-run on a separate host and the vault items, attachments and organization data open correctly there.
Confirm the target path with Bitwarden
The business owner or administrator asks Bitwarden in writing whether a direct import from a Vaultwarden instance is supported, and which export format and version of the official server it expects. No supplied fact documents this path, so the answer from Bitwarden decides whether the move is a direct import or a rebuild from exports. Done means the written answer, with the target server version, is filed with the change record.
Export vault and organization data
The administrator exports the personal vaults and organization data from Vaultwarden using the export tools in the web vault or admin tooling, then checks item counts against the source. Attachments, collection assignments and member lists may not travel with a standard export, so record them separately before the export is treated as complete. Done means each export file is stored with a checksum and a written inventory of item, collection and member counts.
Prepare the official server and its license
The team installs the official Bitwarden server, following the Linux install guide, and retrieves an installation ID and key with a valid email address from bitwarden.com/host. If paid features are needed, the organization administrator downloads a license file from the cloud web app and ties it to the installation ID, and the data region must match the cloud organization's region. Done means the self-hosted instance starts, the license is accepted, and an administrator account exists on the same email the team will use for import.
Import data into the official server
Using the path Bitwarden confirmed in step two, the administrator imports the exported data into the official instance under the matching account and organization. Imported vault items are checked against the inventory from the export step, with particular attention to organization collections and group assignments. Done means item and collection counts match the inventory and a sample of logins opens correctly from a client pointed at the new server.
Rebuild attachments, invitations and policies
Attachments, member invitations, enterprise policies and SSO must be redone on the official server, so the administrator re-uploads attachments from the saved copies and sends fresh invitations to members. Policies such as master password requirements and two-factor rules are reapplied in the admin console, and SSO is configured again against the identity provider, including its redirect and claim settings. Done means each item on the rebuild list is ticked off with a named owner and a test login by a pilot user.
Cut over clients and retire Vaultwarden
Users switch their clients and browser extensions to the new server address, and the Vaultwarden instance is kept in read-only status for a defined period agreed by the team. Support questions go to the channel that matches the server now in use, because Vaultwarden's README asks users to report its bugs to the Vaultwarden project, not to official Bitwarden support. Done means every pilot and production user has logged in on the new server, and the old backup set is retained under the agreed retention policy.

Who supports each when something breaks

Vaultwarden's own README sets the baseline for support: the project is not associated with Bitwarden or Bitwarden, Inc., one active maintainer is employed by Bitwarden and contributes on their own time, and bugs belong in the Vaultwarden project, not in Bitwarden's support channels. The maintainers state they cannot be held liable for data loss and highly recommend regular backups of files and the database. In practice, a Vaultwarden incident is a community issue handled on the project's schedule, and the operator carries the recovery risk.

Official Bitwarden self-hosting differs in who is accountable. The license file for paid features is tied to the installation ID and region, and paid organization features such as SSO depend on it, so a licensed customer has a contractual and commercial path that a community project does not offer. Confirm in writing with Bitwarden what support tier, response commitments, and escalation path come with your subscription, and whether support covers the self-hosted installation, the Helm charts, or only the cloud service. Do not assume either answer from the open-source license alone.

A regulated buyer should ask for specifics in writing before choosing either path. Request the named support tier, the channels and hours, the severity definitions and response targets, and whether the vendor will help restore from backup or only advise. Ask who patches the server and how quickly security fixes ship, and whether the Vaultwarden project or Bitwarden commits to any fix window. Document who owns backup, restore testing and incident communication inside your own team, and whether a third party such as DeployOpen will operate, back up and document the platform under a fixed-scope agreement.

What drives running cost for each option

Running either server costs more than the software line on a quote. The cards below separate hardware, skills, paid licensing, upgrade work and recovery testing, and note which ones recur each year and which are paid once during setup.

Infrastructure sizing

The official Bitwarden Linux install guide lists a minimum of 2 GB of RAM and 12 GB of storage, and recommends 4 GB of RAM and 25 GB. Vaultwarden is positioned as the lighter option for teams that do not want the resource-heavy official service. Ask your vendor or consultant to size both against your user count, attachment volume and database growth, then price the host, storage and backup target for each option separately.

Docker and container skills

The official server requires Docker Engine 26 or later and ships an MSSQL Express image by default with a 10 GB database size limit. Vaultwarden recommends installing from its container images. Either option needs someone who can operate containers, patch base images and read logs. Count that person's time as a recurring cost, not a one-time setup task.

Database administration

The standard Bitwarden installation runs on MSSQL, and its 10 GB default size limit is a planning point for growing organizations. Vaultwarden uses SQLite by default and its template marks PostgreSQL as recommended for larger use. If you move Vaultwarden to PostgreSQL, budget for a database administrator or a managed service, plus the backup and restore work that comes with it.

Reverse proxy and HTTPS

Vaultwarden requires HTTPS for the web vault because of the Web Crypto API and suggests running behind a reverse proxy. Certificates, proxy configuration and renewals become ongoing work. Confirm who owns the certificate lifecycle, and whether your existing edge platform already provides it at no added cost.

Paid licensing and vendor support

Self-hosting Bitwarden is free, but paid features need a license file tied to the installation ID and the cloud region. That license is a recurring cost tied to your subscription. Vaultwarden has no paid feature license, but its README directs bug reports to the Vaultwarden project rather than official Bitwarden support. Ask each vendor what is included in a quote and whether support is contracted separately.

Monthly upgrade effort

Bitwarden publishes monthly server releases, with v2026.10.0 published on October 14, 2026 and the self-host release on October 15, 2026. Vaultwarden released 1.37.4 on October 5, 2026, after 1.37.3 and 1.37.2. Each monthly cycle needs a test in staging, a backup, a change window and a rollback plan. Estimate that cadence as a recurring staff cost, and ask whether a retainer covers upgrades.

Backup testing and recovery

The Vaultwarden README highly recommends regular backups of files and the database and states its maintainers cannot be held liable for data loss. The official server also depends on the database and attachment storage being restorable. A backup that has never been restored is not a control. Schedule restore tests at a set interval, record the time they take, and treat that staff time as recurring.

What implementing each one involves and where projects run long

Both paths start with a database and a container host, but the work diverges quickly. Self-hosted Bitwarden needs an installation ID and installation key retrieved with a valid email address from bitwarden.com/host before the standard installer runs, and the installer ships an MSSQL Express image by default with a 10 GB database size limit, so plan for that limit or replace the database image before go-live. Vaultwarden runs from its container images, defaults to SQLite, and moves to MySQL or PostgreSQL through the DATABASE_URL setting, with PostgreSQL marked as recommended in the .env.template file. Either way, the web vault needs HTTPS and a reverse proxy in front of it. Confirm the Bitwarden installer's current prerequisites against the Linux install guide, and confirm the Vaultwarden database choice against your backup tooling before you commit.

SSO and directory sync are where the two diverge most. Vaultwarden added OpenID Connect single sign-on in 1.35.0, and later releases through 1.37.3 added fixes and settings such as SSO_SIGNUPS_ALLOWED, so test your identity provider's claim mapping, group handling and logout behavior against the exact release you deploy. On the Bitwarden side, SSO and Directory Connector sync (GPL-3.0) are paid-feature paths that depend on a license file tied to the installation ID, so confirm entitlement before you design the rollout. Edge cases that projects usually find late include users who sign in with SSO but have no vault yet, accounts that exist in the directory but were never invited, and mismatched email addresses between the identity provider and the vault. Client rollout then depends on each browser extension and mobile app pointing at your server URL, which is a per-device step you should script or document.

Questions buyers ask before choosing or hiring help

Is Vaultwarden safe for business use?

Vaultwarden can be run safely by a business, but the decision depends on who answers for it when something breaks. Vaultwarden is an independent project, not affiliated with Bitwarden, Inc., and its README says the maintainers focus on individuals, families and small organizations. It asks users to report bugs to the Vaultwarden project rather than to Bitwarden support, and states that the maintainers cannot be held liable for data loss. A business using it should have a tested backup routine for files and the database, a named internal owner, and a written decision on who handles upgrades and incidents. Teams that need a vendor to stand behind the product usually compare that against the licensed official server before deciding.

What do the official Bitwarden paid features cost?

Bitwarden does not publish a cost in the material supplied for this page, so the cost has to be confirmed directly with Bitwarden for your organization size and feature set. The mechanism is clear, though. Self-hosting the server is free, but paid features need a license file that you download from the cloud web app, under Admin Console, Billing, and Subscription. That license is tied to your installation ID, and the data region of the installation must match the region of the cloud organization. Ask Bitwarden which features your plan includes, whether the license is per seat or per organization, how renewals work, and whether support is included. Those answers, not the server itself, determine the recurring cost.

Can a team run Bitwarden or Vaultwarden itself?

A capable internal team can run either one, but the workload differs. Official Bitwarden installs on Linux with Docker Engine 26 or later, and its install guide lists a minimum of 2 GB of RAM and 12 GB of storage, with 4 GB of RAM and 25 GB recommended. Vaultwarden is a lighter alternative server implementation written in Rust and is designed for environments where the official service is too heavy. Either way, you need someone who can operate containers, manage TLS, back up the database and apply upgrades on a regular cadence. If that skill is not in-house, scope the work in writing before starting, or hire an implementation partner to plan and document it.

Which parts of a password manager rollout need internal staff?

Some decisions must stay with your organization even if an outside firm does the build. Your staff should own the policy choices: who can create collections, which enterprise policies apply, how two-factor login is enforced, and how emergency access and admin password reset are used. They should also own the identity integration, since SSO and directory sync must match your existing identity provider. Day-to-day operations include monitoring, patching, backup restore tests and responding to bug reports. For Vaultwarden, the bug path runs to the Vaultwarden project, so someone internal must triage issues first. Confirm these responsibilities in the written scope so no step is left unowned.

How long does a migration between Bitwarden and Vaultwarden take?

The duration depends on the size of the vault, the number of users and how much configuration you rebuild, so no fixed timeline applies. Bitwarden documents a cloud to self-hosted path in which an organization exports its data, downloads its license, creates a self-hosted account with the same email and imports the data. Attachments, member invitations, enterprise policies and SSO must be redone in that path, and the same kind of rework should be expected when moving between server implementations. Plan for a pilot group, a rollback point and a user communication window. Ask any implementation partner for a timeline tied to your user count, your identity provider and your export volume.

Does Vaultwarden need HTTPS to work?

Yes, the web vault needs HTTPS. Vaultwarden's README states that the web vault requires HTTPS because of the Web Crypto API, so plan a valid certificate before users sign in. The project also suggests running it behind a reverse proxy, which handles TLS termination and can add request limits and logging. Your reverse proxy, certificate issuance and renewal become part of the operating scope. Check how the proxy is configured against your own security baseline, and test the browser extensions and mobile clients against the same endpoint before you roll out.

Does Vaultwarden support SSO and which database should it use?

Vaultwarden supports single sign-on with OpenID Connect, added in version 1.35.0 on December 27, 2025, with later fixes through 1.37.3. Confirm that your identity provider and claim mapping fit the flow before relying on it. Vaultwarden uses SQLite by default and can use MySQL or PostgreSQL through the DATABASE_URL setting, and its configuration template marks PostgreSQL as recommended for production. Official Bitwarden documents SSO as part of its enterprise setup, so check with Bitwarden which SSO integration is covered by your license. Ask both sides to show the setup working with your own directory.

Who supports each option when something breaks?

Support depends on which product you run. With official Bitwarden, paid features come with the licensed relationship, and you should confirm in writing the response times, channels and included services for your plan. With Vaultwarden, the project asks users to report bugs to the Vaultwarden project and not to Bitwarden support, and its maintainers do not offer a commercial support contract in the material supplied. A third-party firm can provide operating support, but its scope, response targets and fees must be agreed in a written statement of work before go-live. DeployOpen plans, implements, hardens, backs up and supports self-hosted platforms in your own infrastructure, with ongoing support available as a retainer and most engagements fixed in scope.

How DeployOpen helps choose, implement or migrate

DeployOpen works on self-hosted Bitwarden and Vaultwarden inside your own cloud accounts, data centers or air-gapped networks. We start from a written scope that reflects your licensing, database and support requirements, then build, document and hand over the deployment you choose.

How we scope

We confirm which Bitwarden features your organization needs and whether they require a paid license file
We agree the database, hosting platform, SSO provider and backup targets before any build starts
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins

How we build

We install the chosen server with its database, reverse proxy and HTTPS configuration in your environment
We wire SSO and directory sync to your identity provider and test login, policy and recovery paths
We run security testing against the deployed service and record the findings and fixes

How we hand over

You receive runbooks covering upgrades, backups, restores and license renewal for your installation
We document the configuration, access model and the responsibilities your team keeps after handover
If you move from Vaultwarden to official Bitwarden or the reverse, we document the migration steps and what must be redone

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
A retainer can cover monitoring of new releases, patching and restore testing for your backups
Ask us to confirm in writing who answers each class of problem: vendor, community project or DeployOpen

Self-hosted Bitwarden vs Vaultwarden