Bitwarden vs Passbolt: when to choose each
Choose Bitwarden when your team wants a vault model with a broad client ecosystem, including mobile apps and a standard browser extension, and can accept that the server is AGPL-3.0 but several business features sit under the Bitwarden License and need a paid subscription for production. Choose Passbolt when you want OpenPGP end-to-end encryption where each user holds a key pair and each shared resource is encrypted separately to every authorized user, and when a browser-extension-first workflow is central to how people will work. Both can be self-hosted, so the decision turns less on hosting than on the four questions below. First, decide who holds recovery responsibility. In Passbolt, keys are per user, so losing a private key without a recovery path means losing access to what that user could decrypt. Account recovery is a Pro feature in Passbolt's comparison, so confirm whether your recovery model requires it before you commit. Bitwarden's vault model centers on organization collections and admin-managed access, which changes what a lost master password means for your help desk. Write the recovery procedure first, then test it with a departing employee.
Second, map user provisioning. Passbolt lists LDAP user and group provisioning from AD or OpenLDAP, SSO with Microsoft, Google, OpenID and AD FS, and SCIM as Pro features, so a Community Edition deployment means manual user lifecycle work. Bitwarden's Directory Connector, which syncs AD, LDAP, Azure, Google Workspace or Okta users, is a separate GPL-3.0 tool, and SSO integration modules sit under the Bitwarden License. Ask both vendors which edition and license your identity stack needs, and confirm the sync direction and deprovisioning behavior in a pilot. If your directory is the system of record, the cost of a paid tier often depends on this single requirement.
Which team fits Bitwarden and which fits Passbolt
This table maps common team situations to the platform that fits them better, with the supplied fact that drives each choice. Read each row against your own directory, licensing and browser habits, because the better fit often depends on one requirement. Where neither product is a clean match, the table says so and points you to other options.
| Scenario | Better fit | Why |
|---|---|---|
| Small team with no directory and a browser-first habit | Passbolt | Passbolt's Community Edition is free for self-hosting with unlimited users, and encryption happens in the browser extension, so users work the way they already do. |
| Team that needs LDAP or SSO provisioning on a budget | Bitwarden | Bitwarden's self-hosted server offers directory and SSO integration, but production use of those modules requires a paid subscription and license file tied to the installation ID. |
| Company that needs LDAP user and group provisioning and SCIM | Passbolt | Passbolt lists LDAP provisioning from AD or OpenLDAP and SCIM as Pro features, so the choice depends on accepting a paid tier. Confirm the exact connector set with Passbolt before committing. |
| Team that must stay on Community Edition | Passbolt | Passbolt's Community Edition is free to self-host with unlimited users, while Bitwarden's paid features require a license file for production. Confirm which controls your compliance scope needs. |
| Team migrating from a browser-based vault | Passbolt | Passbolt imports CSV exports from LastPass, 1Password, Dashlane, Chrome, Firefox and Bitwarden, and its browser extension mirrors that workflow. Bitwarden also imports from browser vaults, so test your largest export first. |
| Kubernetes-centered platform team | Bitwarden | Bitwarden publishes official Helm charts for Kubernetes, and Passbolt also ships a Helm chart, so both fit. Bitwarden's standard install is multi-container, so size the cluster and database before choosing. |
| Team that needs a cleared export path for audit or exit planning | Neither cleanly | Passbolt disables cleartext CSV export by default since version 5.10 and offers encrypted KDBX, while Bitwarden's export policies differ. Evaluate other options or confirm export controls in writing with each vendor. |
What the encryption model changes day to day
Passbolt and Bitwarden protect shared secrets with different key models, and those differences show up in daily administration, not just in the architecture diagram. The four areas below cover who holds keys, what happens when a user is locked out, what the server can see, and how much depends on the client software.
Key ownership and sharing
In Passbolt, each user holds an OpenPGP key pair, and each user with access to a shared resource receives their own copy encrypted with their public key. Adding or removing a member therefore means re-encrypting resource copies for that person, so offboarding and access reviews depend on Passbolt's sharing workflow working as documented. Bitwarden organizations use a vault model with collection-based sharing. Confirm with Bitwarden how key material is created and rotated for organization members before you rely on its offboarding steps.
Account and key recovery
Passbolt's encryption is tied to each user's private key, so the administrator's first recovery question is what happens when a user loses that key or their device. Passbolt Pro lists account recovery as a paid feature, which means the recovery process is part of your edition decision. For Bitwarden, the supplied facts do not describe its recovery or key escrow mechanics in enough detail to compare. Ask Bitwarden for its written account and key recovery procedure, and test it on a non-production organization.
Metadata visibility
Passbolt states that its server stores only ciphertext, but metadata such as names, URLs and descriptions is encrypted only with the v5 format and when the organization enables metadata encryption. A Passbolt deployment on an older format or without that setting leaves more readable on the server than the headline model suggests. Review your Passbolt version and the metadata encryption setting during design. For Bitwarden, confirm with the vendor which vault fields are encrypted and which remain visible to the server operator.
Client dependence and export
Passbolt encrypts and decrypts locally in its browser extension or mobile app, never on the server, and the extension is cryptographically signed. Users without a working client cannot read secrets, so rollout, browser policy and extension updates become core administration tasks. Passbolt also disables cleartext CSV export by default since version 5.10, so an administrator must allow CSV again in export policies if a migration needs it. Plan client deployment and export policy together before you onboard users.
Bitwarden vs Passbolt feature by feature: SSO, directory sync, imports and exports
This table compares self-hosted Bitwarden and Passbolt on the features that decide SSO, directory provisioning, imports, exports and deployment. Passbolt's Pro-only items come from its published comparison, and Bitwarden tiers are marked for confirmation where the supplied facts do not settle them. Read each row against the condition in the last column, because many rows matter only for teams that run directory-driven onboarding or need controlled exports.
| Feature | Bitwarden | Passbolt | When it matters |
|---|---|---|---|
| License and free edition | Server core is AGPL-3.0. Files in bitwarden_license fall under the Bitwarden License, which requires a paid subscription for production use. | Server is AGPL-3.0 and the self-hosted Community Edition is free with unlimited users. | Matters when legal or procurement must approve the exact code and license you run in production. |
| SSO | SSO integration modules sit under the Bitwarden License. Confirm the tier on the Bitwarden licensing page before deciding. | SSO with Microsoft, Google, OpenID and AD FS is a Pro feature, not part of Community Edition. | Matters when staff must sign in with an existing identity provider and each login must follow corporate policy. |
| Directory sync (LDAP, AD and SCIM) | Directory Connector (GPL-3.0) syncs AD, LDAP, Azure, Google Workspace or Okta users. Confirm which tier the server side needs. | LDAP user and group provisioning from AD or OpenLDAP is Pro only. SCIM is also listed as Pro only. | Matters when joiners, movers and leavers should be provisioned from a directory instead of managed by hand. |
| MFA policies and account recovery | Confirm on the Bitwarden licensing page whether MFA policies and account recovery are available in your edition. | Both MFA policies and account recovery are Pro features in Passbolt's pricing comparison. | Matters when administrators must enforce second factors or regain access to shared credentials after a lockout. |
| Password policies and syslog activity logs | Confirm the tier and available policy and logging options on the Bitwarden licensing page. | Passphrase and password policies, a password expiry policy and syslog activity logs are Pro features. | Matters when audit teams need activity forwarded to a SIEM or when policies must be enforced across all users. |
| Imports from other managers | Confirm the supported import sources and formats in Bitwarden's help documentation for your version. | CSV imports cover LastPass, 1Password, Dashlane, NordPass, LogMeOnce, Bitwarden and major browsers. KDBX covers KeePass and Keeper. Available in Community, Pro and Cloud. | Matters during migration from a current manager, where the source tool determines whether a clean import is possible. |
| Export controls | Confirm in Bitwarden's admin documentation which export formats are available and whether an administrator can restrict them. | Since Passbolt 5.10, cleartext CSV export is off by default. Encrypted KDBX exports are offered unless an administrator re-enables CSV in export policies. | Matters when data leaving the vault must be limited, logged or kept in encrypted form for offboarding and audits. |
| Kubernetes packaging | Official Helm charts are published in the bitwarden/helm-charts repository under AGPL-3.0. | The official Helm chart in charts-passbolt is AGPL-3.0. Docker is also supported for installation. | Matters when the password manager must run on an existing cluster under the same deployment pipeline as other services. |
| Supported Linux hosts | Requires Docker Engine 26 or later, at least 2 GB RAM and 12 GB storage, with an MSSQL Express image by default. Lite is positioned for personal use. | Installs on Debian 13, Ubuntu 26.04, Red Hat family, openSUSE Leap 15 and SLES 16, with Docker, Helm, AWS AMI and Ansible options. | Matters when your standard operating system images or patch windows are fixed, so the host must be on the vendor's list. |
What each license allows and what each edition charges for
Bitwarden's server splits its licensing across directories, and that split decides what a production deployment needs to pay for. The main server code is under AGPL-3.0, which lets you read, modify and self-host it. Files in the bitwarden_license directory, including the Commercial.Core and SSO integration modules, fall under the Bitwarden License. That license is source-available and does not qualify as open source under the OSI definition. The Bitwarden server license FAQ allows those files for development and testing, but production use requires a paid subscription.
- Production use of paid code: Running the SSO integration or other licensed modules in production needs a subscription, so budget for it even though the core server is AGPL-3.0.
- License file tied to the installation: Paid features need a license file downloaded from the cloud web app (Admin Console, Billing, Subscription). It is bound to your installation ID, and the data region of the installation must match the cloud organization's region.
- Client licenses: The clients repository is GPL v3.0 except the
bitwarden_licensedirectory. The internal SDK is GPL v3.0 or the Bitwarden Software Development Kit License v2.0, with its license directories under the SDK license only. - Directory Connector: The tool that syncs AD, LDAP, Azure, Google Workspace or Okta users is GPL-3.0, separate from the server license.
- Helm charts: The official Kubernetes charts are AGPL-3.0.
Because the license file is tied to the installation ID, changing hosting or migrating from cloud to self-hosted means reissuing licenses and redoing SSO and enterprise policies. Ask Bitwarden for a written quote covering the subscription for your user count and the modules you need. Confirm in writing which files your deployment will load.
Passbolt's licensing is simpler at the code level, since its API server and Helm chart repositories are AGPL-3.0. The paid differences sit in editions. The free Community Edition is self-hosted with unlimited users. Pro, billed per user, adds features that many business teams treat as requirements. The Passbolt pricing page lists Pro at $4.9 per user per month, billed annually, with a 10-user minimum and volume discounts after 100 users, according to Passbolt's pricing page. A cloud-managed edition and an Enterprise tier at custom pricing are also offered.
- AGPL-3.0 code: The
passbolt_apiserver and the official Docker and Helm chart repositories are AGPL-3.0, so you can inspect and self-host them. - Community Edition scope: Unlimited users, but no LDAP provisioning, account recovery, SSO with Microsoft, Google, OpenID or AD FS, MFA policies, syslog logs, passphrase policies, password expiry or SCIM.
- Pro pricing: $4.9 per user per month, billed annually, with a 10-user minimum. Per-user billing recurs, so cost grows with headcount.
- Enterprise: Custom pricing, so it is only quoted after a conversation about scope.
- Cloud-managed edition: Hosted by Passbolt rather than in your infrastructure, which changes the data location question.
Pro pricing is a published list price, and it does not include DeployOpen's implementation work or your internal administration time. Ask Passbolt for a written quote at your exact user count, and confirm whether volume discounts apply to your size.
How each is deployed and what it asks of operations
The main operational difference is what you run yourself. A standard self-hosted Bitwarden installation is a multi-container stack that ships with an MSSQL Express image by default, which the Bitwarden Linux install guide pairs with a 10 GB database size limit. The guide requires Docker Engine 26 or later and lists a minimum of an x64 1.4 GHz processor, 2 GB of RAM and 12 GB of storage, with a recommendation of 4 GB of RAM and 25 GB. Treat those figures as the floor and recommendation from the vendor, then size against your user count and attachment volume. Before installing, confirm that someone on your team can obtain the installation ID and installation key from bitwarden.com/host with a valid email address, since paid features are later tied to that installation ID. Bitwarden also publishes official Helm charts in its helm-charts repository under AGPL-3.0 if your platform team runs Kubernetes, which moves the upgrade and rollback model onto your cluster tooling. Bitwarden lite is a different proposition: a single container that supports MSSQL, PostgreSQL, SQLite and MySQL or MariaDB, needing at least 200 MB of RAM. Bitwarden positions it for personal use and home labs, not business use, so it is not a fit for a team on this shortlist.
Passbolt offers Docker images, a Kubernetes Helm chart, an AWS AMI and Ansible playbooks, and its hosting guide lists installation on Debian 13, Ubuntu 26.04, Red Hat, AlmaLinux, Rocky Linux and Oracle Linux 9, openSUSE Leap 15 and SLES 16. Confirm your chosen host distribution against that list before you commit to a build. The virtual appliance option is available only with Pro, so a Community Edition deployment has to be built on a host you manage. Passbolt's releases are frequent, with v5.14.0, v5.15.0 and v5.16.0 published between July and September 2026, so your upgrade calendar should assume regular minor releases. For both products, the operations team owns the host operating system patching, container runtime updates, database backups, TLS certificates and restore testing. Ask each vendor, in writing, which configuration and database state must be captured in a backup for a restore to work, and rehearse that restore on a separate host. Passbolt's users keep their own private keys, so a server backup alone does not recover a user's access, a point to test explicitly with your compliance lead.
Moving a team vault from one platform to the other
This sequence shows how a team moves its shared credentials between Passbolt and Bitwarden without losing access, and how to confirm that each group can reach what it needs before the old vault is switched off.
Inventory users, groups and shared resources
The platform owner lists every user, sharing group, folder or tag, and shared resource in the current vault, and records who has read, update or manage rights on each item. Passbolt shares are granted per user, and each recipient holds their own encrypted copy, so the inventory should be built from the access list on each resource rather than from memory. Bitwarden organizations use collections and group or member permissions, which must be mapped separately. The output is a written access matrix that both teams sign off on before any export starts.
Confirm the supported export path
Check which export format the source platform allows. Passbolt's documentation says that since version 5.10 cleartext CSV exports are disabled by default, and the export list offers encrypted KeePass KDBX formats unless an administrator re-enables CSV in the export policies. Ask the Passbolt administrator to confirm the current export policy in your instance, and confirm the equivalent export options for your Bitwarden edition in its help documentation. The output is a named export method, the person authorized to run it, and a record of where the export file will be stored and deleted.
Run the import into a test instance
Import the export into a non-production Bitwarden or Passbolt instance. Passbolt's import documentation lists CSV imports from Bitwarden, along with several other managers, for the Community, Pro and Cloud editions, so confirm that your Passbolt edition and the Bitwarden export format match before you start. Compare item counts, folder or tag structure, custom fields, URLs and notes against the source. Expect that attachments, shared-resource permissions and group memberships will not carry over as-is. The output is a reconciliation sheet listing every item that imported, failed or arrived without its sharing settings.
Rebuild sharing groups and permissions
Recreate collections, groups and per-item access in the target platform using the access matrix from the first step. Bitwarden's documented cloud to self-hosted migration states that member invitations and enterprise policies must be redone, and the same assumption should be tested for any move between these two products. Passbolt's own documentation should be checked for how groups and resource shares are recreated in your edition. The output is a target-side permission map that matches the source matrix, with exceptions noted and approved.
Rebuild SSO, directory sync and enterprise policies
Reconfigure single sign-on, directory synchronization and security policies in the target platform. Bitwarden's documented migration guidance says SSO and enterprise policies must be set up again, and directory sync through Directory Connector is a separate component that must be installed and pointed at your directory. On the Passbolt side, LDAP provisioning, SSO, MFA policies, password policies and SCIM are Pro features in its comparison, so confirm which of these your edition includes before planning. The output is a checklist showing each identity and policy setting, who owns it, and the test result.
Enroll users and verify their access
Invite each user to the target platform, have them create or link their account, and confirm that they can unlock or decrypt the items they were granted. In Passbolt, each user needs a key pair and the browser extension or mobile app to decrypt shared resources, so enrollment includes key setup for each person. Use a small pilot group first, then the full team, and record any user who cannot reach an expected item. The output is a per-user access report that lists the resources each person can open and the ones that still need attention.
Validate access before cutover
Run a structured check against the access matrix, covering a sample of resources from every group, the administrators and the break-glass accounts. Confirm that revoked users cannot reach items and that every shared resource has at least one owner or manager. Ask an independent reviewer or your security team to sign off the results, and keep the export file out of circulation once the import is verified. The output is a signed cutover record that names the verifier, the date and any accepted exceptions.
Cut over and retire the source vault
Announce the switch, make the target platform the only place where users save new credentials, and set the source vault to read-only for a defined period so that late changes can be found. Keep backups of the source until the team confirms that nothing is missing, then decommission it according to your retention policy. Confirm the decommissioning steps with the vendor documentation for your source platform. The output is a closed source vault, a retained backup with a stated disposal date, and a record of the final reconciliation.
What drives the running cost and implementation effort of each
The running cost of a self-hosted Bitwarden or Passbolt deployment is driven less by the software license than by the people and infrastructure around it. For Bitwarden, the recurring items are the host or Kubernetes capacity, the database (the standard installation ships an MSSQL Express image with a 10 GB database size limit, per Bitwarden's Linux install guide), the administrator time for upgrades, and any paid subscription. Bitwarden's Linux guide recommends 4 GB of RAM and 25 GB of storage at minimum, and self-hosted paid features need a license file tied to the installation ID and matching data region. For Passbolt, the Community Edition is free to run, but Pro is priced per user per month with a 10-user minimum, so the license line scales with headcount, and the server footprint is typically smaller. Ask each vendor or partner to state which of these items is one-time and which recurs, and to name who pays for each.
The largest one-time costs are usually the directory and SSO setup and the migration. Passbolt's Pro-only features include LDAP user and group provisioning from AD or OpenLDAP, SSO with Microsoft, Google, OpenID and AD FS, and SCIM, so a team that needs directory-driven onboarding must budget for Pro before writing any mapping rules. Bitwarden's Directory Connector (GPL-3.0) syncs AD, LDAP, Azure, Google Workspace or Okta users, and its cloud-to-self-hosted migration requires attachments, member invitations, enterprise policies and SSO to be redone. The quote should separate these items and state the license tier, the user count, the directory scope (which OUs and groups sync), the migration scope (how many vaults, attachments and shared collections move) and the acceptance tests that prove a restore works.
Projects tend to run long in three places. The first is directory group mapping, where nested groups and role-based collections must match the access model the business already uses. The second is recovery policy: Passbolt's account recovery is a Pro feature and needs an explicit decision about who can recover a locked account, while Bitwarden's recovery model differs, so both need a documented policy before rollout. The third is user onboarding in a browser-first model. Passbolt encrypts and decrypts in the browser extension or mobile app and gives each user a key pair, so every enrolled user needs a working extension and a key setup session, and that enrollment effort recurs for each new hire. Ask for a training plan, a restore test from backup for both the database and the encryption keys, and a written upgrade schedule that covers the monthly Bitwarden self-host releases and Passbolt's release cadence.
What do buyers ask before choosing Bitwarden or Passbolt for a self-hosted team?
Does the free Passbolt Community Edition include LDAP or SSO?
No. Passbolt's pricing comparison lists LDAP user and group provisioning from AD or OpenLDAP, SSO with Microsoft, Google, OpenID and AD FS, and SCIM as Pro features that are not in Community Edition. The same comparison also lists MFA policies, account recovery and password expiry policies as Pro features. If directory sync or SSO is a requirement, the Pro edition or the Enterprise edition is the option to price, and you should confirm the exact feature list against the current Passbolt pricing page before you commit.
Does production Bitwarden require a paid subscription?
Yes, for production use of the code under the Bitwarden License. Bitwarden's server license FAQ states that 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. That license allows development and testing, while production use of those files requires a paid subscription. Paid features also need a license file tied to your installation ID and data region, so confirm which features your organization needs before you assume the free core covers them.
How long does a migration take, and what does it depend on?
No fixed duration can be promised, because the effort depends on the data and the controls around it. The main drivers are the number of vaults and items, how many attachments exist, how many members must be reinvited, and how many enterprise policies and SSO connections must be rebuilt. Bitwarden's documented cloud to self-hosted path requires that attachments, member invitations, enterprise policies and SSO be redone, so those steps are usually the longest. For Passbolt, the import formats available from your current manager and the export policy decide how much can move cleanly. Ask for a written migration scope with a sample import before you agree on a timeline.
Can our team run either platform without outside help, and what skills does it need?
A team with Linux, container and database operations experience can run either platform, but both need ongoing ownership. Bitwarden standard installation uses Docker Engine 26 or later and an MSSQL Express image by default with a 10 GB database limit, and its Helm charts serve Kubernetes deployments. Passbolt documents installation on several Linux distributions, Docker, a Helm chart and Ansible, and the Pro edition adds a virtual appliance. Your team also needs skills for backups, certificate renewal, upgrades and, for Passbolt, managing user keys and recovery. Whether you need outside help depends on those skills in-house, and a fixed-scope written plan can cover the gaps.
What drives the cost of Passbolt Pro?
Passbolt's pricing page lists Pro at $4.9 per user per month, billed annually, with a 10-user minimum and volume discounts after 100 users. That figure is the list price from the pricing page and does not include your implementation work. Your total cost depends on user count, whether you need the Pro features such as LDAP provisioning and SSO, any Enterprise terms, and the one-time work to deploy, configure identity integration and migrate data. Ask the vendor for a written quote that states the edition, the user count and the billing period, and ask DeployOpen for a fixed-scope quote that lists each deliverable.
What happens if a user loses access to their vault?
The answer depends on the design, so confirm it for each platform. Passbolt encrypts each shared resource for every user with access, using that user's OpenPGP key, and encryption and decryption happen in the browser extension or mobile app. Losing a private key therefore affects that user's access, which is why Passbolt's Pro features include account recovery. Bitwarden stores vault data encrypted by the client and is administered through its organization model, so recovery depends on the administration and account policies you configure. Test the recovery flow in a pilot with a lost-device scenario before you rely on it.
Which platform suits a team that already uses browser-based vaults?
Passbolt is built around a browser-extension-first workflow, so teams that already work in browser extensions and want per-user OpenPGP encryption will find its model familiar. Bitwarden uses a vault model with clients across browsers, desktop, mobile and command line, which suits teams that want one vault across many devices. Your choice depends on whether your users need the browser-first design, which resource-sharing model you prefer, and which import formats match your current manager. Run a pilot with a representative group and compare the import and sharing steps before deciding.
How DeployOpen helps teams choose, implement or migrate a password manager
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Bitwarden vs Passbolt, we help teams work out which design fits their users, directory, audit needs and recovery expectations before any installation begins.
How we scope
- Written scope fixes which edition, directory sync, SSO and import sources are covered before work starts.
- We confirm current edition terms, licensing for paid features and data region requirements with the vendor before scoping.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing, and a quote follows from that scope.
How we build
- We deploy the chosen platform in your cloud account, data center or air-gapped network, not on DeployOpen systems.
- Directory integration, SSO configuration, import testing and export policy settings are built and tested against your own tenant.
- Hardening, backup and restore checks are run and documented so your team can see how the deployment behaves.
How we hand over
- Handover includes architecture notes, admin runbooks and the configuration decisions behind each design choice.
- Migration plans cover user onboarding, shared item ownership and what must be redone after moving between platforms.
- We prepare documentation and evidence for your compliance assessment, while independent auditors issue any formal reports.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
- Retainers can cover version upgrades, patch review and periodic security testing of the password manager deployment.
- Before choosing a retainer, ask what response commitments and upgrade windows the written scope includes.
