PearPass Desktop: a peer-to-peer password manager that its own authors have paused

What it is, and the warning that comes first

PearPass is an open-source, privacy-first password and identity manager that gives you full control over your sensitive information, and the desktop app is the Electron and TypeScript client for it, built on Pear Runtime.

The design bet is that a password manager does not need a company in the middle. Instead of a centralised server, PearPass encrypts and stores all data locally on your device, and syncs your credentials directly between your devices using peer-to-peer technology. The documentation is explicit about the difference: unlike traditional password managers that rely on centralized servers, this one keeps the data private, secure and under your control.

The first thing in the readme, above the logo and the title, is a warning, and it is the first thing anyone should read. PearPass is currently paused from active development, so please use it at your own caution until further notice.

That single line changes how the rest of this article should be read. Everything below describes a well-built and interesting piece of software, and none of it changes the fact that the people who wrote it have stepped back from it. For a password manager, which is a piece of software whose failure mode is that your credentials are exposed, a paused project is a category of risk that has to be weighed explicitly rather than noted in passing.

The releases tell a consistent story. The recent versions are PearPass Desktop v2.1.0 from 2026-05-20, v2.0.0 from 2026-05-12 and v1.6.0 from 2026-04-08, and the last push to the repository was on 2026-08-14. So the work was concentrated in the spring of 2026 and has slowed since, which is consistent with a project being wound down rather than one that has simply gone quiet.

The licence is one that GitHub cannot classify, so the terms are in the LICENSE file, and the repository also carries a NOTICE.md and a SECURITY.md, which is a sensible pair of files for a project that stores credentials.

The feature set, and what peer-to-peer actually buys you

The feature list is short and each item is specific.

Encrypted-at-rest storage means PearPass encrypts passwords, credit cards, secure notes and custom fields before writing them to disk. Cross-device sync means credentials are synchronised directly between your devices using Pear Runtime, with no central server. Offline access means the vault is available at any time, even without a network connection.

Then the two conventional features: password health, which analyses password strength and identifies weak passwords, and a random password generator for strong, unique passwords. The multi-platform line says it runs on macOS, Linux and Windows, and that PearPass is also available on mobile and as a browser extension, with those two being separate repositories.

The offline access point is the one that interacts with the peer-to-peer design in a way worth thinking about. A design where the server is the only copy of your vault forces the network to be available for the product to work, which is why most password managers keep a local cache anyway. Here the local encrypted copy is the primary artefact and the sync is a convenience, so a network outage degrades the experience rather than locking you out of your own passwords. For somebody whose threat model includes a provider disappearing or a company being bought, that ordering is the point.

The repository structure shows how the application is put together. There is an electron/ directory for the main process, an app.electron.tsx entry point, a src/ directory for the development source, an e2e/ directory, a jest.config.js for the unit tests, a lingui.config.js for the translations, and packaging configuration for every platform, with electron-builder.mac.json, electron-builder.linux.json, a forge.config.cjs, a flatpak/ directory and a snap/ directory. There is also a knip.json, which is the configuration for a tool that finds unused files and dependencies, and a .husky/ directory for the git hooks.

Building it, and the eighteen siblings you need first

The prerequisites are Node.js, with the required version in the .nvmrc and checked with node --version, and Pear Runtime, which has its own installation guide.

The setup is five steps:

# 1. Clone the repository
git clone [email protected]:tetherto/pearpass-app-desktop.git

# 2. Go to the cloned directory
cd pearpass-app-desktop

# 3. Install dependencies
npm install

# 4. Generate translation keys
npm run build

# 5. Start the development app
npm run dev

Step 4 is worth noting. The build script generates translation keys, because the app uses Lingui for localisation, and a key file that is a build product rather than a committed artefact means the translations and the code cannot drift apart silently.

The real obstacle is the next section. The workspace dependencies are listed as sibling modules that must be present in the workspace and are not declared as npm dependencies. There are eighteen of them, and the list covers everything from the vault core to a QR utility, an avatar initials helper, a date helper, a pattern search helper, a validator and a unique id generator. Alongside them sit library packages for constants, data export, data import, a theme provider, the vault and the vault core, plus the password check and password generator utilities.

That is a substantial structural fact about the project. The app depends on eighteen sibling repositories that have to exist next to it on disk, none of them pulled from a registry, which means a clone of this repository alone does not build, and a contributor needs the whole family checked out. It is a normal arrangement for a monorepo split across repositories, and it is an unusual one for a desktop application, and it has a direct effect on how easy it is to audit the security of what you are running.

