# passbolt_api: the self-hosted password manager backend teams can audit

> Passbolt Community Edition ships its server as a CakePHP JSON API with end-to-end encrypted secrets. Here is what the repository actually contains, how to install it, and where it stops being the right tool.

**passbolt/passbolt_api** — Passbolt Community Edition (CE) API. The JSON API for the open source password manager for teams!

- Repository: https://github.com/passbolt/passbolt_api
- Website: https://passbolt.com
- Stars: 6,144 · Forks: 403
- Language: PHP
- License: AGPL-3.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/passbolt-passbolt-api

## What passbolt_api actually is, and who it is for

Passbolt describes itself as "the open source password manager for teams", and this repository is the server half of that product. It is a JSON API written in PHP on CakePHP 5, with the topics list naming cakephp, cakephp5, credentials, password, password-manager, php, productivity and security. The front end is not here. The README points to browser extensions for Chrome, Firefox and Edge, mobile apps on the App Store and Google Play, a separate CLI tool called go-passbolt-CLI, and a desktop app described as "Coming soon" with a pre-alpha repository at passbolt/passbolt-windows.

The intended user is an operations or security team that wants credential sharing inside its own perimeter. The README states the product can be deployed in an air-gapped environment and that Passbolt does not collect personal data or telemetry. That combination is the selling point: you own the database, and the vendor has no channel into it. It is a poor fit for a solo developer who just wants a hosted vault, because you still have to run PHP, a database and a web server, and the browser extension is not optional for normal use.

## The end-to-end key model that shapes every API call

The README's first differentiator is the security model: "user-owned secret keys and end-to-end encryption". That single sentence explains most of the API's shape. Secrets are encrypted to recipients' OpenPGP keys, so the server stores ciphertext and public keys rather than readable passwords. Sharing a credential is a re-encryption operation performed on the client, not a permission flag the server flips.

The repository layout backs this up. There is an openpgp dependency in package.json at version ^5.11.3, and the npm scripts copy:dependencies, copy:styleguide and copy:locales pull the shared passbolt-styleguide package into the build. The API therefore has to serve the client application assets and the shared crypto/front-end code, not just JSON. The practical consequence is that you cannot treat this as a stateless microservice behind a load balancer. Session handling, the extension handshake and the key material all have to line up, and an integration that ignores the client-side decryption step will get armoured blobs it cannot read.

The security posture is also documented as externally reviewed. The README says Passbolt "is audited multiple times annually, and findings are made public", with a link to a code review FAQ. That is a claim about process, not a guarantee about your deployment, and the README does not describe a bug bounty scope or a response-time commitment.

## Installing passbolt_api: Docker, packages, or a checkout

The README does not embed install commands. It presents a grid of platform icons, each linking to a page on passbolt.com for Docker, Kubernetes, Ubuntu, Debian, RedHat, Raspberry Pi, RockyLinux, AlmaLinux, Oracle, Fedora, openSUSE, AWS, DigitalOcean and CentOS. The section is titled "Run it on your own server, natively". If you want the supported path, follow the link for your platform; the repository itself is the source tree, not the installer.

For a source checkout, the top-level entries show what the build expects: composer.json and composer.lock for PHP dependencies, package.json and package-lock.json for the Node tooling, config/ for application configuration, and a Tiltfile plus a .ddev/ directory for local development environments. The package.json declares the Node requirement explicitly, so a Node version below that will fail the copy scripts rather than the PHP application.

## A first run from source, in the shape the repository implies

The package.json engines field is the one hard version constraint the repository states outright. Install PHP dependencies with Composer and Node dependencies with npm before anything else, because the copy scripts move the styleguide and locale files that the templates expect.

## Where passbolt_api is the wrong tool

The failure mode is expecting a conventional secrets API. If your deployment pipeline wants to fetch a database password with a token and inject it into an environment variable, this server will hand you OpenPGP-encrypted content that your pipeline cannot decrypt without a private key. Putting that private key on a build runner moves the secret out of the vault, which defeats the model the README describes. The go-passbolt-CLI project exists precisely because the raw API is awkward for automation.

There is a second constraint in the README's own framing. It is a password manager for teams, and the collaboration features are described as policies "for power users". A single-person install pays the full operational cost of PHP, a database, a web server and TLS for a vault one person uses. The README also lists a desktop app as "Coming soon" with only a pre-alpha repository, so anyone who needs a native desktop client today is relying on the browser extension or the mobile apps.

