Bitwarden vs Vaultwarden for business use

Bitwarden vs Vaultwarden for business use: which one fits once the pilot works

Once a Vaultwarden pilot works, the question is whether the business can depend on it or should license Bitwarden. Vaultwarden is AGPL-3.0 licensed, is not associated with Bitwarden, Inc., and its README says bugs go to the Vaultwarden project rather than Bitwarden support, with maintainers who cannot be held liable for data loss. Bitwarden's server is also AGPL-3.0, but the files in the bitwarden_license directory, including Commercial.Core and the SSO integration modules, fall under the Bitwarden License, and production use of that code requires a paid subscription. Vaultwarden is defensible for a small organization with a named owner who accepts community support, tests restores and owns the backup routine. Bitwarden is the stronger choice when the business needs a vendor to answer for the product.

The gap is widest in the features a regulated team tends to need. Vaultwarden has implemented SSO through OpenID Connect since version 1.35.0, but the SSO settings have changed across the 1.37 line, so the exact configuration needs checking against the release you deploy. Ask Bitwarden which enterprise policies, SSO and directory features your plan includes, and ask Vaultwarden maintainers or your own tests to confirm the same for the behavior you depend on, such as SSO_SIGNUPS_ALLOWED and group handling. Vaultwarden's README also highlights a single active maintainer employed by Bitwarden who contributes in personal time, so continuity should be part of your risk review.

Before deciding, run a written check of three items: who answers a production incident and within what agreed timeframe, whether your auditors accept a community project as a component of your control evidence, and how you would restore the database and attachments from backup on a clean host. If the answers point to a contract and a named support path, budget for a Bitwarden subscription and the self-host license that ties to your installation ID. If they point to self-managed operations with a tested restore, Vaultwarden on PostgreSQL remains a credible option. Either path benefits from an independent review of the deployment, which DeployOpen can plan and implement within a fixed written scope.

How the two compare on support, auditability, licensing and operations

This table compares Bitwarden's self-hosted server with Vaultwarden on the questions that usually decide business use: license, paid features, support path, liability, SSO, databases, install path and migration. Read each row as a question to put to both vendors, since several answers depend on your contract and your own environment.

Question	Bitwarden self-hosted	Vaultwarden
Server license	Main server code is AGPL 3.0; files in the bitwarden_license directory fall under the source-available Bitwarden License, which the vendor says is not open source under the OSI definition.	Licensed under AGPL-3.0, with no separate licensed directory described in the supplied material.
License for paid features	Production use of bitwarden_license code needs a paid subscription; the license file is tied to the installation ID and must match the cloud organization's data region.	Not applicable as a paid tier; the README lists the features it implements, including organizations, groups, event logs and policies.
Bug reports and support	Official Bitwarden support channels handle issues with the licensed product; confirm the response terms in your subscription.	Report bugs to the Vaultwarden project, not Bitwarden support; the project is not associated with Bitwarden, Inc. and maintainers focus on individuals, families and small organizations.
Liability statement	Confirm the warranties and liability terms in your Bitwarden subscription agreement with the vendor.	Maintainers state they cannot be held liable for data loss and recommend regular backups of files and the database.
SSO availability	SSO is part of the Bitwarden License code path; confirm the SSO module and its terms for your edition with Bitwarden.	OpenID Connect SSO added in version 1.35.0 (December 27, 2025), with later fixes through 1.37.3; confirm the settings you need against your identity provider.
Supported databases	Standard installation ships MSSQL Express by default with a 10 GB database size limit; confirm other database options in the install guide for your version.	SQLite by default; MySQL or PostgreSQL through DATABASE_URL, with PostgreSQL marked as recommended in the configuration template.
Container and install path	Multi-container install needs Docker Engine 26 or later and an installation ID and key from bitwarden.com/host; official Helm charts are published.	Installed from container images on ghcr.io, docker.io or quay.io; HTTPS is required for the web vault and a reverse proxy is suggested.
Migration between the two	Moving data from Vaultwarden is a planned export and import; confirm the steps, since attachments, invitations, enterprise policies and SSO are documented as redone on cloud-to-self-hosted moves.	Export from Vaultwarden and import into Bitwarden; confirm the export format, attachments and organization structure with the Bitwarden import documentation before cutover.

