Infisical
| License | FOSS problems | Maintenance | SSO | Users | Tested |
|---|---|---|---|---|---|
| MITPermissive license. Preserve the copyright notice. Applies only to the covered code — your surrounding project can stay under any license. | Open-Core | Active | ✅ | Unlimited | ❌ |
Description
Infisical is an open-source secrets management platform — closer to a lighter, developer-focused HashiCorp Vault than a consumer password manager. Secrets are organized per project and environment.
Features
- Web UI, CLI, and SDKs — secrets injected into a process at runtime, the same shape as
pass-cli's environment injection. - Dynamic secrets — generated on demand rather than static, long-lived credentials.
- Kubernetes operator — for injecting secrets straight into a cluster; not relevant to this project's single-server setup, but a real capability.
- Self-hostable — deployable on your own infrastructure via Docker or Helm, not tied to a vendor's cloud. That's also where the real risk sits: self-hosting the thing that holds the keys to everything else means its backup and recovery has to be solved separately, not inherited for free from a vendor's own infrastructure the way a hosted vault's would be (see Conclusion).
Usage patterns
- Self-hosted deployment — running on this stack's own infrastructure would close the "one deliberately non-self-hosted piece" gap Proton Pass leaves open in this catalog, instead of accepting it.
- CLI injection —
infisical run -- <command>resolves secrets into a subprocess's environment, the same shape the OpenTofu credential workflow already uses viapass-cli— adopting this wouldn't change that shape, just which tool backs it. - Team/org secret management — built for a team's infrastructure secrets across projects and environments, not personal password/login management.
License and governance
MIT for the core platform — genuinely open, self-hostable, does the actual secrets-management job in full. Flagged Open-Core in this catalog because some team/org-scale features sit behind a separate enterprise license within the same codebase, rather than the milder "optional hosted cloud" shape Coolify or Pulumi have — self-hosting here doesn't necessarily get you everything the hosted version offers.
Conclusion
Why you would — self-hostable, the one gap Proton Pass leaves open in this catalog. Its CLI resolves secrets into a subprocess's environment the same way pass-cli does, so the credential workflow already documented wouldn't need to change shape — just which tool backs it.
Why you wouldn't — it solves infrastructure secrets well but isn't a general password manager — no browser extension, no autofill, nothing built for personal logins — so it would sit alongside Proton Pass for a narrower job rather than replace it. And self-hosting the thing that holds the keys to everything else reopens exactly the problem Proton Pass's conclusion accepted a SaaS dependency to avoid: if this stack's own server goes down, so does the vault meant to help recover it. Worth revisiting once there's a second box to host it on, independent of what it protects.