passbolt_api: the server half of Passbolt, and its trademark catch

User-owned keys, and a server that never asks for them

The security model is stated in one line and everything else follows from it: user-owned secret keys and end-to-end encryption. That is what makes the client split the interesting part, because the API can only do what a client can do once the keys live with the user rather than with the server.

What this repository holds is the Community Edition API, the PHP JSON API behind that model. The clients that do the encrypting are listed elsewhere in the README: browser extensions for Chrome, which the README extends to Brave, Opera, Vivaldi and other Chromium browsers, plus Firefox and Edge, and mobile builds on the App Store and Google Play under com.passbolt.mobile.android.

The trust claims are specific rather than vague. Passbolt says it is audited multiple times annually and that the findings are made public, that it is headquartered in Luxembourg in the EU, that it collects no personal data or telemetry, and that it can be deployed in an air-gapped environment. The last one is the claim to press on: nothing in this repository documents what an air-gapped deployment actually requires, since there is no offline update path, no provisioning script and no configuration walkthrough to check it against.

AGPL v3 with the trademark withheld by Section 7(e)

The license is AGPL-3.0, and the interesting sentence is not about the code. The README states that the name Passbolt is a registered trademark of Passbolt SA, and that Passbolt SA declines to grant a trademark license to Passbolt pursuant to GNU Affero General Public License version 3 Section 7(e) without a separate agreement with Passbolt SA.

Read that as a fork with a name attached. You can read the source, modify it and redistribute it under the AGPL, and you cannot call the result Passbolt unless you have a separate agreement with the company. For an internal deployment under a different hostname that costs nothing. For anyone planning to publish a build, rebrand it and keep a support contract, it is the first question to ask, because the code licence and the name licence are two different permissions and only one of them travels with the repository.

The rest of the license section is the standard AGPL text, including the warranty disclaimer and the pointer to the GNU Affero General Public License v3 for full terms. No commercial licence is offered in this repository; the README's calls to action point to passbolt.com/ce, a Pro free trial and a cloud signup.

Fourteen platform links and no install command

The Get Started section is three banner images pointing at passbolt.com/ce, a Pro trial and the cloud signup, followed by a single table titled Run it on your own server, natively. That table is fourteen links: Docker, Kubernetes, Ubuntu, Debian, Red Hat, Raspberry, Rocky Linux, AlmaLinux, Oracle, Fedora, openSUSE, AWS, DigitalOcean and CentOS.

There is no clone command, no composer install, no database migration and no configuration file walkthrough anywhere in the README. Whatever you install, you install from a page the project hosts rather than from this repository, and the fourteen pages are separate documents that may well differ in what they ask you to configure.

That makes the README a signpost rather than a manual, which is a defensible choice for a product with this many install targets and an indefensible one if you need a reproducible, reviewable install you can put in your own infrastructure as code. Nothing in the tree closes that gap: there is a Dockerfile reference in neither README nor package.json, and no compose file or Helm chart is present at the top level.

The only commands in the tree copy assets and lint the lockfile

The npm side of this repository exists to move files around and check where they came from. package.json requires node >=16.14.0 and npm >=8.3.1, and its entire script surface is five entries. Three copy things: copy:dependencies runs node ./scripts/copy-dependencies.js, copy:styleguide runs node ./scripts/copy-styleguide.js, copy:locales runs node ./scripts/copy-locales.js. The other two are the lint pair, where lint delegates to lint:lockfile:

npm run copy:dependencies
npm run copy:styleguide
npm run copy:locales
npm run lint

The underlying lockfile-lint invocation is the only supply chain policy the project states in machine-readable form, and it is worth reading before you mirror it: the path is package-lock.json, the allowed hosts are npm and github.com, the allowed schemes are https: and git+ssh:, and empty hostnames are rejected. Two hosts and two schemes is a narrow allowlist, which is the point.

So the first thing you can actually run here is a lockfile check and three file copies. That is genuinely all, and it means the frontend build contributes no runtime code paths to the PHP application beyond what those copies stage.