What the support gap means when something breaks

The Vaultwarden README is explicit that the project is not associated with Bitwarden or Bitwarden, Inc., that one active maintainer is employed by Bitwarden and contributes on their own time, and that bugs should be reported to the Vaultwarden project rather than to official Bitwarden support channels. The same file says the maintainers cannot be held liable for data loss and highly recommend regular backups of files and the database. For a business, this means there is no contractual support path in the Bitwarden sense, and the people who fix a failed upgrade or a corrupted database are volunteers with no obligation to respond on a timeline. Ask whether your organization has any agreement that changes this, and record the answer. If the answer is none, the support model is whatever your own team can staff.

A business that chooses Vaultwarden needs a written support and incident path before go-live, not after the first outage. Document who triages a fault, who has administrative access to the server and its database, which upstream channel receives a Vaultwarden bug report, and who signs off a rollback. Define the recovery objective you need for the vault database and attachment storage, then test a restore of the database and the data directory on a separate host, since the README's backup guidance only helps if the restore has been exercised. Plan the version pinning and patch cadence as well, because Vaultwarden releases such as 1.37.4 arrive on the project's own schedule, and your staff must decide when to apply them. Where a pilot runs on a single container, record that as a known single point of failure.

Compare that internal burden with the Bitwarden self-host path, where a licensed organization can take paid support from the vendor under its subscription terms. Confirm the exact support tier, response commitments and escalation route in writing with Bitwarden, because the supplied facts do not state them. Ask for the same items from any Vaultwarden hosting partner you consider. The decision is defensible for a business only when the team can name the people who will own each step, and when leadership accepts the no-liability position in writing.

Factors that decide whether Vaultwarden is defensible

Vaultwarden can be a sound choice for some organizations and a poor fit for others. The cards below group the checks that usually decide it: who needs vendor-backed evidence, how many people and admins run the service, which paid Bitwarden features are required, and who answers when something breaks.

Vendor-backed audit evidence

Some assessors and internal audit teams ask who stands behind the software and who answers for it in a review. Vaultwarden's README says it is not associated with Bitwarden, Inc. and that its maintainers cannot be held liable for data loss. Ask your auditor whether a community project with documented backup guidance satisfies the control, or whether you need a contract with a named vendor. Check this before the pilot grows.

Number of users and admin roles

Small teams with one administrator can run Vaultwarden with a short operating checklist. Larger organizations with several admins, delegated collections and frequent offboarding need documented role separation and a review of who can change policies. Count your admin accounts and the groups they manage, then test whether the admin backend and event logs meet your access review cadence.

Required paid Bitwarden features

Enterprise policies and SSO in the official server sit in the Bitwarden License, which requires a paid subscription for production use. Vaultwarden implements policies and, since version 1.35.0, OpenID Connect SSO, so the gap may be smaller than it looks. Map each control you need, such as enforced two-factor rules or SSO signup restrictions, to a feature in each product and confirm the behavior in a test tenant.

In-house operations skill

Backups, restores, upgrades and the reverse proxy are the operator's responsibility with Vaultwarden. The README highly recommends regular backups of files and the database and requires HTTPS for the web vault. Confirm that your team can test a restore, follow release notes for security fixes and patch on a schedule. If that skill is thin, a managed or retained operating model may fit better.

Data residency and license region

Paid Bitwarden features on the official server depend on a license file tied to the installation ID, and the data region must match the cloud organization's region. Vaultwarden carries no such license file, which removes that dependency but also removes any vendor-issued entitlement. Document where your data must live, confirm whether your regulator or contracts require a specific region, and record how each option satisfies that requirement.

Tolerance for community response times

