Proton Pass

License	FOSS problems	Maintenance	SSO	Users	Tested
EULAProprietary license. No obligation to share source code. Terms of use set entirely by the vendor; redistribution and production use typically require a paid subscription.	Clients are open source, but it's a hosted vault — not self-hostable	Active	❌	Paid tiers	✅

Description

Proton Pass is a password manager and secrets vault from Proton. Alongside the usual login/password storage, it ships Custom Items (arbitrary named fields, useful for API keys and other credentials that don't fit a login form) and a CLI (pass-cli) that resolves pass://vault/item/field references and injects the real values into a wrapped command's environment at run time.

Features

• Custom Items — arbitrary named fields, not forced into a login-form shape, for API keys and other credentials that don't fit one.
• pass-cli — resolves pass://vault/item/field references and injects the real values only into a wrapped subprocess's environment, masking any resolved value it sees echoed back in that command's own output.
• SSH agent — loads a key straight from the vault into an agent socket; SSH talks to the socket, not a file, so no private key is ever written to disk.

Usage patterns

• Provisioning tooling — Terraform/OpenTofu and the OpenStack/Infomaniak CLIs authenticate via pass-cli run --env-file .env -- <command>, no clouds.yaml, no openrc, no ~/.s3cfg on disk. See Walkthrough → Infrastructure → Infrastructure as Code for how this is actually wired up.
• Server SSH access — via the same CLI's SSH agent, not a local key file.
• Ordinary password manager use — the human, day-to-day role too: logins, personal secrets, the vault a person unlocks directly.

License and governance

EULA for the hosted vault itself — the clients are open source separately, but the service is closed and not self-hostable, the one deliberate exception in a catalog otherwise built entirely from self-hosted choices.

Worth being precise about what kind of company sits behind it, though. Since 2024, majority ownership of Proton AG sits with the Proton Foundation, a Swiss non-profit legally bound to defend Proton's privacy/freedom/democracy mission — it holds enough voting power to block a hostile takeover or a change of control the mission wouldn't survive, with employees, a Swiss innovation charity (FONGIT), and early users holding the remaining minority stakes. That's a genuine mission-lock, not a marketing claim — closer in spirit to a steward-owned company than a typical VC-backed one, even though Proton AG itself still operates at real commercial scale, hundreds of employees and real infrastructure, not a scrappy volunteer project.

Conclusion

Why you would — the CLI is the reason it's here over any other password manager: it's what lets infrastructure tooling authenticate without a credential ever sitting in a flat file on disk, and it covers the ordinary human password-manager role too.

Why you wouldn't — it's not self-hosted, real tension for a project whose whole premise is not depending on third-party SaaS. Accepted here on the reasoning that a password manager is exactly the kind of thing you don't want to be your own single point of failure for — losing access to a self-hosted vault (server down, backup corrupted) would be worse than depending on a provider for the one system that unlocks everything else, and this particular provider's ownership structure is a closer match to this project's own values than most alternatives would be.