Passbolt vs Vaultwarden: when each one fits a self-hosted team
Choose Passbolt when your team needs per-user OpenPGP encryption and directory or SSO controls, and you are willing to pay for them. Choose Vaultwarden when your team wants clients it already knows from Bitwarden and a free, lightweight server. The first decision is whether SSO, LDAP provisioning and account recovery must be available without a license. In Passbolt, the Community Edition is free and self-hosted, but the Pro features listed on its pricing comparison include LDAP user and group provisioning, account recovery, SSO with Microsoft, Google, OpenID and AD FS, and MFA policies. Confirm those features against the current Passbolt pricing page before you budget, because the per-user price and the 10-user minimum apply to Pro, not to Community. Vaultwarden added SSO with OpenID Connect in version 1.35.0, and its README lists directory connector support, organizations with collections and event logs. Check which of these your identity provider and audit process actually need.
The second driver is how much your team trusts a community-run server. Vaultwarden is an alternative implementation of the Bitwarden Client API. Its README states that it is not associated with Bitwarden, Inc., that one active maintainer is employed by Bitwarden but contributes on personal time, and that the maintainers focus on individuals, families and small organizations. It also tells users to report bugs to the Vaultwarden project rather than to Bitwarden support, and it recommends regular backups of files and the database. Passbolt is developed by a company that sells Pro, Cloud and Enterprise editions, and its encryption model puts each user's copy of a shared secret under that user's public key, so the server only stores ciphertext. Ask your security team whether a vendor-backed support path or the Passbolt cryptographic design matters more for your risk register.
The third driver is who will support the platform after go-live. Decide whether an internal team will run upgrades, backups and reverse proxy configuration, or whether you will buy support or an implementation partner for that work. Vaultwarden runs on SQLite by default and recommends PostgreSQL through DATABASE_URL, and it requires HTTPS for the web vault, so you will own that configuration. Passbolt documents installation on several Linux distributions, Docker, a Helm chart and Ansible. Before you commit, map your team's migration path from your current manager, since both tools import from common formats but Passbolt's cleartext CSV export is disabled by default since version 5.10, and confirm each export policy with your own administrators.
Which platform fits which scenario
This table matches common team situations to the platform that fits better and the condition that decides it. Read each row against your own directory, client base and tolerance for single-maintainer risk, because the answer changes when those conditions change.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Small team with no directory and no SSO | Vaultwarden | Community use needs no paid tier, and Vaultwarden's organizations, collections and sharing cover small team structures without LDAP or SSO provisioning |
| Regulated team that needs LDAP or SSO provisioning | Passbolt Pro | LDAP user and group provisioning, SSO with Microsoft, Google, OpenID and AD FS, and SCIM are listed as Pro features in Passbolt's pricing comparison, so confirm the edition covers your identity flow |
| Team already using Bitwarden clients | Vaultwarden | Vaultwarden is compatible with the official Bitwarden clients, so existing users may keep their apps, but confirm your client versions and features against the current Vaultwarden release |
| Team that wants paid vendor support | Passbolt | Passbolt sells Pro and Enterprise editions with vendor-facing terms, while Vaultwarden is an independent project that asks users to report issues to the Vaultwarden project; confirm support terms with each vendor before purchase |
| Team that must avoid reliance on a single maintainer | Passbolt | Vaultwarden's README states one active maintainer is employed by Bitwarden and contributes on their own time, so a larger maintainer base should be verified against your own risk review |
| Team that wants per-user OpenPGP encryption of each shared secret | Passbolt | Passbolt gives each user a key pair and encrypts shared resources to each recipient's public key, a design that differs from Vaultwarden's Bitwarden-compatible vault model |
| Team that wants a lightweight server footprint | Vaultwarden | Vaultwarden was written in Rust as a lighter alternative to the official Bitwarden service, and its default SQLite storage can be replaced with PostgreSQL as the team grows |
How Passbolt and Vaultwarden are built and deployed
Both products are self-hosted password managers, but they differ in where encryption keys live, which databases they expect and how they are installed. Those differences drive backup scope, upgrade effort and the skills your operations team needs. The cards below cover the decisions that matter most before you choose.
Per-user OpenPGP key pairs
Passbolt gives each user an OpenPGP key pair and stores a separate copy of each shared secret encrypted to every authorized user's public key. Encryption and decryption happen in the browser extension or mobile app, so the server only holds ciphertext. This means losing a user's private key can cut off access to their secrets, so key recovery and offboarding procedures must be part of your runbook. Ask how metadata encryption is enabled for your organization.
Bitwarden-compatible vault model
Vaultwarden implements the Bitwarden Client API, so the official Bitwarden clients connect to a server you run. Vault data is protected by the client-side design inherited from Bitwarden rather than by per-user OpenPGP keys, which changes what a recovery or key-loss scenario looks like. Confirm with the project how the vault encryption model maps to your recovery and audit requirements before you commit to a rollout.
Database choice and backup scope
Vaultwarden uses SQLite by default, and its configuration template recommends PostgreSQL, which is set through DATABASE_URL. Passbolt runs on the supported Linux distributions and Docker, Kubernetes or AMI install paths listed in its hosting guide, with its own database and file state to back up. Whichever you pick, plan backups of both the database and the attachment and configuration files, and test restores on a schedule. The Vaultwarden README highly recommends regular backups of files and the database.
Passbolt install targets
Passbolt's hosting guide lists Debian 13, Ubuntu 26.04, Red Hat family distributions, openSUSE Leap 15 and SLES 16, Docker, a Kubernetes Helm chart, an AWS AMI and Ansible. A virtual appliance is available for Pro only. Match the install target to the patching and image pipeline your platform team already runs, and confirm which targets your chosen edition supports before standardizing.
Container and Helm deployment paths
Vaultwarden recommends its container images on ghcr.io, docker.io and quay.io and asks for HTTPS in front of the web vault, typically through a reverse proxy. Passbolt publishes Docker images and an official Helm chart in its charts-passbolt repository, both under AGPL-3.0. Check how each image tag is pinned and which upgrade path your team will follow, because an unpinned container pull can change the server without a planned change window.
Upgrades and release cadence
Passbolt publishes numbered releases such as v5.16.0, and Vaultwarden publishes releases such as 1.37.4. Both projects change server behavior between versions, so each upgrade needs a backup, a staging run and a rollback plan. Confirm the upgrade notes for your current version and, for Passbolt, check whether an Ansible or Helm workflow is already maintained for your target platform.
What per-user OpenPGP encryption changes about the trust model
Passbolt's model moves the trust boundary to the user's own device. Encryption and decryption happen locally, in the browser extension or the mobile app, and the Passbolt server only receives and stores ciphertext. Each user has an OpenPGP key pair, and every user with access to a shared resource holds their own copy of that secret, encrypted with their public key. The practical consequence for an administrator is that the server cannot read a password on its own, but the loss of a user's private key or passphrase means that user's access to the secrets encrypted for them is lost too. Plan key backup, recovery and offboarding as part of the rollout, not as an afterthought.
Metadata is a separate question. Passbolt's documentation says names, URLs and descriptions are encrypted only with the v5 format and only when the organization enables metadata encryption. Check which format your instance uses and whether that setting is on before you import sensitive records, because the answer determines what a database dump or an administrator reading the server would reveal. Also confirm how the browser extension is distributed and verified in your environment, since the extension is the component that holds the keys in use. Passbolt's how it secures your data page is the starting point for those details.
Vaultwarden is a Bitwarden-compatible server, and its trust model and recovery features differ from Passbolt's OpenPGP design. Do not assume either way. Ask the Vaultwarden project and your own security team to document how vault keys are derived and held, what an administrator can and cannot read, how emergency access and admin password reset behave in your edition and configuration, and what happens to a locked-out user's data. Test those flows in a non-production instance with a user who has lost access, and record the result. Your conclusions should come from that test, not from a general description of either product.
Capability comparison: sharing, SSO, LDAP, recovery and imports
This table compares the features that most often decide a self-hosted team password manager, with Pro-only Passbolt features marked as such. Read each row against your own identity provider, audit obligations and migration source, and confirm any Vaultwarden capability that the supplied README facts do not cover. The main takeaway is that Passbolt's directory, SSO, recovery and logging controls sit in its paid Pro edition, while Vaultwarden's organization model and SSO ship in one server build.
| Capability | Passbolt | Vaultwarden |
|---|---|---|
| Encryption model | OpenPGP per-user key pairs; each user with access receives their own encrypted copy; encryption happens in the browser extension or mobile app | Bitwarden-compatible vault encryption through official Bitwarden clients; confirm the exact key model in its documentation |
| Sharing and permissions | Resources shared to individual users and groups, with each recipient holding their own encrypted copy (Community and Pro) | Organizations with collections, password sharing, member roles and groups, per the README |
| SSO | Pro only: Microsoft, Google, OpenID and AD FS | OpenID Connect SSO added in 1.35.0 (December 27, 2025), with later SSO settings through 1.37.3; confirm provider coverage |
| LDAP and SCIM provisioning | Pro only: LDAP user and group provisioning from AD or OpenLDAP; SCIM listed as Pro | Directory Connector support is listed in the README; confirm LDAP and SCIM behavior for your directory |
| MFA options | Pro only: MFA policies; confirm which second factors are available in Community | Authenticator app, email, FIDO2 WebAuthn, YubiKey and Duo for two-factor login |
| Account recovery | Pro only: account recovery | Emergency access and admin password reset are listed; confirm recovery workflow and key handling |
| Logging and audit | Pro only: syslog activity logs; confirm what Community records | Event logs for organizations, per the README; confirm export and retention options |
| Import sources | Community, Pro and Cloud: CSV from LastPass, 1Password, Dashlane, NordPass, LogMeOnce, Bitwarden, browsers; CSV and KDBX for KeePass; KDBX for Keeper | Confirm supported import formats in Vaultwarden's documentation before planning a migration |
| Export formats | Since 5.10, cleartext CSV is off by default; encrypted KDBX offered unless an admin re-enables CSV | Confirm export formats and whether cleartext export is restricted by default |
| License | AGPL-3.0 for the API server and official Docker and Helm repositories; paid Pro and Cloud editions | AGPL-3.0, with no paid edition described in the supplied facts |
What each license and edition costs and includes
Passbolt Community Edition is the free self-hosted tier, and the Passbolt pricing page lists it with unlimited users. It runs on your own servers, so the licence cost is zero but the hosting, patching, backups and TLS are your responsibility. The API server repository is licensed under AGPL-3.0, which matches the open-source nature of the server code you deploy.
- Unlimited users: the pricing page lists unlimited users for the self-hosted Community Edition.
- Core sharing model: each user holds a key pair and receives their own encrypted copy of each shared resource.
- Import support: CSV imports from common managers are listed for Community, Pro and Cloud editions.
- Missing paid features: LDAP provisioning, account recovery, SSO with Microsoft, Google, OpenID or AD FS, MFA policies, syslog logs, SCIM and password policies are listed as Pro features.
- Operating cost: staff time for upgrades, backups and monitoring recurs whether or not a licence is paid.
Check the Passbolt pricing comparison before committing, because the feature split between Community and Pro is set there and can change between releases.
Passbolt Pro adds directory and identity features on top of the Community Edition. The pricing page lists Pro at $4.9 per user per month billed annually, with a 10-user minimum and volume discounts after 100 users. The published figure is the list price at the time of writing, so the quote from Passbolt governs what your organization pays.
- Published price: $4.9 per user per month, billed annually, with a 10-user minimum on the pricing page.
- Volume discounts: the pricing page notes discounts after 100 users, so ask for the tier that applies to your count.
- Identity features: LDAP user and group provisioning from AD or OpenLDAP, SSO, SCIM and MFA policies are Pro features.
- Recovery and governance: account recovery, password and passphrase policies, password expiry and tags sit in Pro.
- Virtual appliance: the hosting guide lists a virtual appliance for Pro only.
For a 10-user team, multiply the per-user rate by 12 months and by the user count to estimate the annual licence line, then confirm with Passbolt whether taxes and currency terms change the figure.
Passbolt Cloud is the cloud-managed edition, where Passbolt operates the service. It shifts server hosting, upgrades and backups to the vendor, so the cost model moves from staff time to subscription. Because the data path changes, the question is not only price but where ciphertext and metadata live and who controls the server.
- Vendor-run service: Passbolt hosts and maintains the server rather than your team.
- Subscription cost: the cloud edition is priced by the vendor, so ask for the current rate and terms in writing.
- Import and export: the import list covers Cloud as well as Community and Pro.
- Control trade-off: you give up direct control over the server location, patch timing and backup schedule.
- Exit planning: confirm export formats and data return terms before adopting it.
Ask Passbolt to state the cloud edition's price, included features, data location and exit process in writing, since the pricing page does not give these details in a form you can compare directly with self-hosting.
Passbolt Enterprise is listed on the pricing page at custom pricing, so no public figure exists. Enterprise terms are negotiated with the vendor, and the scope usually depends on organization size, support expectations and deployment requirements. Treat it as a separate commercial conversation rather than a fixed tier you can budget from a web page.
- Custom pricing: the pricing page gives no published figure, so request a written quote.
- Scope to define: list the user count, required identity features, support hours and hosting targets before asking.
- Support terms: ask what response commitments are included and whether they are written into the contract.
- Feature confirmation: verify in writing which Pro features are included, since the public comparison is the starting point.
- Contract length: ask whether pricing is annual, multi-year or subject to renewal increases.
Request the Enterprise quote and the Pro quote together, so you can compare what each includes against your required feature list.
Vaultwarden is licensed under AGPL-3.0, and the repository's LICENSE.txt is the governing text. No paid Vaultwarden edition is supplied for this comparison, so the licence cost is zero and the costs are the infrastructure, the administration time and any outside support you choose to buy. Its features, including SSO with OpenID Connect added in version 1.35.0, are in the open project rather than behind a paid tier.
- Licence: AGPL-3.0, which governs redistribution and network use of modified versions.
- Infrastructure cost: the server runs on your hardware or cloud account, so hosting and backups are your costs.
- Feature access: SSO, organizations, collections, groups, event logs and emergency access are described in the README.
- Support model: the README directs bugs to the Vaultwarden project, not Bitwarden support, and maintainers do not accept liability for data loss.
- Hidden effort: regular backups of files and the database are strongly recommended, and that duty stays with your team.
Confirm with the Vaultwarden project or your own review whether any third-party support, hosting or add-on you plan to use carries its own licence or fee.
What drives the running cost of each platform
Passbolt and Vaultwarden both run on your own infrastructure, so the license line is only part of the bill. The cards below separate recurring costs from one-time setup and name what to put in a written quote before you compare totals.
Infrastructure and database hosting
Both platforms are self-hosted, so you pay for the servers, storage, backups and reverse proxy in your own cloud account or data center. Vaultwarden uses SQLite by default and can use MySQL or PostgreSQL through DATABASE_URL, with PostgreSQL marked as recommended in its configuration template. Passbolt is installed on a supported Linux distribution, Docker, Kubernetes or another listed target, and its database and HTTPS termination are yours to size. Ask each vendor or integrator which database tier and high availability setup they assume, since that choice sets the recurring hosting bill.
Administrator time for upgrades and backups
Vaultwarden's maintainers recommend regular backups of files and the database and state they cannot be held liable for data loss, so backup and restore testing falls to your team. Passbolt upgrades and backups follow the same pattern on your servers. Staff time for patching, release tracking and restore drills is a recurring cost that often exceeds the software line. Ask who performs upgrades, how often, and whether restore tests are included in scope.
Passbolt Pro subscription seats
Passbolt Community is free to self-host with unlimited users, but LDAP provisioning, account recovery, SSO, MFA policies, syslog logs and SCIM are Pro features. Pro is priced per user per month billed annually, with a 10-user minimum and volume discounts after 100 users, according to Passbolt's pricing page. Seat count therefore recurs and grows with headcount. Vaultwarden has no equivalent seat fee for its self-hosted server, so model Pro seats against the features your team actually needs.
Support contracts and retainers
Vaultwarden asks users to report bugs to its own project rather than Bitwarden support channels, and its maintainers focus on individuals, families and small organizations. Passbolt sells Pro and Enterprise tiers with vendor support, and DeployOpen offers ongoing support as a retainer. Community support is free but has no response commitment. Ask any vendor for the written response terms, hours covered and escalation path, and treat them as recurring costs.
External implementation services
Setup work such as SSO configuration with your identity provider, LDAP or directory integration, hardening, migration from an existing password manager and documentation is usually a one-time project. DeployOpen plans and implements these as fixed-scope engagements agreed in writing before work starts. Passbolt imports from common managers such as LastPass, 1Password and Bitwarden, and Vaultwarden is Bitwarden-compatible, which narrows migration work. Ask for deliverables, acceptance criteria and whether migration of shared folders and permissions is included.
Cost of leaving later
Switching later costs export effort, re-enrollment of every user, and re-building sharing structures. Passbolt exports default to encrypted KDBX formats since version 5.10, with cleartext CSV disabled unless an administrator re-enables it, which can slow an exit. Vaultwarden exports are Bitwarden-compatible, so tooling is broader. Ask each side what export formats, admin time and data-verification steps an exit would require, and price that scenario into the comparison.
How to move a team from Vaultwarden to Passbolt, or back
The sequence moves a team's credentials, sharing and sign-in setup from one server to the other without leaving a copy of cleartext secrets behind. The end state is one live server, verified users and groups, and a retired source that no one can still write to.
Inventory vaults, sharing and sign-in dependencies
The team lead and the server owner list every shared collection, organization member, group, and any SSO or LDAP connection that Vaultwarden uses today. They also record which users rely on two-factor methods such as FIDO2 or YubiKey, because those enrollments will need to be repeated. Confirm the list against the Vaultwarden admin page and your identity provider. The step is done when someone other than the author can read the list and recognize every user and shared folder.
Export from Vaultwarden and handle the file
An owner of each organization exports its vault from the Vaultwarden web vault, using an encrypted export where the option is offered. Store any exported file in an approved location with restricted access, and do not email it or leave it in a shared drive. Confirm the export format and field coverage for your source before relying on it, since Vaultwarden exports and Passbolt import coverage can differ by item type. The step is done when every collection has an export file and a record of which file came from which collection.
Stand up and configure the Passbolt server
The platform team installs Passbolt in your own infrastructure using one of the supported hosting paths, such as Docker, the Helm chart, or the Linux packages listed in the hosting guide. They configure HTTPS, backups and the administrator account before any user data arrives. The team confirms that the edition matches the features needed, since SSO, LDAP provisioning and account recovery are Pro features rather than Community Edition features. The step is done when a test user can sign in over HTTPS and the server backup has run once successfully.
Import into Passbolt and check coverage
An administrator imports each export file into the matching Passbolt user account, using the import pathway that matches the source format. Passbolt's documentation lists supported sources for CSV and KDBX, but coverage should be checked against your own export, not assumed. Compare item counts and a sample of entries by hand, and note any fields that did not map. The step is done when counts match for each collection and the mismatch list is written down and assigned to someone.
Rebuild sharing, groups and permissions
Passbolt encrypts each shared resource separately for every user who receives access, so the team recreates folders, groups and per-resource permissions in Passbolt rather than expecting them to carry over. The admin re-adds members, then the resource owners re-share each item with the correct groups. Check the result against the inventory from the first step. The step is done when a sample of users can open the shared items they should see and cannot open the ones they should not.
Reconfigure SSO, LDAP and MFA policies
The identity owner connects Passbolt to the directory or SSO provider, configures any LDAP user and group provisioning, and sets the MFA and password policies chosen for the team. Vaultwarden SSO settings and Passbolt SSO settings are separate, so the old configuration is not copied across. Each user then re-enrolls their second factor and confirms sign-in. The step is done when a test account has signed in through each method the team uses and every active user has a working second factor on Passbolt.
Retire the source server after verification
After the team signs off on the imported data, the server owner stops accepting new writes on Vaultwarden, takes a final backup, and shuts the service down on a set date. Remove or lock the exported files, delete temporary copies, and revoke any API keys or SSO clients that pointed at the old server. Keep the final backup for the period your records policy requires. The step is done when the old server is offline, the backup is stored and verified, and the access list records who approved the cutover.
Where Passbolt and Vaultwarden deployments usually run long
The longest delays in a Vaultwarden rollout usually come before the first user logs in, in the web vault and its surroundings. The web vault needs HTTPS because of the Web Crypto API, and Vaultwarden suggests running behind a reverse proxy, so the team must settle DNS names, certificates and proxy configuration early. Confirm who owns the public DNS zone, who issues and renews the certificate, and who maintains the proxy. Database choice follows the same pattern. Vaultwarden uses SQLite by default, while its .env.template marks PostgreSQL as recommended and selects it through DATABASE_URL. Switching later means migrating data, so decide before go-live, and set up backups of files and the database, which the maintainers highly recommend.
Passbolt's delays sit in different places. Its hosting guide covers several Linux targets, Docker, a Helm chart and Ansible, so the platform team must pick one and align it with its patching standard before installation. Directory and SSO work usually takes the most coordination. LDAP user and group provisioning, SSO with Microsoft, Google, OpenID or AD FS, and SCIM are Pro features in Passbolt's comparison, so confirm the edition before designing the integration. Ask the directory team for a bind account with read access, the group structure that will map to Passbolt roles, and the identity provider application registration. Each of these needs an administrator who can make the change in production.
Onboarding is where the per-user model adds effort that a shared-vault mindset misses. In Passbolt, each user has an OpenPGP key pair, and each user with access to a shared resource receives their own encrypted copy, so new accounts must complete key setup in the browser extension or mobile app before they can receive shared secrets. Plan the sequence with business owners, and budget administrator time for account creation, key checks and recovery requests. For Vaultwarden, the Vaultwarden README says the project is not associated with Bitwarden, that the maintainers focus on individuals, families and small organizations, and that bugs go to the Vaultwarden project rather than Bitwarden support. A regulated team should decide in advance who answers production incidents, and whether that response path is acceptable to its risk owners.
Questions teams ask before choosing or hiring help
Can Passbolt Community use SSO?
No, according to Passbolt's pricing comparison, SSO with Microsoft, Google, OpenID and AD FS is listed as a Pro feature and not part of Community Edition. The same comparison lists LDAP user and group provisioning, account recovery, MFA policies, syslog activity logs, tags, password policies, password expiry and SCIM as Pro features too. A team that needs single sign-on on the free edition should plan for Pro or confirm the current feature list on the pricing page before committing.
What does a Passbolt Pro subscription cost per user?
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. The total depends on seat count, the billing term and whether volume discounts apply at your size. Pro is a subscription paid to Passbolt, separate from any work to install or integrate the server, which is a one-time cost you agree in a written scope. Ask Passbolt for the current quote and confirm whether the price matches the published page on the date you buy.
Can a team run Passbolt or Vaultwarden without a partner?
Yes, both are self-hosted open-source projects that a capable internal team can install and operate. Passbolt's hosting guide covers Docker, a Kubernetes Helm chart, Ansible and several Linux distributions, and Vaultwarden is installed from container images and expects HTTPS and a reverse proxy. The real question is whether your team has the time to handle upgrades, backups, access reviews and incident response. If it does not, a fixed-scope implementation or retainer from DeployOpen can take over parts of that work, and the written scope should name who owns each duty.
Does switching from Vaultwarden to Passbolt keep stored passwords?
Passbolt provides CSV imports for several password managers, including Bitwarden, and lists KDBX and CSV imports for KeePass, so existing entries can usually be brought over. Passbolt encrypts each item with OpenPGP keys per user, so imported entries are re-encrypted into Passbolt's format rather than kept as Bitwarden-style vault data. Plan a test import, check folder structure, shared access and attachments, and confirm which fields survive the move before you retire the old vault. Retain a backup of the source vault until the import is verified.
Where does Vaultwarden support come from?
Vaultwarden is maintained by an open community, and its README asks users to report bugs to the Vaultwarden project rather than to official Bitwarden support channels. The README also says one active maintainer is employed by Bitwarden and contributes on personal time, and that the maintainers focus on individuals, families and small organizations. Commercial support is therefore not provided by the project itself. If your organization needs a contracted support path, ask a provider such as DeployOpen for a written scope covering support, upgrades and testing.
What does an implementation need from our internal team?
The internal team typically supplies the target infrastructure, DNS and TLS certificates, identity provider details for SSO or LDAP, a backup location, and named owners for access policy and recovery decisions. Passbolt's LDAP provisioning and account recovery features need directory and recovery decisions made in advance, and Vaultwarden needs HTTPS, a reverse proxy and a database choice. Cost rises with the number of integrations, the size of the user base and the number of migration sources. Ask for these inputs to be listed in the written scope so the quote reflects them.
Which Vaultwarden database should we choose for a team?
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 a team deployment, PostgreSQL is the option the project's own template recommends, which gives you a separate database to back up and monitor. Confirm the database choice against your backup and recovery design before rollout, and test restores rather than assuming backups work.
Does Passbolt keep the server from reading our passwords?
Passbolt's documentation states that the server only receives and stores ciphertext, and that encryption and decryption happen in the browser extension or mobile app. Metadata such as names, URLs and descriptions is encrypted only with the v5 format and when the organization enables metadata encryption. Teams with strict requirements should confirm the metadata setting for their version, and review how the browser extension is deployed and signed across their endpoints.
How DeployOpen helps choose, implement or migrate your password manager
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the Passbolt or Vaultwarden decision can be tested against your identity setup, your sharing model and your recovery requirements. We start from the written scope and do not publish a price list, so a quote follows from what you ask us to deliver.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We map which teams share credentials, which need SSO or LDAP provisioning, and which need account recovery.
- We confirm which Passbolt edition or Vaultwarden feature set your requirements need, against current vendor documentation.
- Ongoing support, upgrades and continuous testing are available as retainers after the initial scope is delivered.
How we build
- We deploy the chosen platform in your own cloud account, data center or air-gapped network.
- We configure SSO, directory integration, sharing structures, policies and backup routines to match the written scope.
- We test import and export paths from your current password manager, including how encrypted and CSV exports are handled.
- We run security testing against the deployed service and document the findings and fixes.
How we hand over
- You receive documentation covering architecture, configuration, backup and restore steps, and administrator duties.
- We document who holds which keys or recovery responsibilities so ownership is clear after handover.
- We prepare the access control and operational evidence your compliance assessor may request, without issuing any audit report or certification.
- Your team gets a runbook for upgrades, database maintenance and incident response tied to your environment.
How we support
- Support, upgrades and continuous testing can be delivered under a retainer aligned to your release cadence.
- We track vendor release and support notices so upgrade planning reflects the versions you actually run.
- We review backup and restore results periodically, since the vendor guidance for self-hosted deployments places backups on the operator.
- Before any migration to or from another platform, we agree the cutover plan and rollback steps in writing.