Vaultwarden asks users to report bugs to the Vaultwarden project rather than to Bitwarden's support channels, and its maintainers focus on individuals, families and small organizations. Security fixes arrive through releases such as 1.37.4, but no response time is promised. Decide how long a security-relevant outage or vulnerability can wait for a fix, and whether your incident process can carry that risk.

Where Bitwarden's paid features apply and what a license costs in effort

The first split to understand is that self-hosting Bitwarden is free, but paid features are not. The main server code is licensed under AGPL-3.0, while files in the bitwarden_license directory, including Commercial.Core and the SSO integration modules, fall under the Bitwarden License. That license is source-available rather than open source under the OSI definition. Under the Bitwarden server license FAQ, code under the Bitwarden License may be used for development and testing, but production use requires a paid subscription. For a business pilot, the question is which features your rollout depends on, such as SSO, directory sync or enterprise policies, and whether those sit in the licensed modules. Confirm that mapping with Bitwarden before you commit to a production design.

Paid features are unlocked with a license file that you download from the cloud web app, under Admin Console, Billing and Subscription, and it is tied to your installation ID. The installation ID and installation key come from bitwarden.com/host using a valid email address during installation. The data region of the license must match the region of the cloud organization it belongs to, so decide the region before you buy or request a license. Ask Bitwarden how a license is renewed, how a rebuilt or moved installation keeps its installation ID, and what happens to licensed features if a renewal lapses. Those answers determine how much recurring administrative work the license adds.

The license cost in effort is mostly recurring. Someone must own the subscription, track renewals, and re-attach a license file when the installation changes, and that person needs access to the cloud billing account, which is a separate control from the server administrator role. Compare this with Vaultwarden, where no equivalent license file exists but the team takes on the support and risk the README describes. When you request a quote, ask Bitwarden to list each licensed module against your requirements, the seat or plan basis for pricing, what support is included, and the process for renewals and license file replacement.

How to confirm the fit in your own environment

This sequence turns the comparison into evidence from your own environment. By the end, you will have a requirement-by-requirement map, a license position for each paid feature, tested restores, observed support paths, SSO and directory sync results, and a documented upgrade routine for each platform.

Write down the required features and map them
The security or IT lead lists every requirement the password manager must meet, such as SSO sign-in, directory-based group membership, role-based collections, event logs, policy enforcement and admin password reset. For each item, record the vendor's documented capability for Bitwarden and for Vaultwarden, with the page or release note used as the source. Mark anything you cannot confirm from documentation as open. The output is a single matrix that every later step can reference.
Confirm which features need a Bitwarden license
Using the matrix, the procurement or licensing owner marks each item that depends on a Bitwarden paid feature. Bitwarden's license file is tied to the installation ID and the data region of the cloud organization, and it is downloaded from the cloud Admin Console, so confirm the region and the subscription terms with Bitwarden before you commit. The licensing owner should also confirm that files under the Bitwarden License are used only under a paid subscription for production. The output is a signed-off list of paid features and the cost basis for each, requested in writing from the vendor.
Run a restore test on both platforms
The platform engineer deploys each candidate in a non-production environment, loads realistic but non-sensitive test data, and takes a backup using the method each project documents. Then the engineer restores the backup to a clean host and checks that vault items, attachments, organizations, collections and user logins work. Vaultwarden's maintainers state they cannot be held liable for data loss and recommend regular backups of files and the database, so this test must be run by your team. The output is a dated restore record for each platform, with any gaps noted.
Run a support escalation drill on each channel
The service owner opens one sample ticket through Bitwarden's support channel and one through the Vaultwarden project's issue tracker, using the same reproducible fault such as a failed SSO login or a broken attachment upload. Record the response, who answered, what they asked for, and whether the answer came from the vendor or from a community volunteer. Vaultwarden's README directs bug reports to its own project, not to Bitwarden support, so the drill shows which path your staff will actually use. The output is a documented escalation procedure with the contact route for each platform.
Test SSO and directory sync with your identity provider
The identity engineer connects each candidate to a test tenant of your identity provider and checks sign-in, group mapping, user provisioning and deprovisioning. For Bitwarden, confirm which SSO and Directory Connector functions sit in the licensed modules, and for Vaultwarden, confirm the behavior of its OpenID Connect settings in the version you plan to run. Remove a test user in the directory and verify access ends on each platform. The output is a test log showing which flows passed, failed or required workarounds.
Review auditability and event log retention
The compliance lead asks each platform for the event records your audit process needs, including who viewed or exported a vault item, who changed a member role and when an admin reset a password. The lead exports a sample of these logs, checks the fields against your evidence requirements, and confirms where the logs are stored and how long they are kept under your own control. The output is a short evidence note per platform that your auditors can review. This note supports readiness work only and does not replace an assessment by an independent auditor.
Document upgrade steps against each release cadence
The platform owner records how each project publishes releases, including the Bitwarden server and self-host release pages and the Vaultwarden GitHub releases page, and then writes a maintenance calendar that matches your change windows. The owner rehearses one upgrade in staging, notes any database or configuration changes, and records the rollback path. The output is a runbook for each platform that names the release source, the test steps and the person who approves production upgrades.

