Open Source Secrets Manager
A secrets manager is a single point that, if it falls, can expose every credential your infrastructure runs on, so its blast radius is the whole environment rather than one app. That puts the weight on how it encrypts at rest, scopes access, rotates keys, and behaves during an outage, not on any convenience feature. The open source systems here keep that machinery in the open: you can read the encryption and access logic, run it inside your own trust boundary, and rotate or revoke credentials without waiting on a vendor. When the thing guarding every other secret is auditable, its promises become checkable rather than assumed.
Vaultwarden
Self-hosted Bitwarden-compatible server in Rust, light enough to run where the official service is too heavy
HashiCorp Vault
Secrets management, encryption as a service, and privileged access management
Infisical
Open-source secrets, certificate, and privileged access management for teams and infrastructure
SOPS
Editor for encrypted YAML, JSON, ENV, INI, and binary files with KMS, age, and PGP
Bitwarden
Open-source password manager for passwords and passkeys, with clients for web, browser, desktop, and CLI
Sealed Secrets
Kubernetes controller and kubeseal tool for one-way encrypted Secrets
gopass
GPG-encrypted, git-versioned password manager for teams - a drop-in replacement for the standard UNIX pass
External Secrets Operator
Kubernetes operator that syncs values from external secret stores into Kubernetes Secrets
OpenBao
Open source secrets manager for storing, encrypting, leasing, and revoking sensitive data
Our picks
This category spans central services, Kubernetes controllers, and file-based tools; these four cover the common shapes.
Best for dynamic secrets at scale: HashiCorp Vault Vault stores key-value secrets encrypted before they hit storage, and generates dynamic, short-lived credentials on demand for systems like databases, with leasing, renewal, and revocation built in. It also offers encryption as a service and detailed audit logging. It fits infrastructure that wants credentials to expire automatically.
Best for team secret syncing and CI/CD: Infisical Infisical centralizes application secrets and syncs them across projects, environments, and CI/CD, with connectors for platforms like GitHub, Vercel, AWS, and Terraform. It adds secret versioning, point-in-time recovery, scheduled rotation, and dynamic secrets, plus RBAC, approval workflows, and audit logs. Reach for it when the goal is keeping secrets out of git across many teams.
Best for encrypting secrets in git: SOPS SOPS encrypts the values inside YAML, JSON, ENV, and INI files while leaving the structure readable, using AWS KMS, GCP KMS, Azure Key Vault, age, or PGP. Secrets stay in your own repository and storage, with no service to run. It suits GitOps workflows that want configuration and secrets versioned side by side.
Best for GitOps on Kubernetes: Sealed Secrets Sealed Secrets lets you encrypt a Kubernetes Secret into a SealedSecret that is safe to commit to a public repository, since only the in-cluster controller can decrypt it. It supports key rotation, re-encryption, and backup of sealing keys for offline recovery. Choose it when Kubernetes manifests, including secrets, should live in git.
Choosing a secrets manager for your trust boundary
The trust boundary is the first decision, and it shapes everything after. A secrets manager can be a central online service, a Kubernetes-native controller, or a file-based encrypted store, and each choice moves your blast radius somewhere different. Central services like HashiCorp Vault and OpenBao make policy and audit easier but put every workload on their availability. SOPS keeps secrets as encrypted files in git with no service to run, while Sealed Secrets and the External Secrets Operator fit teams whose secrets live and die with Kubernetes. Decide, too, whether you need static storage or dynamic credentials with leases.
Look hard at the access model before the interface. The system should map to how machines and people prove identity: workload identity, short-lived tokens, mTLS, OIDC, or a cloud IAM bridge, so no application has to store a permanent token just to fetch another secret. Dynamic secrets, which Vault and OpenBao generate on demand with automatic revocation, shrink the exposure window because credentials expire on their own, but they only work when the target system can create and revoke accounts safely. Audit logs should record access decisions and policy changes without leaking the secret values themselves.
Then plan the operating model and the exit together. Seal and unseal procedures, backup encryption, restore testing, certificate renewal, and client retry behavior all matter more than the feature list, because a secrets outage can stall every deployment. Confirm how applications consume secrets, whether through an API, a sidecar, templated files, or environment injection, since that determines migration cost. For the exit, prefer clear export of paths, policies, metadata, and version history, and avoid being trapped by undocumented storage formats.
Related categories
Frequently asked questions
What should a secrets manager solve first?+
Its first job is getting secrets out of source code, shared files, chat, build logs, and long-lived environment variables. A useful one gives applications a controlled way to fetch credentials, gives operators a way to rotate them, and gives auditors a record of who accessed what. If it only stores encrypted key-value pairs with no identity, policy, or rotation, it is closer to a vault file than an operational secrets system.
When are dynamic secrets worth the added complexity over static ones?+
Dynamic secrets pay off when the target system can safely create and revoke credentials on demand, such as database accounts, certificates, or temporary service tokens; Vault and OpenBao generate these with automatic expiry. They shrink the damage window because credentials do not linger. Static values are still fine for legacy systems and third-party services, so the real question is whether your apps can handle leases and renewal failures without outages.
Which authentication model works best for applications?+
Prefer one that uses the workload's existing identity rather than a shared bootstrap secret. Good patterns include machine identity, mTLS certificates, OIDC tokens, cloud workload identity, or orchestrator-provided identity. Avoid designs where every application stores a permanent token just to fetch another secret, because that first credential becomes the weak point. Make it short-lived, tightly scoped, and easy to revoke.
How does secret rotation actually work?+
Rotation can mean updating a stored value, generating a fresh credential in the target system, or issuing short-lived credentials on demand. The safest systems coordinate creation, distribution, validation, and revocation so old credentials do not vanish before applications reload. Check whether clients refresh automatically, whether failed rotations roll back cleanly, and whether the manager can rotate the specific databases, certificates, and external services you actually use.
What belongs in a secrets manager's audit log?+
An audit log should show who or what requested access, which path or credential was involved, whether the request was allowed, and which policy decided it. It should also capture policy changes, logins, token creation, rotation, and administrative actions. It must not leak secret values, full tokens, or sensitive payloads. Confirm the logs can ship to the security monitoring stack you already run.
Should a secrets manager replace environment variables?+
Not always. Environment variables are simple but leak easily through process listings, crash reports, and build systems. A secrets manager can inject values at start time, mount them as files, or let applications fetch them at runtime; runtime fetching supports rotation best but adds a dependency. For older applications, file or environment injection is often the realistic first step before moving to live fetches.
What happens to my applications if the secrets manager goes down?+
Decide in advance which applications can fail closed and which need cached credentials to keep running. A secrets outage should not automatically take down every service, but stale credentials carry their own risk. Look for client-side caching controls, lease renewal behavior, and clear error handling, and test failure explicitly, especially startup paths where an application cannot boot until it receives a secret.