version 5.0.0 in the manifest against a 5.16.0 release

The npm manifest declares version 5.0.0. The most recent release tag is v5.17.0, published on 2026-10-20, and the manifest's own devDependency on the styleguide is passbolt-styleguide ^5.17.2. The version field in package.json is therefore not the server version, and reading it tells you nothing about what you are running. Do not use it as a version check in a script.

What the manifest does pin is the build toolchain:

  "name": "passbolt_api",
  "version": "5.0.0",
  "engines": {
    "node": ">=16.14.0",
    "npm": ">=8.3.1"
  },

The only runtime npm dependency is react-router-dom ^5.3.4. Everything heavier sits in devDependencies:

  "devDependencies": {
    "@babel/runtime": "^7.27.0",
    "@babel/runtime-corejs3": "^7.26.10",
    "lockfile-lint": "^5.0.1",
    "openpgp": "^5.11.3",
    "passbolt-styleguide": "^5.17.2"
  },

openpgp ^5.11.3 being a development dependency rather than a runtime one is the detail to notice: the JavaScript in this tree is not the encryption path for the deployed server. Overrides pin uuid ^14.0.0 and js-yaml ^4.3.2, and the PHP side of the application is built by composer, with composer.json and composer.lock at the root and no npm equivalent for server code.

A psalm baseline named for the v5 upgrade

Static analysis has four configurations at the root: phpcs.xml, phpstan.neon paired with phpstan-baseline.neon, and psalm.xml paired with a baseline whose filename is the interesting part, psalm-baseline-v5-upgrade.xml. Tests run through phpunit.xml.dist. Around them sit .pre-commit-config.yaml, renovate.json for automated dependency updates, CODEOWNERS, SECURITY.md, CHANGELOG.md, RELEASE_NOTES.md and a CLAUDE.md.

A baseline named after a major version is a candid artefact. It records what had to be suppressed to get the analyser through the v5 migration, which tells you the debt is tracked rather than forgotten. It is also a place to be careful: adding a finding to psalm.xml or phpstan-baseline.neon makes it disappear from the report without fixing anything.

Local development has two visible paths, a .ddev/ directory for DDEV and a Tiltfile for a Kubernetes-based local stack, which is a strange pair to see side by side and suggests both are supported starting points. Translations run through crowdin.yml. The application layout is index.php at the root with config/, src/, templates/, plugins/, resources/, tests/, bin/ and webroot/ around it, and the top-level tmp/ is where a CakePHP-shaped project would put its runtime files.

The desktop app is a pre-alpha link, the CLI is another repo

Two of the four client families are usable today: browser extensions for Chrome (which the README extends to Brave, Opera, Vivaldi and other Chromium browsers), Firefox and Edge, and mobile builds on the App Store and Google Play. The other two are not.

The CLI is go-passbolt-cli, a separate Go project. Scripting against passbolt_api therefore means depending on something this repository does not contain, at a version whose compatibility with your server is not documented here. The desktop app is labelled coming soon, with a pre-alpha build pointed at passbolt/passbolt-windows, which means there is no released Windows desktop client and the repository is candid about it rather than implying one exists.

One more routing rule matters before you file anything. The README asks that security issues not be opened as GitHub issues, and points to the responsible disclosure process instead. So a vulnerability report does not go through the issue tracker or a pull request, which is correct for a password manager and worth knowing before you assume the usual contributor path applies.

Editorial conclusion

passbolt_api suits teams that want to self-host a password manager and accept three costs: an AGPL-3.0 codebase that also withholds the Passbolt trademark, a repository with no install command of its own, and clients that live in other projects, including a desktop app the README still calls coming soon. Before committing, read the license section for the Section 7(e) trademark refusal, then choose a platform page under passbolt.com/ce and confirm the extension or mobile build you need is actually published for your browser.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. passbolt/passbolt_api on GitHub
3. Project website
4. README
5. Releases