When each option is defensible

Vaultwarden fits a small group that accepts community support, can tolerate a short outage and has someone who will keep backups and upgrades current. Its README is candid that it is not associated with Bitwarden, Inc., that its maintainers focus on individuals, families and small organizations, and that they cannot be held liable for data loss. For a household or a handful of people with a shared vault, that trade-off is usually acceptable if the operating habits are right.

Support expectation: Bug reports go to the Vaultwarden project, not to Bitwarden's support channels, so plan on community help.
Backups: The README highly recommends regular backups of files and the database. Test a restore before you rely on it.
Feature need: Personal vault, Send, attachments and organizations with collections cover most informal sharing.
Upgrade rhythm: Track releases such as 1.37.4 and apply them promptly, since the project is maintained by a small group.
Licensed Bitwarden server: Becomes the safer choice once a family or small team needs paid features, which require a license file tied to an installation ID.

Before committing, confirm who owns recovery when the server fails at a bad hour and whether that person is comfortable with community-only support.

Questions buyers ask before choosing a self-hosted password manager

Does a business need a paid license to run Bitwarden in production?

Yes, if the code in question is the paid part. The main Bitwarden server code is AGPL-3.0, but files in the bitwarden_license directory, including Commercial.Core and the SSO integration modules, fall under the Bitwarden License. That license allows development and testing, while production use requires a paid subscription. Paid features such as the Admin Console controls and SSO need a license file downloaded from the cloud web app and tied to your installation ID, and its data region must match the cloud organization's region. Confirm the current edition terms and seat counts with Bitwarden before you budget, because the license file, not the server license alone, decides what your production instance may use. Read the Bitwarden server license FAQ before you rely on any reading of it.

Does Vaultwarden support SSO, and which version added it?

Yes. Vaultwarden 1.35.0, released on December 27, 2025, added single sign-on with OpenID Connect. Later releases through 1.37.3 added SSO fixes and settings such as SSO_SIGNUPS_ALLOWED. Check the feature set against your identity provider before you commit, because SSO behavior is only as good as the OIDC integration your team tests. Ask for your specific flows, including group mapping, enforced login and account recovery, to be proven in a staging instance. Your team should also confirm which Vaultwarden release you run, since SSO fixes landed across several versions.

What must our own team do when running Vaultwarden for a business?

Most of the operating work stays with you. The Vaultwarden README states that the project is not associated with Bitwarden, that the maintainers focus on individuals, families and small organizations, and that they cannot be held liable for data loss. It also tells users to report bugs to the Vaultwarden project rather than to official Bitwarden support, and it highly recommends regular backups of files and the database. Your team therefore owns:

Backup design, restore testing and retention for the database and attachments
HTTPS, reverse proxy setup and upgrades to each new release
Database choice, since it uses SQLite by default and recommends PostgreSQL for larger use
Monitoring, incident response and the audit evidence your assessors request

