Padloc: self-hostable password management with a PWA and native clients

What Padloc is meant to manage

Padloc addresses password and general data storage for individuals and teams that prefer to operate the service themselves. The repository describes it as a "modern, open source password manager" and presents the project as simple, secure password and data management. The README does not provide a feature checklist covering browser autofill, sharing policies, emergency access, import formats, or password auditing, so those capabilities should not be assumed from the project description alone.

The repository is split into packages with separate responsibilities. `@padloc/core` contains core logic, `@padloc/server` provides the backend, and `@padloc/pwa` supplies the web client as a Progressive Web App. Additional packages cover localization, Electron desktop builds, Cordova mobile builds, Tauri native builds, and a browser extension. This packaging model is useful for teams that want to inspect or extend a particular client, but it also means that adopting the project is more than installing one standalone application.

The intended minimum deployment is a configured server and web client. That boundary is important. A team should first decide whether it wants a hosted Padloc service, a self-hosted server, or a locally built client, because the README gives a direct setup path for local use but says detailed production hosting and application distribution guides are coming soon.

The server, PWA, and package boundaries

Padloc's visible architecture is a monorepo coordinated with Lerna. The root package defines private development tooling and scripts, while the `packages` directory contains the product surfaces. The web client is a PWA, and the README describes the development mode as starting both the backend server and the PWA. The server listens on port `3000` by default, while the PWA is available at `http://localhost:8080`.

The root scripts show the intended relationship between packages. Commands use `lerna run` with scopes such as `@padloc/pwa`, `@padloc/server`, `@padloc/electron`, and `@padloc/extension`. The `postinstall` script runs `lerna bootstrap`, which indicates that installing root dependencies also prepares the package relationships in this workspace.

The repository also contains `Dockerfile-server`, `Dockerfile-pwa`, and `docker-compose.yml`. The compose file defines separate `server`, `pwa`, and `nginx` services. It exposes server ports `3000` and `4000`, mounts attachment, log, and asset paths, and reads configuration from `.env`. Its MongoDB service is commented out, so the compose file does not document a complete active MongoDB deployment. That omission limits how far the file can be treated as a turnkey production configuration.

Running a local Padloc instance for the first time

The README's local installation path uses SSH for cloning, so the reader needs access to GitHub through SSH. The documented commands are:

git clone [email protected]:padloc/padloc.git
cd padloc
npm ci
npm start

The first command retrieves the repository. `npm ci` installs the dependency versions represented by the lockfile, and `npm start` starts the documented local application. The README says the web client becomes available at `http://localhost:8080`.

For development mode, the README gives a separate command:

npm run dev

This starts the backend server, which defaults to port `3000`, and the PWA, which defaults to port `8080`. The repository's package metadata requires Node.js `16.x` and npm `8.x`, so those versions are the confirmed environment constraints for this checkout. The README also documents the configuration variables `PL_TRANSPORT_HTTP_PORT` and `PL_PWA_PORT`, but it does not show a complete production configuration.

A first real use after startup would be to open the PWA address and follow the interface. The README documentation does not specify the first screen, account-creation command, default administrator setup, or an API request for creating a vault. It also does not document rollback, backup verification, or recovery procedures, which are material gaps for a password manager.

Client choices come with package-level build costs

Padloc supports several client targets, but the README does not present all of them as equally documented deployment paths. The Electron package builds a desktop application, the Tauri package provides a cross-platform native app, and the Cordova package supports iOS and Android builds. The extension package is intended for browser use, while the PWA provides the browser-based client.

The root package scripts expose separate build commands for many of these targets, including `pwa:build`, `electron:build`, and `web-extension:build`. Cordova scripts include separate Android and iOS commands, plus a signed Android build command. The existence of these scripts confirms that the repository is designed for multiple client pipelines. It does not confirm that every target has current setup documentation, platform prerequisites, or a tested publishing procedure.

This distinction matters for adoption. A team interested only in a hosted web client may find the PWA and server packages sufficient. A team that needs a branded desktop or mobile application must inspect the relevant package and its native toolchain requirements. The README says detailed guides for building and distributing custom desktop and mobile applications are coming soon, so those workflows are not fully explained in the available project documentation.

Cryptography claims and verification boundaries

The repository topics include cryptography and end-to-end-encryption, and the README directs readers to `security.md` for a security design overview. That is a clear pointer for technical review, but the README excerpt does not describe the encryption protocol, key derivation, recovery model, attachment handling, or browser extension trust boundary. It would therefore be inaccurate to claim specific cryptographic guarantees based only on the topic labels.

The package layout suggests that security-sensitive core behavior is separated into `@padloc/core`, while server and client packages provide their respective delivery layers. That separation can make code review easier, but it does not prove where trust decisions occur or whether all clients share identical security behavior. The available documentation also does not say whether a team administrator can inspect encrypted vault contents, how attachments are encrypted, or how a lost device is handled.

For a password manager, these are adoption questions rather than optional details. Review `security.md`, inspect the relevant client and server packages, and verify the exact behavior of key storage and recovery before placing important credentials in a new instance. The README does not provide a rollback procedure or a documented migration plan for changing an existing deployment's storage configuration.

Docker deployment and licensing decisions

The compose file shows a possible container layout rather than a complete documented installation. It builds the server from `Dockerfile-server`, builds the PWA from `Dockerfile-pwa`, and places an `nginx` service in front of the server. The `server` service loads `.env`, exposes `3000` and `4000`, and uses volumes for attachments, logs, and assets. The PWA service is configured to run its `build` command and restart on failure.

A team adapting that layout would need to supply suitable configuration and storage decisions itself. The compose file includes a commented MongoDB service and commented environment values for a MongoDB host, protocol, and port. The compose configuration therefore leaves open which data backend is intended for a given deployment. It is not enough to assume that starting `docker-compose.yml` will produce a complete production service.

Padloc is identified in the repository metadata as AGPL-3.0, and the README says the software is published under the GNU Affero General Public License. The root package metadata also displays `GPL-3.0`, which is a licensing inconsistency worth resolving before redistribution or network deployment. The README advertises a commercial license contact at `[email protected]`. This is not legal advice, but it is a concrete adoption constraint: confirm which license text governs the version and package being deployed before modifying or offering the service.

Who should choose Padloc, and what remains unverified

Padloc is a reasonable candidate for a self-hosted password and data manager when an individual or team is comfortable operating a JavaScript monorepo and reviewing its server, PWA, and security documentation. The package separation gives room for web, desktop, mobile, extension, and localization work. The documented local startup is short enough to support an initial evaluation.

It is a weaker fit for a team that expects a fully documented production installer, a complete database configuration, or turnkey desktop and mobile distribution. The README says production hosting and client-distribution guides are coming soon, the compose database section is commented out, and the first-use workflow is not documented at the level of commands or account setup. The license metadata also needs clarification.

Before adoption, verify `security.md`, inspect the exact AGPL and package licensing metadata, confirm the intended database and attachment storage, and test recovery and backup procedures in a non-production instance. The repository is not archived and its last push was on 2026-10-14, but the versioned `v4.3.0` release is from 2023-03-06, so repository activity and release cadence should be evaluated separately.

Editorial conclusion

Individuals or teams that want to self-host a password and data manager can evaluate Padloc, especially if they also need a web client or native client packages. Organizations should not adopt it without first checking the AGPL-3.0 licensing implications, confirming a maintained deployment path, and reviewing the security design for their own threat model. The repository is not archived, and its last push was on 2026-10-14, but the documented installation guide remains focused on local development rather than production hosting.

Frequently asked questions

Official sources

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