Bitwarden vs Vaultwarden vs Passbolt

Passbolt's design gives every user a key pair, so a shared secret exists as one encrypted copy per person with access. Each user who can open a shared resource receives their own copy encrypted with their public key, following the OpenPGP standard. The Passbolt server only receives and stores ciphertext. Encryption and decryption happen locally in the browser extension or mobile app, never on the server, and the browser extension is cryptographically signed. Bitwarden and Vaultwarden use a vault model in which the server holds the encrypted vault for the organization, so the operational questions differ. Before deciding, confirm with Bitwarden's documentation and the Vaultwarden project how their encryption keys are derived, stored and protected, and whether an administrator can reach a member's data without that member's participation.

Metadata deserves a separate check. Passbolt's documentation says names, URLs and descriptions are encrypted only with the v5 format and only when the organization enables metadata encryption. An illustrative review question for a regulated team: if the server database were copied, would resource titles and login URLs still be readable? Answer that for the exact version and settings you plan to run, not for the defaults you remember. Ask the vendor to document which fields remain in cleartext in your configuration.

Key loss and recovery are the trade-off to plan around. Because each person's access depends on their own private key, a lost key or an unrecoverable account can strand the secrets only that person received, so account recovery and admin control must be designed before rollout. Passbolt's comparison lists account recovery as a Pro feature not in Community Edition, so check which recovery path your edition provides, who approves it, and what an administrator can and cannot decrypt. Test a recovery exercise with a non-production user, and write down the escalation steps for a departed employee whose keys are still held.

Single sign-on and directory sync are where the three platforms differ most in licensing, so confirm the path you need before comparing anything else. Bitwarden's SSO integration modules sit in the bitwarden_license directory under the Bitwarden License, which the server license FAQ describes as source-available rather than open source, and production use of that code requires a paid subscription. Directory sync for AD, LDAP, Azure, Google Workspace or Okta runs through Directory Connector, a separate GPL-3.0 client that the Bitwarden Directory Connector repository documents. Plan these as two separate licensing questions: the SSO module and the sync client.

Vaultwarden takes a different path. Vaultwarden 1.35.0 added single sign-on with OpenID Connect, and later releases through 1.37.3 added fixes and settings such as SSO_SIGNUPS_ALLOWED. Its README also lists Directory Connector support. Because the SSO feature is newer than Bitwarden's official module and the project is maintained by volunteers, confirm the exact OIDC flow, the identity provider versions you run, and how group and user provisioning behaves from Directory Connector before you depend on it.

Passbolt keeps directory and SSO features in the Pro edition. Its comparison lists LDAP user and group provisioning from AD or OpenLDAP, SSO with Microsoft, Google, OpenID and AD FS, and SCIM as Pro features absent from Community Edition. Test each path in a staging environment with your real identity provider, including deprovisioning, since a removed directory user must lose access to shared resources. Whichever platform you choose, rehearse one joiner, mover and leaver cycle and record the result before rollout.

Setup effort starts with the license and the install path. A standard self-hosted Bitwarden installation needs an installation ID and installation key, retrieved with a valid email address from bitwarden.com/host, before the server will run as a supported standard deployment. The Linux install guide lists a minimum of an x64 1.4 GHz processor, 2 GB of RAM and 12 GB of storage, recommends 4 GB of RAM and 25 GB, and requires Docker Engine 26 or later. The default database is the bundled MSSQL Express image, which carries a 10 GB database size limit, so confirm growth expectations for your user count before you commit. Vaultwarden is lighter: it runs from its container images on ghcr.io, docker.io or quay.io, and its own README requires HTTPS for the web vault because of the Web Crypto API. Set DATABASE_URL early, since SQLite is the default and the .env.template marks PostgreSQL as recommended. Passbolt documents installation on Debian 13, Ubuntu 26.04, several Red Hat family and SUSE releases, Docker, a Helm chart, an AWS AMI and Ansible. Its virtual appliance is a Pro-only option, so check the edition you plan to buy before you plan the install method.

Migration is where the risk sits. Bitwarden's documented cloud to self-hosted path has the organization export its data, download its license, create a self-hosted account with the same email and import the data. Attachments, member invitations, enterprise policies and SSO must be rebuilt by hand, so inventory those items and budget admin time for them. Moving between Bitwarden and Vaultwarden, or from either to Passbolt, has no equivalent step in the supplied material, so ask each vendor and your own test team to document the exact export and import steps for your data before you assume a clean move. Under any of the three options, your team owns backups and restore testing. The Vaultwarden README states that its maintainers cannot be held liable for data loss and recommends regular backups of files and the database. Test a full restore on a separate host, not just a backup job that reports success, and confirm who runs the restore when an incident occurs.