How long does a migration between Bitwarden and Vaultwarden take?

Duration depends on your data volume, your identity integration and how many people must re-enroll, so no fixed figure applies. Bitwarden documents a cloud-to-self-hosted path that exports organization data, downloads a 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. Moving between the two self-hosted servers is a separate project with its own export, import and client testing. Ask any vendor or partner for a written plan that lists each data type, who performs each step and how users keep access during cutover, then time a rehearsal on a copy of production.

Can a partner run Bitwarden or Vaultwarden inside our own infrastructure?

DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a password manager, that can include deployment, SSO integration, backup and restore design, and upgrade runbooks for either server. DeployOpen does not issue audit reports or certifications, and it is not an official partner or reseller of Bitwarden or Vaultwarden. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as retainers.

What should we ask for in a written quote for a self-hosted password manager?

Ask for a scope that names each component and who is responsible for it. Request line items for installation, SSO and directory integration, data migration, backup and restore testing, hardening, documentation, training and any post-launch support. Separate one-time work from recurring items such as retainers, upgrades and license renewals. Ask the vendor to state which paid license applies, who buys it, and what happens if seat counts change. For either server, ask who handles security reports, patch timing and incident response, and whether the quote covers your compliance evidence. DeployOpen does not publish a price list, and a quote follows from the written scope.

Primary sources to read before deciding

Read the Bitwarden server license FAQ before you commit to either path, because the license split decides what you can run in production. The main server code is AGPL 3.0, but the files in the bitwarden_license directory, including Commercial.Core and the SSO integration modules, fall under the Bitwarden License, which is source-available and not open source under the OSI definition. The same FAQ says that code under the Bitwarden License may be used for development and testing, while production use requires a paid subscription. Ask your legal team to map every feature your rollout depends on, especially SSO, to one of those two licenses. The Bitwarden server license FAQ is the document to take to that review.

Next, read Bitwarden's guide to licensing for paid features, which explains how a license file is downloaded from the cloud web app and tied to your installation ID, and why the data region of that installation must match the cloud organization's region. Confirm with Bitwarden which paid features your edition includes, who issues renewals, and what happens to enterprise policies and SSO if a license lapses. Those answers are the basis of any support or continuity discussion, and they are not in the Vaultwarden project's documentation. The Bitwarden licensing for paid features guide sets out the mechanics you will need to verify.

Then read the Vaultwarden README and its release history side by side. The README states that the project is not associated with Bitwarden, Inc., directs bug reports to the Vaultwarden project rather than Bitwarden's support channels, and says the maintainers cannot be held liable for data loss. For a business, that disclaimer means your own backup procedure for the database and attachments is the control that matters, and your change process should track each release. Check the release notes for the SSO and organization settings you plan to use, and confirm which version your environment will pin before you go live.

How DeployOpen helps evaluate and implement

DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Bitwarden vs Vaultwarden for business use, we start with the written scope that decides which edition, license and support path fits your environment.

How we scope

Confirm which Bitwarden features and paid modules your organization needs, such as SSO, directory sync and policies.
Map the support expectations your business needs, including who answers for incidents on each option.
Agree scope, deliverables and timelines in writing before work starts, since most engagements are fixed-scope.

How we build

Deploy the chosen server in your own cloud account, data center or air-gapped network, with HTTPS and reverse proxy configured.
Connect identity sources, SSO and directory sync, and test policies, collections and emergency access with pilot users.
Test backup and restore for the database and attachments, and verify the paid license tied to your installation ID.

How we hand over

Document the architecture, licensing position, backup routine and upgrade steps so your team can run the platform.
Provide a migration plan if you move between Bitwarden and Vaultwarden, including what must be redone after import.
Hand over evidence for compliance readiness, though independent auditors and certification bodies issue any attestation.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing.
Review each new release line for licensing, database and configuration changes before your team applies it.
Confirm with the vendor or project which support channel applies to each incident, and record it in the runbook.

Bitwarden vs Vaultwarden for business use