OpenBao vs HashiCorp Vault vs Infisical: which fits your secrets program
If your team already runs Vault, the first question is whether its license terms still fit your plans, not whether the software still works. HashiCorp announced in August 2023 that future releases would move from MPL-2.0 to the Business Source License 1.1, and the Vault LICENSE now names IBM as licensor and bars competitive hosted or embedded offerings. In short, OpenBao fits teams that want an MPL-2.0 Vault-style engine with namespaces and standby read scaling, HashiCorp Vault fits buyers who accept the BSL 1.1 terms and want Enterprise features under a commercial license, and Infisical fits developer-centric teams that need secrets delivery, PKI and privileged access with paid ee modules where required.
Start with the feature list, because the license alone does not decide the choice. Make an inventory of what your cluster depends on today: performance or disaster recovery replication, HSM or PKCS#11 seals, Sentinel policies, control groups, FIPS builds, or namespaces. Vault Enterprise lists several of these as features that need a license applied to the cluster, so confirm with HashiCorp which ones you hold and which OpenBao covers. Check the OpenBao namespaces documentation against your tenancy model before assuming parity. If you need Kubernetes-native delivery, a PKI front end or session recording, compare Infisical's feature set against your existing tooling rather than against Vault's engines alone.
Whichever platform you choose, plan for a sized, owned deployment. Each option runs in your own infrastructure or your chosen hosting arrangement, so your team owns the storage backend, high availability, unseal approach, backups and upgrades. Ask any vendor or partner for a written scope that names the storage, seal method, node count, replication design and the Vault versions a migration would be tested against. OpenBao's migration guide was tested only against Vault 1.14.1 community edition, so confirm how your current Vault version and any Enterprise features behave before you commit to a migration date.
Which platform fits which scenario
This table matches five common situations to the platform that usually fits best, along with the condition that makes that choice hold. Read each row against your own estate, then use the confirmation column to close the gaps the public facts leave open. The main takeaway is that the licence and the gated features matter more than the feature list for most of these decisions.
| Scenario | Best fit | Why, and under what condition | What to confirm |
|---|---|---|---|
| Existing Vault estate under review | OpenBao, if the team wants to stay on a Vault-compatible API under MPL-2.0 | OpenBao is an MPL-2.0 fork managed under the Linux Foundation's OpenSSF. This holds only if the estate runs community Vault features. OpenBao's migration guide was tested against Vault 1.14.1 community edition, not Enterprise. | Which Vault edition and version is running, whether any Enterprise-only features are in use, and whether the migration guide's tested versions match your upgrade path. |
| Kubernetes-heavy developer teams | Infisical, if developer self-service and Kubernetes delivery matter more than Vault-style engines | Infisical offers a Kubernetes operator that delivers secrets and reloads deployments, plus an injecting agent. The MIT core covers the core secrets platform, but SSO and gateways in self-hosting need enterprise licensing. | Which self-hosting features your teams need and whether they fall under the MIT core or the enterprise-licensed ee directory. Confirm the Kubernetes auth method you will use. |
| Regulated enterprise needing replication or HSM | HashiCorp Vault Enterprise, unless OpenBao's roadmap covers the specific control you need | Performance and disaster recovery replication, HSM support and FIPS compliance are listed as Vault Enterprise features requiring a license. OpenBao covers namespaces and read scaling on standbys, but the supplied facts do not show equivalent replication or HSM support. | Whether your assessor requires FIPS validated builds or HSM-backed seals, which replication topology you need, and the current Vault Enterprise terms from sales, since HashiCorp does not publish those prices. |
| Air-gapped sites | OpenBao or Vault Community, self-hosted with Raft or PostgreSQL storage | Both run self-hosted binaries inside the client's network. Infisical's self-hosting options cover Docker, Compose, Helm and Linux packages, but its enterprise features require licensing that you must confirm works offline. | Whether the chosen binary, container images and licence checks work without outbound access, and how unseal keys or auto-unseal will be handled without a cloud KMS. |
| Teams needing PKI and PAM alongside secrets | Infisical, which bundles a private PKI with ACME and EST enrollment and privileged access with session recording | Infisical includes these in one platform, so one product can cover secrets, certificates and session recording. OpenBao focuses on secrets, dynamic credentials and encryption as a service. A team that needs a full PAM platform may still need a separate tool. | Which PKI and PAM features are in the MIT core and which need enterprise licensing, the session recording depth you require, and whether your compliance evidence needs a separate PAM product. |
What each license allows and what is paid
OpenBao is licensed under MPL-2.0, a file-level copyleft license. If you modify MPL-licensed files and distribute the result, you share those file changes under the same license, but you can combine the code with proprietary code and you can run it internally without any license fee. The project is managed by the Linux Foundation's OpenSSF as a Sandbox project and is led by a community under open-governance principles. The facts supplied do not describe a paid tier, a commercial edition or a feature gate in OpenBao, so the license terms are the main thing to read.
- No license fee: Running OpenBao inside your own infrastructure carries no vendor license charge described in the project materials.
- File-level copyleft: Changes to MPL-2.0 files must be shared if you distribute them, which is a narrower obligation than a network copyleft license.
- Hosting for others: The license does not restrict offering OpenBao as a service, so a managed offering for customers is permitted under the license terms.
- Governance: The Linux Foundation's OpenSSF stewardship is the governance frame to review against your own vendor-risk process.
- Support is a separate question: No paid support tier is described in the facts, so ask any provider you engage what support, upgrades and security response they cover.
Check the LICENSE file and the release notes for the version you plan to deploy, and confirm with your legal team how the MPL-2.0 file-level terms apply to any patches you intend to keep private.
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 now names IBM as licensor, covers Vault 1.15.0 or later, and bars competitive hosted or embedded offerings. Each version converts to MPL-2.0 four years after publication. 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.
- BSL restriction on competitors: Using Vault internally is allowed, but offering a competing hosted or embedded product built on it is barred by the license text.
- Enterprise features need a license: Performance and disaster recovery replication, HSM support, namespaces, performance standbys, seal wrapping, FIPS compliance, control groups, Sentinel and automated upgrades need a license applied to the cluster.
- Sales-led pricing: HashiCorp's pricing pages describe pay-as-you-go, flex and Enterprise self-managed models and direct self-managed Enterprise buyers to sales, with no Vault Enterprise prices published.
- Managed option: HCP Vault Dedicated runs the same binary as self-managed Enterprise, so the managed route changes who operates the cluster, not the feature set.
- Version conversion: Each release converts to MPL-2.0 four years after publication, so older versions move to the open license on a published schedule.
Before you commit, ask HashiCorp or your reseller which Enterprise features your design depends on, and get the subscription terms, support scope and any restriction on your intended use in writing.
Infisical's repository is licensed under the MIT Expat license, except content in any ee directory, which is governed by the separate license in ee/LICENSE. The core secrets management, PKI, key management and access features sit in the MIT-licensed code, while enterprise features such as SSO and gateways require enterprise licensing according to the self-hosting documentation. Before you deploy, the question is which features fall in the ee directories and which of them your design requires.
- Permissive core: Code outside the ee directories is MIT, which allows internal use, modification and redistribution with a notice requirement.
- Separate ee terms: Anything under the ee directory follows ee/LICENSE, so read that file rather than assuming the MIT terms apply to paid modules.
- Enterprise gates named in the docs: SSO and gateways are stated to require enterprise licensing in the self-hosting documentation.
- Cloud is separate: Infisical Cloud is the vendor's hosted service, and teams can sign up for it free, which is a different commercial relationship from self-hosting.
- Hosting for others: Read the ee license before offering Infisical as a service to customers, because the MIT grant does not automatically cover the ee directories.
Confirm with Infisical, in writing, which features your deployment needs are covered by MIT and which require an enterprise license, and check the license terms against the exact release tag you plan to run.
What the Vault license change means for an existing Vault estate
HashiCorp announced on August 10, 2023 that future Vault releases would move from MPL-2.0 to the Business Source License 1.1. The current Vault LICENSE file names IBM as licensor, covers Vault 1.15.0 and later, and bars competitive hosted or embedded offerings. Each version converts to MPL-2.0 four years after publication, so the terms that apply to an existing deployment depend on which version it runs. IBM completed its acquisition of HashiCorp on February 27, 2025. If your estate includes Vault builds from 1.15.0 onward, have counsel read the LICENSE file against your actual use, especially if you embed Vault in a product you sell or offer it to customers as a service.
The license question is separate from the operational one. Ask your procurement and legal teams to confirm three things: which Vault versions each cluster runs, whether any internal or external party consumes Vault as a hosted or embedded service, and whether your current agreement with the vendor includes Enterprise features. Vault Enterprise needs a license applied to the cluster, and HashiCorp directs self-managed Enterprise buyers to sales for pricing, so the cost of staying is a quote question rather than a published figure.
If you consider OpenBao as the exit path, test before you commit. The OpenBao migration guide was tested only against Vault 1.14.1 Community Edition, not Vault Enterprise, so an estate that depends on Enterprise features or on versions newer than 1.14.1 needs its own validation run in a non-production environment. Read the OpenBao migration guide with your platform team, record the exact Vault version in each cluster, and plan a rollback path before any cutover.
How moving from Vault to OpenBao or Infisical works
The sequence turns a Vault estate into either an OpenBao cluster or an Infisical deployment with a documented inventory, a tested path, a validated configuration and a rollback option at every stage. The two destinations involve different kinds of work, so the steps below separate them where they diverge.
Inventory Vault features and Enterprise dependencies
Your team lists every Vault feature in use: secrets engines, auth methods, policies, namespaces, replication, seal type, HSM use, Sentinel policies, control groups, and any Enterprise-only capability. Compare that list against the Vault Enterprise feature set in the HashiCorp documentation, and mark each item as covered by OpenBao, not covered, or needing a different design. The output is a written inventory with an owner for each gap, and the gaps decide whether OpenBao is a fit at all.
Confirm the Vault version against the tested guide
Check which Vault edition and version runs in production and compare it with the version the OpenBao migration guide was tested against. The guide was tested only against Vault 1.14.1 community edition, not Vault Enterprise, so any newer or Enterprise cluster needs a documented gap analysis and a test in your own environment before a production change. The output is a signed-off version note that states which path you are taking and why.
Choose in-place swap or parallel build
Decide between replacing the Vault binary in place and standing up a parallel OpenBao cluster that you cut over to. The in-place route keeps storage and configuration largely intact but leaves less room to back out; a parallel build costs more infrastructure but lets you run both and move clients gradually. Infisical is a different decision: it is a new platform rather than a binary change, so you plan a separate deployment on the self-hosting options you have chosen. The output is a documented decision with the reasons recorded.
Rebuild secrets, identities and policies for Infisical
If the destination is Infisical, treat the move as a re-modelling exercise rather than a migration. Map Vault paths and secrets engines to Infisical projects, environments and folders, redesign machine identities so that Kubernetes, AWS, GCP, Azure, OIDC or Universal Auth replace the Vault auth methods your workloads use, and rewrite RBAC, temporary access and approval rules as Infisical policies. Confirm with the vendor which features your plan and self-hosted license cover, since SSO and gateways need enterprise licensing. The output is a mapping document that a reviewer can check line by line.
Validate auth methods and storage backend
In a test cluster, run each auth method your workloads use, including AppRole, JWT/OIDC, Kubernetes, LDAP and TLS certificates, and confirm that identities, tokens and leases behave as before. Confirm the storage backend (integrated storage, PostgreSQL or another supported option) reads and writes correctly after the swap, and test failover between active and standby nodes. The output is a test record that lists each auth method and backend with a pass or fail result and the evidence behind it.
Test dynamic secrets, leases and revocation
Exercise the dynamic secrets your applications depend on, such as database credentials, and verify that leases issue, renew and revoke as expected. Confirm bulk revocation works for an emergency scenario, and check that encryption as a service calls succeed for any application that uses them. For Infisical, run the equivalent checks on rotation and dynamic secrets for the databases you use. The output is a list of tested secret paths with the results recorded and any application changes logged for the cutover.
Cut over with a documented rollback plan
Move production clients in stages, keep the Vault cluster and its snapshots available, and agree in advance the conditions that trigger a rollback, such as failed authentication or unexpected lease behavior. Record who can approve a rollback and how the team confirms that the rollback worked. Infisical cutovers often run in parallel with existing secret stores until each consuming workload is verified. The output is a signed cutover record with a rollback runbook that the operations team has rehearsed.
Retire Vault after a stable observation period
Once clients have run on the new platform for an agreed observation period, decommission the Vault cluster in a controlled way. Confirm that audit logs are retained under your policy, that no workload still points at old endpoints, and that backups from the final Vault state are stored where your retention rules require. The output is a decommission record that shows the old cluster is no longer in use and where its data sits. Ask your implementation partner or vendor to confirm the retention and support terms in writing before this step.
What drives the running cost of each platform
Running cost for these three platforms is set less by the software price than by who operates the cluster, which storage and unseal design you choose, and which features sit behind a license. The cards below separate one-time setup from recurring spend so you can build a like-for-like quote request.
OpenBao license and operating staff
OpenBao is licensed under MPL-2.0 with no license fee, so its recurring cost is staff time and infrastructure. You pay for the nodes, the HA storage (integrated Raft or PostgreSQL) and the people who run upgrades, backups and unseal procedures. Ask any vendor or partner quoting support to separate license charges from operating labor and infrastructure.
Unseal and recovery operations
Whichever platform you run, an unseal design creates recurring work. Shamir key shares tie cost to the people who hold keys and to ceremonies after every restart, while auto-unseal shifts cost to a cloud KMS or HSM service. Confirm who holds recovery material and how often the cluster is expected to restart before pricing the operating model.
HashiCorp Vault Enterprise licensing
Vault Enterprise is licensed, and HashiCorp's pricing pages direct self-managed Enterprise buyers to sales instead of publishing a price. Features such as performance and disaster recovery replication, HSM support, namespaces and FIPS compliance need a license applied to the cluster. Request a written quote that lists each Enterprise feature you need, the term, and whether support is included.
Vault Community Edition self-operation
Vault Community Edition is available as binaries or source, so the license line is zero, but the operating burden moves to your team. You own the HA design, storage backend choices, upgrades and any feature you would otherwise buy as Enterprise. Note that HashiCorp's storage documentation limits support for external backends such as PostgreSQL, so confirm supportability before choosing storage.
Infisical self-hosting footprint
Self-hosting Infisical means running its application with PostgreSQL and Redis, whether through Docker Compose or the official Helm chart, which bundles both. Recurring costs include the hosting for those components, backups and upgrades. SSO or gateways require enterprise licensing under the ee terms, so ask whether the quote includes that license and whether it is priced per year or per seat.
Infisical Cloud as a cost alternative
Infisical Cloud is the vendor's hosted service and teams can sign up for it free, which moves infrastructure and upgrade work to the vendor. The trade-off is that data and key custody sit outside your own environment, which may not meet a regulated data residency or air-gap requirement. Compare the cloud subscription against the full self-hosted cost, including the staff time you would otherwise spend.
What implementing each platform involves
Scope drives implementation effort more than the choice of product, so the first decision is how much of the platform your team will own. For OpenBao, the main architectural choice is storage and high availability: integrated storage (Raft) or an external PostgreSQL backend. The OpenBao storage and HA documentation treats both as officially supported HA options and describes PostgreSQL as easier to operate safely than Raft, so confirm which your operators already run. Unsealing is a separate design item, since Shamir key shares and auto-unseal through a cloud KMS or HSM carry different recovery duties. For Vault, the storage documentation recommends integrated storage for most use cases, while Consul and integrated storage are the officially supported backends and PostgreSQL, MySQL, DynamoDB and S3 have limited support. Ask HashiCorp or your reseller to confirm which backends apply to your edition before you design around them. Infisical self-hosting is simpler to start: a single Docker container, Docker Compose, or the official Helm chart, which bundles PostgreSQL and Redis. Confirm whether you will run those bundled services or point the chart at managed databases, because that choice moves backup and upgrade work to your team.
Identity integration and Kubernetes delivery shape most of the rest of the work. OpenBao documents AppRole for servers and Userpass for developer machines, and also lists JWT/OIDC, Kerberos, Kubernetes, LDAP and TLS certificate methods, so map each workload class to one method and test its renewal path. Infisical authenticates machine identities through Kubernetes, AWS, GCP, Azure, OIDC or Universal Auth, and its Kubernetes operator reloads deployments when secrets change, which needs a tested rollout plan. Vault Enterprise features such as control groups or MFA need a license applied to the cluster before they can be designed in. Testing should cover secret rotation, lease revocation, backup restore and a full recovery drill, because a secrets platform that fails to restore is an outage for every dependent system. Documentation should record the unseal process, the backup and restore runbook, and the access policy for each application. DeployOpen plans, implements, hardens, documents and supports these platforms inside your infrastructure, and the work is agreed in a written, fixed scope before it starts. Ask any implementer for a quote that lists storage, identity integration, Kubernetes delivery, testing and documentation as separate line items.
Questions buyers ask before choosing a secrets manager
Is OpenBao a drop-in replacement for HashiCorp Vault?
Not automatically, and the answer depends on which Vault you run today. OpenBao is a community fork of Vault under MPL-2.0, managed by the Linux Foundation's OpenSSF, and its migration guide was tested only against Vault 1.14.1 community edition, not Vault Enterprise. If you run community Vault at a version the guide covers, an in-place binary swap is the documented path. If you run Vault Enterprise, treat OpenBao as a re-validation project: confirm every feature your configuration depends on, test restores, and plan a rollback before touching production. Read the OpenBao migration guide against your exact versions before deciding.
Which Vault Enterprise features does OpenBao not cover?
OpenBao covers some Enterprise capabilities but not all of them. Namespaces for multi-tenancy are documented in OpenBao, and since 2.5.0 Raft standbys can serve read-only operations, with v2.7.0 extending that to PostgreSQL. HashiCorp's Enterprise list also includes performance and disaster recovery replication, HSM support and a PKCS#11 provider, seal wrapping, FIPS compliance, control groups, Sentinel policy as code, redundancy zones, automated upgrades, lease count quotas and MFA. Each needs a check against the current OpenBao documentation before you assume parity. Ask your team which of these your policies depend on, because those gaps drive the migration effort more than anything else.
Does Infisical replace HashiCorp Vault?
Infisical overlaps with Vault on secrets, dynamic secrets for databases, and machine identity access, but it is not a Vault-compatible engine. Its repository is MIT Expat except for content in ee directories, and it adds a private PKI with ACME and EST, a key management service, and privileged access management with session recording. Choose it when developer workflows such as dashboards, secret syncs to platforms like GitHub and Vercel, and Kubernetes delivery matter most. Choose OpenBao when you need Vault-style secret engines, existing Vault policies and integrations, or the Vault API. Enterprise features such as SSO or gateways require enterprise licensing in Infisical's self-hosting documentation, so confirm them early.
What drives the cost of running a self-hosted secrets manager?
Software licensing is only one component. The main recurring costs are the people who operate the cluster, the storage and high availability design, the infrastructure for backups and disaster recovery, and any paid subscription. For OpenBao, the software is MPL-2.0, but the unseal process, backup verification and storage choice (integrated Raft or PostgreSQL) all need operator time. For Vault, licensed Enterprise features need a license applied to the cluster, and HashiCorp directs self-managed Enterprise buyers to sales rather than publishing prices. For Infisical, enterprise features need a paid license. Ask any vendor or partner for a written quote that separates one-time setup, recurring licensing, support, and operations, and that names which features it assumes.
How long does a secrets manager implementation take, and what does it need from our team?
No supplied source gives a duration for these implementations, so treat any timeline as a question for your environment. The effort scales with the number of applications that read secrets, the auth methods you need (OpenBao documents AppRole, JWT/OIDC, Kerberos, Kubernetes, LDAP and others), the storage design, and whether you are migrating existing Vault policies. Your team will need to supply identity and network contacts, a decision on unseal method, backup and restore ownership, and people who can review policies. DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms in your own infrastructure, usually under a fixed scope agreed in writing before work starts, so ask for that written scope and its deliverables.
Can our engineers self-host OpenBao or Infisical without outside help?
Many teams can, provided they have people who already run stateful infrastructure and who will own it after go-live. OpenBao's high availability model uses an active node holding a lock in the data store, with standbys, and Raft or PostgreSQL are the officially supported HA backends. Infisical offers a single Docker container, Docker Compose, an official Helm chart with bundled PostgreSQL and Redis, and AWS or GCP reference deployments. The harder parts are usually unseal procedures, key custody, upgrades, restore testing and audit evidence, not the first install. Check whether you can run a restore drill without the vendor, and whether you have a named owner for upgrades. DeployOpen can take on implementation, hardening, backup and documentation, or ongoing support through a retainer.
Which secrets manager gives us the lowest risk of a future licensing change?
License terms are a strategic risk, not only a legal one. HashiCorp announced on August 10, 2023 that future Vault releases would move from MPL-2.0 to the Business Source License 1.1, and the Vault LICENSE now names IBM as licensor, bars competitive hosted or embedded offerings, and converts each version to MPL-2.0 four years after publication. OpenBao remains MPL-2.0 under OpenSSF governance, and Infisical's core is MIT Expat with enterprise-licensed ee directories. Weigh whether your organization can accept a source-available license for a critical control, and whether a fork's governance and release cadence meet your support needs. Confirm the current license text in each repository before you decide.
How DeployOpen works on this
DeployOpen helps teams decide between OpenBao, HashiCorp Vault and Infisical against their own licensing, audit and workload requirements, then plans and implements the chosen platform inside the client's own infrastructure. Engagements are agreed in writing before work starts, and we do not publish prices.
How we scope
- Scope starts with which secrets, machine identities and certificates the platform must cover, and which Vault features your teams rely on today.
- The written scope names the target edition, license terms reviewed, storage backend, unseal method and the Kubernetes or CI systems to integrate.
- We agree deliverables and timelines in writing before work starts, and list which Enterprise-gated features are in or out of scope.
How we build
- We deploy the chosen platform in your cloud account, data center or air-gapped network, with storage, high availability and unseal design documented.
- Auth methods, secret engines and policies are configured for your workloads, with migration steps tested against a copy of your existing Vault data.
- Integrations for Kubernetes delivery, CI pipelines and dynamic database credentials are built and tested before cutover to production.
How we hand over
- Handover includes architecture, configuration, runbooks for unseal and recovery, and a rollback plan for the migration window.
- Operators receive documented policies, access model decisions and the license and feature inventory that supports your procurement review.
- Compliance evidence is prepared for your independent auditors, since DeployOpen prepares controls and records but does not issue attestations.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Upgrade plans track the release lines of the chosen platform, with changes tested before they reach production clusters.
- Security testing of the secrets platform and its integrations can be scoped separately, covering applications, APIs and infrastructure.
