Why Teams Are Ditching SaaS Password Managers for Self-Hosted Control
Most password managers work on a simple promise: trust us with your keys, and we’ll keep them safe. For individual users, that tradeoff is usually fine. For teams handling client credentials, internal systems, or regulated data, handing that trust to a third-party SaaS platform carries real risk – a vendor breach, a surprise pricing change, or a policy update that conflicts with your compliance requirements can all create serious problems overnight. Passbolt exists as a direct answer to that problem.
Passbolt is an open-source password manager built specifically for teams. Unlike consumer tools bolted onto a business plan, it was designed from the ground up for shared credential management, role-based access, and full server-side control. Every password is encrypted client-side using OpenPGP before it ever leaves the user’s device, which means even if someone gains access to your server, they still can’t read the stored credentials without the private keys.
Self-hosting Passbolt takes about an hour if you follow the right sequence.

Server Requirements and Initial Setup
Passbolt runs on a standard Linux server. The officially supported environments include Ubuntu 20.04/22.04 and Debian 10/11, and the Passbolt team provides a dedicated installer script that handles the full stack – Nginx, MariaDB, PHP, and the application itself. A minimum of 1 vCPU and 2GB RAM is workable for small teams, though 4GB is more comfortable once you add several users and browser extension activity picks up. You’ll also need a domain name with a valid SSL certificate, because the browser extension will refuse to connect over plain HTTP.
Start by provisioning a fresh server and pointing your domain’s DNS A record at its IP address. Once DNS has propagated, SSH into the server and run the official installer script from Passbolt’s documentation. The script walks through several prompts: your domain name, whether to generate a self-signed certificate or use Let’s Encrypt (choose Let’s Encrypt for production), database credentials, and SMTP settings for outgoing email. Email configuration is not optional – Passbolt uses email to send user invitations and account recovery links, so skipping it will break the onboarding flow for every new team member you try to add later.
After the installer completes, it will print a URL to finish setup in the browser. Navigate to that URL, create the admin account, and generate your first OpenPGP key pair when prompted. This keypair is tied to the admin account specifically and is stored locally in your browser via the Passbolt extension. Write down your passphrase and back up the private key file immediately – losing it means losing access to that account permanently, with no server-side recovery path.
Configuring Users, Groups, and Permissions
Passbolt’s permission model is folder and group based. Passwords can be shared with individual users or with groups, and each share can be set to “Can Read” or “Can Update” access. Folders work as organizational containers that inherit their permissions downward, so if you share a folder with the DevOps group, every password inside it becomes accessible to that group without separate configuration. This makes bulk access management straightforward once your groups reflect your actual team structure.

To invite a new user, go to the Users section in the admin panel and send an invitation via email. The invited user installs the Passbolt browser extension (available for Chrome, Firefox, and Edge), clicks the link in the email, and generates their own OpenPGP keypair during account setup. Their private key never leaves their device. When they’re added to a shared folder or a password is shared with them directly, Passbolt re-encrypts the relevant credentials using that user’s public key – so only they can decrypt it on their end. This architecture means compromising the server database gives an attacker nothing usable without the corresponding private keys.
Groups are created under the admin panel’s Groups section and can be assigned to multiple folders simultaneously. A practical setup for most small-to-mid-size teams is to create groups that map to functional roles: Engineering, Finance, Marketing, and so on. Avoid the temptation to share everything with everyone for convenience – the value of Passbolt over a shared spreadsheet is exactly the granularity of access control it provides. Passwords that only two people need should be shared with those two people, not the entire organization.
Browser Extension, CLI Access, and Mobile
Day-to-day use happens almost entirely through the browser extension. Once installed and linked to your Passbolt server, it auto-fills credentials on recognized domains and lets users create, edit, and share passwords without leaving the browser. The extension detects the current site’s domain and suggests matching entries from the user’s accessible passwords – similar to how 1Password or Bitwarden handle autofill, but with all encryption handled locally and all storage happening on your server.
Passbolt also ships a command-line interface called passbolt-cli, which is useful for automation workflows – injecting credentials into deployment scripts, retrieving API keys without logging into the web interface, or integrating with CI/CD pipelines. Mobile access is available through dedicated iOS and Android apps, both of which connect to your self-hosted instance using the same server URL and the same OpenPGP keypair synced from the browser extension setup. The mobile apps support biometric unlock for the local session while keeping the underlying encryption architecture intact.
Backups deserve a dedicated step in your setup checklist. Passbolt stores its data in MariaDB, and a simple mysqldump on a cron schedule pointed at an off-site location covers the database side. The server’s configuration files live in /etc/passbolt/, and those should be included in any snapshot or file-level backup. One thing the backup does not protect: individual users’ private keys. Each team member is responsible for keeping their own key safe. If someone loses their private key and your organization hasn’t configured account recovery (a paid feature on the Community Edition’s paid tiers), that account is effectively locked out forever.

The Community Edition of Passbolt is free and covers everything described above. The paid tiers add SSO integration, LDAP/Active Directory sync, and account recovery – features that matter significantly once a team grows past a dozen people or operates inside a corporate directory. For a team that’s already managing its own infrastructure, running Passbolt on the same server stack as other internal tools costs almost nothing in marginal resources, and it keeps credential storage inside an environment you already control, audit, and own.
Frequently Asked Questions
Is Passbolt free to self-host?
Yes. The Community Edition is fully free and open-source. Paid tiers add features like SSO, LDAP sync, and account recovery for larger teams.
What happens if a user loses their Passbolt private key?
Without account recovery enabled (a paid feature), that user loses access permanently. The server cannot recover private keys by design.





