Which open-source secrets management option fits your situation
If you need a self-hosted secrets manager and want to settle the Vault license question first, the short answer is this: choose OpenBao if you want a Vault-compatible core under the MPL-2.0 license and Linux Foundation governance, choose Vault if your organization is already standardized on HashiCorp tooling and can accept the Business Source License 1.1 terms or buy Enterprise, and choose Infisical if you want secrets, a private PKI and privileged access management in one MIT-licensed platform, accepting that some enterprise modules sit under a separate license. The three are not drop-in substitutes for each other. Moving between them means migrating storage, auth methods, policies and every client integration, so the choice is expensive to reverse once applications depend on it.
Start by confirming your license position in writing. The Vault LICENSE file names IBM as licensor and covers Vault 1.15.0 or later, so legal review should happen against the exact version you plan to run. For OpenBao, check the OpenBao LICENSE file and note that its migration guide was tested only against Vault 1.14.1 community edition, not Vault Enterprise. If you rely on Enterprise features such as namespaces-based multi-tenancy, performance replication or Sentinel policy as code, confirm with HashiCorp whether your current Enterprise contract covers them, and do not assume OpenBao offers an equivalent for every one of them.
For Infisical, map each feature you need against the license split before committing. The core repository is MIT, but any code in an ee directory falls under the separate license in ee/LICENSE, and the self-hosting documentation states that features such as SSO or gateways require enterprise licensing. Ask the vendor which of your required controls, especially SSO for administrators and audit-related features, are in the free tier. Whichever option you pick, plan for the one-time migration effort from any existing secrets store and the recurring cost of running a highly available backend under your own change control.
Which option to pick for each scenario
This table maps common secrets management situations to the option that fits best, with the reasoning and the condition that would change the answer. Read each row against your own platform, licensing constraints and existing Vault footprint, since the right choice often turns on one fact such as whether you already run Vault Enterprise features.
| Scenario | Best fit | Why | Condition that would change the answer |
|---|---|---|---|
| Multi-team platform on Kubernetes needing dynamic database credentials | OpenBao or HashiCorp Vault | Both offer dynamic secrets for SQL databases and Kubernetes with leasing and automatic revocation, so short-lived database credentials are the core use case for each. | Choose Vault if you need Enterprise controls such as performance replication or Sentinel policy. Choose Infisical if the team prefers its Kubernetes operator and a dashboard per project, and confirm which dynamic secret engines your databases need. |
| Regulated team needing an MPL-2.0 Vault-compatible core | OpenBao | OpenBao is MPL-2.0 licensed and a community fork of Vault under Linux Foundation OpenSSF stewardship, so its license terms do not depend on HashiCorp's BSL change. | Confirm with your legal team and your auditor how your procurement treats a Linux Foundation project versus a vendor-backed product. Check compatibility with your existing Vault configurations, since the OpenBao migration guide was tested only against Vault 1.14.1 community edition. |
| Team wanting secrets plus private PKI and PAM in one tool | Infisical | Infisical covers secrets, a private PKI with ACME and EST enrollment, a key management service and privileged access management with session recording in one platform. | Verify that the PAM and SSO features you need are in the MIT-licensed core rather than the ee directory, because the self-hosting documentation says enterprise features such as SSO require enterprise licensing. |
| Team already running Vault Enterprise | HashiCorp Vault Enterprise | Your clusters, policies and operational runbooks already match Vault, and Enterprise features such as replication, HSM support, FIPS compliance and Sentinel are licensed to the cluster. | If renewal cost or the BSL restrictions become a concern, evaluate OpenBao for a future migration. Ask HashiCorp or IBM to confirm license terms for your deployment model, and plan the migration with a tested path. |
| Team with no secrets tool yet | Infisical or OpenBao, chosen by workload | Infisical gives a dashboard, secret syncs and an agent that injects secrets without code changes, which lowers the first-step effort. OpenBao suits teams that want an API-first, Vault-style model with auth methods such as AppRole and Kubernetes. | Pick OpenBao if your team is comfortable with policy files, auth methods and storage backends such as Raft or PostgreSQL. Pick Infisical if developers need quick access to secrets, and confirm which features require the enterprise license before you commit. |
How OpenBao, Vault and Infisical differ in architecture
OpenBao is an open source, community-driven secrets manager and fork of HashiCorp Vault, managed as a Sandbox project of the Open Source Security Foundation (OpenSSF) under Linux Foundation stewardship. Its repository is licensed under MPL-2.0 and is led by a community operating under open-governance principles, so the license and the governance model are both part of the evaluation. Its documented storage backends are integrated storage (Raft), PostgreSQL, PebbleDB and in-memory, and the documentation describes PostgreSQL as easier to operate safely than Raft. High availability uses an active node that holds a lock in the data store, with standby nodes that forward or redirect requests. Raft and PostgreSQL are the officially supported HA backends. The documented auth methods include AppRole, JWT/OIDC, Kerberos, Kubernetes, LDAP, RADIUS, TLS certificates, tokens and username and password, plus login MFA.
- License and governance: MPL-2.0 with community governance under OpenSSF, which suits teams that want to avoid a vendor-controlled license change.
- Storage choice: Raft keeps the cluster self-contained, while PostgreSQL fits teams that already run and back up a database platform.
- Read scaling: Raft standbys can serve read-only operations since 2.5.0, and 2.7.0 extended this to PostgreSQL.
- Auth methods: AppRole is the documented choice for servers and Userpass for developer machines.
- Migration caveat: the migration guide was tested only against Vault 1.14.1 community edition, not Vault Enterprise.
Confirm current storage, HA and auth details in the OpenBao docs and test your chosen backend in a staging cluster before production.
HashiCorp Vault is offered as Community Edition binaries or source, as licensed Vault Enterprise, and as HCP Vault Dedicated, a managed service that runs the same binary as self-managed Vault Enterprise. HashiCorp announced on August 10, 2023 that future releases would move from MPL-2.0 to the Business Source License 1.1. The Vault LICENSE names IBM as licensor, covers Vault 1.15.0 or later, bars competitive hosted or embedded offerings, and converts each version to MPL-2.0 four years after publication. IBM completed its acquisition of HashiCorp on February 27, 2025. HashiCorp recommends integrated storage (Raft) for most use cases. Integrated storage and Consul are the officially supported backends, while external backends such as PostgreSQL, MySQL, DynamoDB and S3 have limited support.
- License position: the BSL 1.1 terms apply to releases from 1.15.0 onward, so read the LICENSE text for the exact version you deploy.
- Supported storage: Raft or Consul are the supported choices, and PostgreSQL is listed with limited support.
- Enterprise-only features: performance and disaster recovery replication, HSM support, namespaces, performance standby nodes and FIPS compliance need a license applied to the cluster.
- Managed option: HCP Vault Dedicated runs the same binary as self-managed Enterprise, which changes who operates the cluster.
- Pricing: HashiCorp directs self-managed Enterprise buyers to sales rather than publishing Vault Enterprise prices.
Confirm current licensing terms, supported storage and Enterprise feature lists with HashiCorp and your legal team before you build on Vault.
Infisical is a secrets management platform whose repository is licensed under the MIT Expat license, except content in any ee directory, which sits under the separate license in ee/LICENSE. Its self-hosting options include a single Docker container, Docker Compose, an official Helm chart with bundled PostgreSQL and Redis, Linux packages, and AWS or GCP reference deployments. Because the Helm chart bundles its own database and cache, the Kubernetes footprint is larger than a single container, and you need to decide whether to run those bundled services or point the chart at managed equivalents. Its self-hosting documentation says that enterprise features such as SSO or gateways require enterprise licensing. Infisical also offers Infisical Cloud, a hosted service that teams can sign up for free.
- License boundary: MIT for the core, with enterprise-licensed code in the ee directory, so check which modules your use case touches.
- Deployment footprint: a single container suits a pilot, while the Helm chart with bundled PostgreSQL and Redis suits a cluster deployment.
- Data services: plan backup, restore and upgrade procedures for the bundled PostgreSQL and Redis, or for external replacements.
- Machine identities: Kubernetes, AWS, GCP, Azure, OIDC and Universal Auth are listed for authenticating workloads.
- Kubernetes delivery: a Kubernetes operator and an injection agent deliver secrets without code changes.
Confirm which features need enterprise licensing, the supported database versions and the Helm chart values for your environment in the Infisical self-hosting overview before you size the deployment.
Capability comparison across OpenBao, Vault and Infisical
This table compares OpenBao, HashiCorp Vault and Infisical on the capabilities that drive a self-hosted secrets decision, marking where the documentation places a feature in a paid Enterprise tier. Read each row with the license and edition column in mind, because a feature listed as community today may still need confirmation for your specific release and deployment. Where the supplied documentation does not settle a point, the cell tells you what to confirm with the vendor.
| Capability | OpenBao | HashiCorp Vault | Infisical |
|---|---|---|---|
| License | MPL-2.0, community fork managed under the Linux Foundation's OpenSSF | Business Source License 1.1 for Vault 1.15.0 or later, with IBM named as licensor; Community Edition binaries and source are also offered | MIT Expat, except content in any ee directory, which uses the separate ee/LICENSE |
| Governance | Community-led under open-governance principles; a Sandbox project of OpenSSF | Commercial vendor governance, now under IBM after its February 27, 2025 acquisition completed | Company-maintained open-source project with a hosted Infisical Cloud service |
| Dynamic secrets | Yes, for systems such as Kubernetes and SQL databases, with leasing and automatic revocation | Available in Vault; confirm the specific engines and editions you need in the current docs | Yes, for databases such as PostgreSQL and MySQL; confirm other targets with the vendor |
| Kubernetes integration | Kubernetes is a documented dynamic secrets target and a Kubernetes auth method; confirm operator options with the project | Kubernetes auth method and integrations are documented; confirm operator and injector options for your version | Kubernetes operator delivers secrets to workloads and reloads deployments; agent injects secrets without code changes |
| PKI | Not listed in the supplied OpenBao documentation; confirm with the project before relying on it | Available in Vault; confirm certificate engine scope and edition requirements | Private PKI for X.509 certificates with ACME and EST enrollment |
| Namespaces and multi-tenancy | Namespaces are supported within a single instance; HashiCorp documents this capability as part of Vault Enterprise | Namespaces are listed as an Enterprise feature that needs a license on the cluster | Organization and project structure; confirm how tenant isolation maps to your model |
| HA backends | Integrated storage (Raft) and PostgreSQL are officially supported HA backends; PostgreSQL standbys serve reads from v2.7.0 | Integrated storage (Raft) and Consul are officially supported; PostgreSQL, MySQL, DynamoDB and S3 have limited support | Self-hosting options include Docker Compose, Helm with bundled PostgreSQL and Redis, and Linux packages; confirm HA layout with the vendor |
| Auth methods | AppRole, JWT/OIDC, Kerberos, Kubernetes, LDAP, RADIUS, TLS certificates, tokens, username and password, and login MFA | Vault auth methods are documented; confirm the full list against your Vault version | Kubernetes, AWS, GCP, Azure, OIDC and Universal Auth for machine identities; SSO requires enterprise licensing |
| Paid-gated features | Not listed as Enterprise-only in the supplied documentation; confirm with the vendor for any support or add-on you plan to use | Performance and disaster recovery replication, HSM and PKCS#11, namespaces, FIPS, control groups, Sentinel, MFA and automated upgrades need a license | SSO, gateways and other enterprise features require enterprise licensing |
| Managed option | Not stated in the supplied documentation; confirm any hosted or support offering with the project or a provider | HCP Vault Dedicated runs the same binary as self-managed Vault Enterprise; pricing requires sales contact | Infisical Cloud, which teams can sign up for free; paid plans are priced separately |
What is gated behind paid editions
Open-source OpenBao, Vault Community Edition and Infisical cover a large part of secrets management without a license. The cards below mark where the paid boundary sits, so you can check which controls your team needs before you choose a path. Vault Enterprise pricing is not published, so any cost figure must come from a written quote.
Vault Enterprise feature set
HashiCorp's Vault Enterprise documentation lists performance and disaster recovery replication, HSM support with a PKCS#11 provider, FIPS compliance, seal wrapping, control groups, Sentinel policy as code, redundancy zones, automated upgrades, lease count quotas and MFA as features that need a license applied to the cluster. If your requirement is replication or FIPS, the paid tier is the path to confirm. Ask HashiCorp which of these apply to your Vault version and deployment model before you assume parity with OpenBao.
Namespaces for multi-tenancy
OpenBao documents namespaces for secure multi-tenancy within a single instance, and HashiCorp documents the same capability as part of Vault Enterprise. Namespaces let separate business units or customers hold their own policies, auth methods and secrets engines inside one cluster. Confirm the exact behavior, limits and upgrade path in the OpenBao documentation for the release line you plan to run, since the feature is not an automatic reason to pick one product over the other.
Infisical enterprise licensing
Infisical's repository is MIT licensed except content in any ee directory, which sits under a separate license in ee/LICENSE. Its self-hosting documentation states that enterprise features such as SSO or gateways require enterprise licensing. Check which identity and network features your team needs before you deploy the community build. Confirm with Infisical which of these are in the open code and which require a license key for your self-hosted instance.
HCP Vault Dedicated as managed Enterprise
HCP Vault Dedicated is HashiCorp's managed service and runs the same binary as self-managed Vault Enterprise. Choosing it moves operation of the cluster to HashiCorp but keeps the commercial terms of the Enterprise model. HashiCorp directs self-managed Enterprise buyers to sales rather than publishing prices, so ask for a written quote that separates subscription, support and any hosting charges, and confirm where data resides and who holds the keys.
How hard is moving from Vault to OpenBao
The migration guide was tested only against Vault 1.14.1 community edition, not Vault Enterprise. OpenBao's migration guide is the starting point, but it does not certify your path. If you run Vault Enterprise features, or a Vault version newer than 1.14.1, treat the guide as a checklist rather than a proven route and test your own upgrade or migration path end to end. Read the OpenBao migration guide with your exact Vault version and license tier in front of you.
Start with an inventory that covers more than the data. List every auth method in use, including AppRole, JWT/OIDC, Kubernetes, LDAP and TLS certificate roles, and confirm each one is documented as available in OpenBao. Export your policies and check each path and capability they reference. Catalog your dynamic secret engines for databases and Kubernetes, and your PKI roles, including issuers, TTLs and allowed domains. Record your storage backend, whether integrated storage (Raft) or another backend, because the supported HA backends differ. Finally, search your codebase and CI pipelines for Vault API calls, Vault client library versions, and any Enterprise-only features such as namespaces, Sentinel policies or control groups that your applications depend on.
Before committing, confirm with OpenBao maintainers and your own vendor support contacts which of your Vault features are supported on OpenBao, and get any Enterprise-specific behavior confirmed in writing. Then run a pilot in a non-production cluster: restore a recent snapshot, replay a representative set of logins, lease renewals and certificate issuance, and check that client code works without changes. Record what breaks, how long the cutover takes and how you would roll back. Scope the pilot results into a written plan before any production change.
How to choose and pilot a secrets manager
This sequence moves a team from an inventory of what needs secrets to a measured pilot of OpenBao, HashiCorp Vault or Infisical. Each step ends with evidence the team can use to pick one platform or rule it out.
List secret consumers and workloads
Platform engineering and application owners list every consumer of secrets: CI pipelines, Kubernetes workloads, virtual machines, database clients, third-party SaaS integrations and human operators. For each consumer, record how it authenticates today, how often its credentials change and who is accountable for them. Done means you have a written inventory with an owner and an authentication method per row, which becomes the test matrix for every candidate in later steps.
Decide where dynamic secrets fit
With the inventory in hand, the security architect sorts each consumer into one of two groups: workloads that can request short-lived credentials from the manager at runtime, and legacy systems that must keep static secrets that are rotated on a schedule. OpenBao and HashiCorp Vault document dynamic secrets for systems such as Kubernetes and SQL databases, and Infisical documents dynamic secrets for PostgreSQL and MySQL. Confirm each target system is on the supported list for the platform you are evaluating. Done means a short list of dynamic-secret targets and a separate list of static secrets, each with a named rotation owner.
Check the license against your use
Legal counsel and the compliance lead review the license for each candidate against how you intend to use it. For Vault, the Business Source License 1.1 applies to versions from 1.15.0 onward and bars competitive hosted or embedded offerings, so counsel should judge whether an internal platform or a product you ship falls under that restriction. For Infisical, the MIT Expat license covers the core repository but code in any ee directory uses a separate license. Ask each vendor which features in your intended edition need a paid license. Done means a written license memo that names the feature set you will run and the edition it requires.
Test the Kubernetes integration path
The platform team deploys a candidate into a non-production cluster and tests the path a real workload would use. Confirm how the workload authenticates, whether through a Kubernetes auth method or an operator, how secrets reach the pod, and what happens when a secret changes. Infisical documents a Kubernetes operator that reloads deployments and an agent that injects secrets without code changes, so test whether those behaviors match your deployment model. Done means a recorded run showing one workload receiving a secret, a rotation, and a revocation, with the exact versions and manifests used.
Run an HA and backup drill on storage
The infrastructure team deploys the candidate on the storage backend you intend to run in production and then tests failure. For OpenBao and Vault, check which backends the vendor officially supports for high availability, since integrated storage (Raft) and PostgreSQL are the documented HA options for OpenBao, while HashiCorp recommends integrated storage and treats external backends as having limited support. Stop the active node, confirm failover, restore from a backup into a clean environment, and time the recovery in your own environment. Done means a signed-off drill record with the restore result and the named person who can repeat it.
Measure operator effort during the pilot
The platform team logs the hours spent on installation, upgrades, policy changes, incident response and access requests across the pilot period, separated by role. Ask each vendor what a quote covers for support and what your own staff must run, including unseal or key handling for self-managed clusters. Compare the logged effort against the inventory from the first step to see which candidate fits your team's capacity. Done means a comparison sheet of logged effort per platform and a written recommendation that names the edition, license position and support model you would buy.
Questions buyers ask before choosing a secrets manager
Is OpenBao a drop-in replacement for HashiCorp Vault?
Not automatically. OpenBao is a community fork of Vault under MPL-2.0, and its migration guide was tested against Vault 1.14.1 community edition, not Vault Enterprise. Teams running Vault Enterprise features, or any Vault version outside the tested range, should plan a compatibility review of policies, auth methods, plugins and storage before moving. Confirm the exact migration path and supported versions in the OpenBao migration guide and test it in a staging cluster with a copy of production data and configuration.
Does the Business Source License mean Vault is not open source?
Under the Open Source Initiative definition, the Business Source License 1.1 is not an open-source license, and that is the practical point for legal review. HashiCorp announced on August 10, 2023 that future releases would move from MPL-2.0 to BSL 1.1. The Vault LICENSE names IBM as licensor, covers Vault 1.15.0 or later, bars competitive hosted or embedded offerings, and converts each version to MPL-2.0 four years after publication. Older versions remain under their original terms, so your counsel should review which versions you run and how you plan to use them.
What does self-hosting a secrets manager cost in people and time?
The main cost is staff time, not software fees, because OpenBao and the Vault Community Edition are free to download. The effort is driven by the number of clusters, the storage backend you choose, how many auth methods and dynamic secret engines you enable, your backup and disaster recovery design, and how often you upgrade. Recurring work includes unseal and key handling, certificate rotation, monitoring, and patching. Ask any provider to break effort into design, build, handover and run, and to state which of these recur each year.
What should a vendor quote for secrets management include?
A useful quote lists the written scope first: which platforms, how many clusters or environments, which auth methods and secret engines, and which integrations such as Kubernetes, CI/CD and cloud accounts. It should separate one-time work (architecture, deployment, migration, hardening, documentation) from recurring work (upgrades, backups testing, monitoring, support). Ask which licenses the quote assumes, whether commercial Vault Enterprise or other paid editions are included or excluded, and who pays for them. DeployOpen does not publish a price list; fees follow from the written scope.
Can our team run a self-hosted secrets manager without outside help?
Yes, if your team already runs production infrastructure, can operate a highly available database or Raft cluster, and has people who understand key management and unseal procedures. Outside help is most useful when the team is new to secrets engineering, has a tight migration deadline, or needs independent testing of the design. Before deciding, check whether you have owners for backups, recovery drills, access reviews and on-call response. DeployOpen plans, implements, hardens, documents and supports self-hosted platforms in your own infrastructure, and most engagements are fixed-scope.
What must our team provide for storage, high availability, backups and auth integration?
Your team provides the infrastructure and the operating model. For storage, OpenBao supports integrated storage (Raft), PostgreSQL, PebbleDB and in-memory backends, and the docs describe PostgreSQL as easier to operate safely than Raft. High availability depends on the supported backends, so confirm which ones you will use. You also need backup and restore procedures tested against real recovery scenarios, integration with your identity provider or auth methods such as Kubernetes, JWT/OIDC, LDAP or AppRole, and a plan for who holds unseal material. Review the OpenBao storage documentation before choosing a backend.
How do Infisical licensing terms affect enterprise features?
Infisical's repository is MIT Expat licensed, except content in any ee directory, which falls under the separate license in ee/LICENSE. Its self-hosting documentation says enterprise features such as SSO or gateways require enterprise licensing. Core secrets management, dynamic secrets, PKI and Kubernetes integration are in the open-source code, but you should map each feature you need to the license that covers it before committing. Ask the vendor to list which features require an enterprise license and what that license costs and covers, and check the Infisical LICENSE file yourself.
What a secrets manager costs to run and change later
The license line is rarely the largest cost of running a secrets manager. The biggest recurring costs are the people and infrastructure around the cluster: the storage backend, the HA nodes, the auth integrations, backups and the operator time to upgrade all of it. For OpenBao and Vault Community Edition, the software itself carries no license fee, so the budget question is who runs it. For HashiCorp Vault Enterprise, the license is a commercial line item, and HashiCorp's pricing pages direct self-managed Enterprise buyers to sales rather than publishing figures, so you will need a written quote. For Infisical, self-hosting the MIT-licensed core is free to license, but features such as SSO or gateways need enterprise licensing according to its self-hosting documentation, so confirm which of your required controls sit behind that line before you budget.
Infrastructure cost follows the storage choice. Vault and OpenBao both document integrated storage (Raft) as a primary option, and PostgreSQL is an officially supported HA backend for OpenBao, which may suit a team that already runs and backs up PostgreSQL. Ask the vendor or your own platform team which backends they will support for your topology, and price the nodes, backup storage and disaster recovery site for each. Upgrades are recurring operator time: budget for test clusters, change windows and the work to verify auth methods, policies and dynamic secret roles after every minor release. Also confirm whether a planned upgrade path exists between the products, because OpenBao's migration guide was tested only against Vault 1.14.1 community edition, not Vault Enterprise.
Switching costs are the most expensive part to change later. Every application, pipeline and Kubernetes workload that reads secrets through an API, agent or operator carries a dependency on that product's paths, auth methods and lease behavior, so moving platforms means rewriting clients as well as migrating data. In a quote, ask for: one-time design and implementation effort separated from recurring support, upgrade and testing hours per year, the named auth integrations and their setup, backup and restore testing, and an itemized list of any enterprise features your requirements depend on. A written scope lets you compare options on the same basis.
How DeployOpen scopes a secrets management selection and rollout
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For secrets management, that means working through the choice between OpenBao, Vault and Infisical against your own environment before any platform is installed.
How we scope
- Start by listing which workloads, pipelines and people need secrets, and where those secrets live today.
- Record which auth methods, Kubernetes clusters and database engines the written scope must cover.
- Confirm licensing, edition and enterprise feature needs with each vendor before the scope is signed.
How we build
- Deploy the chosen platform in your infrastructure, with storage, high availability and seal configuration agreed in advance.
- Configure dynamic secrets, Kubernetes integration and PKI issuance only where the written scope names them.
- Test secret retrieval, lease revocation and access policies against the agreed scenarios before handover.
How we hand over
- Deliver documentation for architecture, access policies, backup and restore, and upgrade steps.
- Provide the control evidence you need for compliance readiness, which auditors and certification bodies then assess.
- Walk your platform, security and operations staff through day-to-day administration and incident procedures.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan version upgrades around the release lines and support windows your chosen vendor publishes.
- Re-test access controls and secret rotation whenever the scope, licensing or workloads change.