The staging section adds one more tool to the picture. You verify the app with npm run dev, stage it with pear stage dev, and run it with pear run pear://GENERATED_URL. Pear serves the files from the dist/ folder, and the src/ folder is for development and is ignored in the package.json, alongside the .github directory, the appling directory, the git directories, the packages directory and the src directory itself.

Logging, and the asymmetry in what gets redacted

The logging documentation is the most carefully written part of this readme, and it describes a security detail that is easy to get wrong.

Logging is off by default. When it is enabled, logs are written under the userData logs directory, with main.log coming from the host process and core.log from the vault worker. And then the sentence that matters: the worker's sink redacts known sensitive fields, passwords, keys, tokens and so on, before writing to core.log. The host process logger does not redact, so treat anything passed to logger.* in main.cjs as on-disk-visible in main.log.

That is an unusual thing to document this explicitly, and it is the correct thing to document. A password manager whose worker redacts secrets but whose host process does not has an obvious failure mode, and a user who turns on logging for a support request has to know that the file on disk may contain whatever the application logged.

There are three ways to enable logging. The in-app toggle lives under Settings, then Diagnostics, then Enable logs, and it persists across launches. Toggling it on clears any previous log files so a session starts clean, and toggling it off stops the writing but preserves the existing files so they can be shared. The second way is a launch flag, --enable-logging, which forces logging on regardless of the toggle. The third is the nightly builds, PearPass-nightly, where logging is on automatically and the in-app toggle is locked, which is a sensible default for a build that exists to gather diagnostics.

When logging is on, an Open logs folder button in the same screen reveals the directory.

The design of the toggle, clearing on enable and preserving on disable, is a small piece of thought about what a user is doing. The person turning logging on is usually about to reproduce a problem, and the person turning it off is usually about to share a log. Both behaviours match that intent, and the locked toggle on nightlies means a diagnostic build cannot accidentally be shipped into a configuration where nobody is collecting the output.

The packaging, and the platform caveats

The build configuration in the package manifest shows the target platforms and the signing decisions in one place.

The application id is com.pears.pass, the product name is PearPass, and the mac target is a dmg with the hardened runtime enabled and gatekeeper assessment off, with an afterSign script that notarises. The Linux target is an AppImage with a pinned appimage toolset version, and the publish configuration pushes the release to GitHub under the tetherto organisation and the pearpass-app-desktop repository.

The Pear-specific configuration is the part that is not conventional. The package name is pearpass-app-desktop, the routes are the current directory, and one path is listed as unrouted, the worklet app inside the vault core package, which is the one part of the app that has to be reachable outside the normal routing. The window configuration sets a background colour of #1F2430, a default size of 1440 by 1024 and a minimum width of 816.

The upgrade and legacy channel fields are pear:// links, which is how the application knows where to find a new version, and a legacy channel for older installations.

There is one platform caveat stated in the documentation and it is not a small one. Intel-based Mac builds are deprecated and provided without official support or active testing. The project says they are keeping them available for now and to use them at your own risk, and that if you run into issues you are welcome to open a ticket, and that while they cannot guarantee a fix they would like to know if the builds are still being used.

That is a well-handled deprecation. It states the position, it says what the alternative is, and it asks for the information that would let the project decide whether to keep shipping them.

The unit tests run with Jest through npm test, and the project uses React, Styled Components, Lingui and Redux alongside Pear Runtime, with the mobile app and the browser extension living in their own repositories.

Editorial conclusion

PearPass Desktop is worth looking at if you want a password manager with no central server, because the sync is directly between your devices and the vault is encrypted on disk before it is written, and because the whole client is readable TypeScript and Electron you can read rather than a closed binary. It is the wrong tool for a user who wants a service with a support team, and it is the wrong tool right now for a user who needs an actively maintained password manager. Before you install it, check three things: that you are comfortable with a project whose own documentation says it is currently paused from active development and to use it at your own caution until further notice; that you understand the logging model, because logs are off by default but the vault worker redacts passwords, keys and tokens before writing core.log while the host process logger does not redact anything, so anything passed to logger.* in main.cjs ends up readable on disk; and that you can build it, because it needs Node.js at the version in .nvmrc, Pear Runtime installed separately, and eighteen sibling workspace modules that are not published as npm dependencies and have to be present in the workspace.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. tetherto/pearpass-app-desktop on GitHub