Finally, version discipline matters more than usual here. The npm dependency on passbolt-styleguide is pinned at ^5.16.1 while the most recent release listed is v5.16.0, and the repository carries both phpstan-baseline.neon and psalm-baseline-v5-upgrade.xml. Those baseline files record accepted static-analysis findings, which means a clean PHPStan or Psalm run on a fresh checkout is not the same as a clean run with the baselines removed.

## How it differs from Vault and from Bitwarden's server

HashiCorp Vault is the closest comparison in the infrastructure space, and the difference is architectural rather than cosmetic. Vault is built around dynamic secrets: it can generate a short-lived database credential on request and revoke it when the lease expires. Passbolt stores credentials that a human created and shares them to other humans' keys. Vault's server can read what it issues; Passbolt's server, by design, holds ciphertext it cannot open. If your problem is machine-to-machine secrets with rotation, Vault's model fits and Passbolt's does not. If your problem is a shared administrative password that three people need and an auditor wants to see access history for, Passbolt's model is the more direct answer.

Bitwarden also publishes a self-hostable server, and the comparison is about client shape. Bitwarden's clients are first-class native applications across desktop and mobile. Passbolt's README lists a desktop app as not yet available and routes desktop users to browser extensions from Chrome, Firefox and Edge. The trade-off is that Passbolt's extension-mediated flow is what enforces the key handling; there is no path where the server sees your plaintext, which is the property the README leads with.

## Licence, upgrade cost, and what the repository tells you about maintenance

The licence is AGPL-3.0, stated in package.json and in LICENSE.txt, and the README's badge links to the same file. The practical implication of AGPL-3.0 for a network-delivered service is that users interacting with a modified version over a network are entitled to the corresponding source. If you patch this code and expose it to your staff, that obligation is worth understanding before you ship. This is not legal advice; read LICENSE.txt and, if the answer matters commercially, ask counsel.

The release cadence is visible in the tags: v5.16.0 on 2026-09-17, v5.15.0 on 2026-08-21, and v5.14.3 on 2026-08-06. The last push to the default branch was on 2026-09-17. The repository is not archived. Upgrade cost is dominated by the tight coupling between the API and the styleguide package, since the npm scripts copy shared assets into the build; a version skew between the two is a build-time problem, not a runtime one. The CHANGELOG.md and RELEASE_NOTES.md files at the repository root are where the project records what changed between those tags, and the README does not document a rollback procedure for a failed upgrade.

## Conclusion

Adopt passbolt_api if you need a self-hosted backend where the server never holds plaintext secrets and you are willing to run a browser extension as part of the workflow. Do not adopt it if you want a plain REST service that returns passwords to a script: the API returns OpenPGP-armoured material that the client must decrypt, and the README does not document any server-side decryption path. Before committing, verify the AGPL-3.0 obligations against how you distribute your own code, and confirm the supported install path for your OS on the passbolt.com CE pages, since the README links there rather than embedding steps.

## FAQ

### How do I use the passbolt_api?

You run the server, then connect to it through one of the clients the README lists: the Chrome, Firefox or Edge browser extension, the mobile apps, or the separate go-passbolt-CLI tool. The API itself serves the client application and the encrypted credential data, so a raw HTTP client is not the intended entry point.

### How do I install passbolt_api on my own server?

The README does not embed install steps. It links to platform-specific pages on passbolt.com for Docker, Kubernetes, Ubuntu, Debian, RedHat, Raspberry Pi, RockyLinux, AlmaLinux, Oracle, Fedora, openSUSE, AWS, DigitalOcean and CentOS, under the heading "Run it on your own server, natively".

### Does passbolt_api store my passwords in readable form?

No. The README describes the security model as user-owned secret keys with end-to-end encryption, so the server holds ciphertext and public keys. Decryption happens on the client side, which is why the browser extension is part of the normal workflow.

### What licence does passbolt_api use?

AGPL-3.0, declared in package.json and in the LICENSE.txt file at the repository root. Because the software is delivered as a network service, the AGPL's source-availability terms apply to modified versions you expose to users.

### Is there a Python client for passbolt_api?

The README does not list one. It lists browser extensions, iOS and Android apps, the go-passbolt-CLI tool, and a desktop app marked "Coming soon". Any Python integration would be something you write against the JSON API yourself.

## Sources

- [License: AGPL-3.0](https://github.com/passbolt/passbolt_api/blob/master/LICENSE)
- [passbolt/passbolt_api on GitHub](https://github.com/passbolt/passbolt_api)
- [Project website](https://passbolt.com)
- [README](https://github.com/passbolt/passbolt_api/blob/master/README.md)
- [Releases](https://github.com/passbolt/passbolt_api/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/passbolt-passbolt-api