Twenty years in this industry have taught me that the tools you treat as infrastructure religion are the ones that will betray you when a licensing spreadsheet ends up on a procurement table. I have watched teams get burned by Oracle, by VMware, by Elastic. Now I am watching the same pattern play out with HashiCorp Vault, and the architects who are still sleeping on this decision are going to feel it in their next budget cycle.
Here is the situation as of September 2026: IBM closed the HashiCorp acquisition in February 2025. HCP Vault Secrets, the SaaS-only lightweight secrets product, hit end of life on July 1, 2026, just weeks ago. OpenBao, the Linux Foundation fork of Vault, shipped v2.6 in August 2026 with per-namespace sealing and a new workflow engine. And Infisical, Doppler, and AWS Secrets Manager have all matured into genuine production-grade alternatives. If you are running Vault in production and you have not revisited your strategy since 2023, this is the briefing you owe yourself.
What IBM Actually Changed (And What It Has Not, Yet)
The acquisition closed quietly, and HashiCorp continues to operate as a unit under IBM’s hybrid cloud division. The product still exists. The Vault CLI still works. The Terraform provider still runs. If you are running Vault Community Edition on your own infrastructure and managing it yourself, your day-to-day operations have not changed at all.
What has changed is the commercial trajectory. A few concrete things have shifted since the deal closed:
IBM integrated Terraform with its Red Hat Ansible Automation Platform. This is good for shops that already run both, but it signals that HashiCorp’s products are becoming components in IBM’s larger hybrid cloud narrative rather than standalone tools with their own roadmaps.
The free tier on HCP Terraform kept shrinking. The legacy user-based free plan reached end of life, and terraform import was restricted to paid tiers in January 2026. The pattern is clear: the hosted, managed products are moving up-market.
HCP Vault Secrets, the lightweight SaaS secrets product that competed with Doppler, ended its life. HashiCorp directed those customers to either HCP Vault Dedicated or Vault Community Edition. This is a meaningful data point: IBM is consolidating the portfolio around enterprise-grade and managed-dedicated offerings rather than maintaining a broad surface area of products at different price points.
Community engagement has visibly slowed. HashiCorp’s forums and GitHub issue response times have stretched. This is normal for any acquired company mid-integration, but it is worth noting if your team has historically relied on the community for support.
None of this is catastrophic. But it represents a consistent trend: the total cost of operating Vault on IBM’s terms is going up, and the non-paying path is increasingly self-managed Community Edition with limited official support.
HCP Vault Dedicated: What You Are Actually Buying
HCP Vault Dedicated is the managed Vault offering that survived the portfolio consolidation. It runs Vault on HashiCorp-managed infrastructure, with automatic upgrades, built-in disaster recovery, and a multi-region replication option.
The pricing model uses a per-hour base charge for the cluster (varying by tier and cluster size, from small to large) plus a per-client charge on top for Essentials and Standard tiers. A “client” is any unique service, application, or user that authenticates to Vault in a billing period. Development tier clusters pay only the base rate, which makes them useful for non-production environments. The moment you need enterprise features like performance replication, HSM integration, or namespaces, you move to tiers where per-client billing kicks in.
I have seen HCP Vault Dedicated quotes in the low six figures annually for organizations running Vault at meaningful scale. HashiCorp publishes list pricing in their HCP Portal when you create a cluster, and I would recommend getting a current quote from your account team rather than anchoring to any third-party analysis. Prices have moved post-acquisition, and published list prices do not reflect negotiated enterprise agreements.
If your organization needs managed Vault with an SLA, multi-region replication, and does not want to run the operational stack yourself, HCP Vault Dedicated is a reasonable choice. The capability set is genuinely strong, dynamic secrets, PKI, transit encryption, LDAP and Kubernetes auth methods, all work exactly as they do in self-hosted Vault. You are paying for the operational overhead to disappear.
The concern I hear from architects is not about capability, it is about price trajectory under IBM and the fact that you are now buying a managed service from a company that has historically been a software licensor transitioning into a cloud provider. IBM has a mixed track record on that journey.
OpenBao: The Fork That Got Serious
OpenBao emerged when HashiCorp changed Vault’s license from MPL 2.0 to Business Source License 1.1 in August 2023. The community forked the last MPL-licensed version of Vault, 1.14.0, and put it under Linux Foundation governance through the OpenSSF. If you have seen the OpenTofu story, this is the same pattern.
The critical question is always: is the fork just maintaining parity, or is it moving forward with its own roadmap?
By August 2026, the answer is clearly the latter. OpenBao v2.6, released earlier this month, added per-namespace sealing, which lets you create an additional Shamir seal and a scoped barrier keyring per namespace. For multi-tenant environments, this is a significant capability: different tenants can now have distinct cryptographic key material, giving you stronger isolation guarantees than a shared cluster. That is not a capability backport from Vault. That is net-new development.
The v2.6 release also shipped a new workflow engine for cross-plugin communication, letting operators create multi-request workflows across secrets engines. And the contributor base is real: 42 first-time contributors in that single release, with 27 individuals contributing multiple changes. This is not a fork being maintained by two people on weekends.
OpenBao speaks the same API as Vault. If you have existing Terraform code using the Vault provider, existing Kubernetes auth configurations, existing PKI workflows, they will work against OpenBao without changes. The migration path from Vault Community Edition to OpenBao is well-documented and involves exporting your Vault data and importing into OpenBao, with the same storage backends supported.
What OpenBao does not have: HashiCorp Vault Enterprise’s HSM integration, the commercial Performance Replication feature, and managed hosting. If you need those, you need Vault. If you need a production-grade open-source secrets engine under neutral governance with an active development community, OpenBao is the answer.
I think the honest framing is this: OpenBao today is roughly where Vault was in 2019 or 2020, before the Enterprise feature set diverged significantly. For most teams, that is more than enough.
Infisical and Doppler: The Modern SaaS Alternatives
The third path, and the one I see more teams taking than I expected, is abandoning the Vault paradigm entirely in favor of purpose-built secrets managers that are not trying to be a general-purpose secrets engine.
Infisical is the one that has surprised me most. It started as an open-source alternative with a self-hosted option, and it has grown into something with genuine production depth. It offers secret versioning, environment-based access control, automatic rotation for a growing set of supported services, and native integrations with every CI/CD platform I can think of. The Kubernetes operator works cleanly. The self-hosted option is MIT-licensed.
For teams with developers who are not secrets management experts, Infisical’s developer experience is meaningfully better than Vault’s. Vault’s learning curve is steep. Dynamic secrets, policies, auth methods, seal/unseal procedures, these are concepts that take real effort to internalize. Infisical’s model is closer to how engineers already think about environment variables and secrets in code.
Doppler is the other strong contender. It is cloud-only, and it excels at the developer-facing side: syncing secrets to environments, integrations with Vercel, Railway, and GitHub Actions, and making it simple to onboard new services without secrets management expertise. It is not trying to be Vault. It is trying to make secrets management invisible to developers, and it largely succeeds.
The limitation with both Infisical and Doppler compared to Vault or OpenBao is depth. They do not have a transit encryption engine. They do not have full PKI certificate management. They do not have the breadth of auth methods. If you need dynamic database credentials that auto-rotate on a fifteen-minute TTL, Vault or OpenBao is still the only viable answer. If you need Vault as a PKI backend for your TLS certificate infrastructure (a pattern I have described in more depth in our TLS certificate management guide), then Vault or OpenBao is still the right tool.
AWS Secrets Manager deserves mention for teams already deep in AWS. It handles rotation natively for RDS, Redshift, and a growing list of other AWS services. For workloads that live entirely in AWS, the integration is tight and the operational overhead is low. The concern is lock-in. If you move to multi-cloud or need to serve secrets to non-AWS infrastructure, you will hit friction fast.
The Decision Framework
Twenty years in, I have learned to ask the same three questions before recommending any infrastructure tool:
What specific capabilities do you actually use?
If you are using Vault primarily as a key-value secrets store and rotating static credentials manually, you are using roughly ten percent of Vault’s surface area. That use case is covered by Infisical, Doppler, or AWS Secrets Manager with dramatically simpler operations. If you are using Vault for dynamic secrets (database credentials, AWS STS tokens, or similar), for PKI, or as a non-human identity platform, the functional depth of Vault or OpenBao is harder to replicate.
What is your team’s operational capacity?
Running OpenBao yourself means owning the HA clustering, the seal/unseal process, the Raft storage backend, the backup strategy, and the upgrade path. That is real operational work. If you have an SRE team that already has strong Vault knowledge, OpenBao is a natural landing spot. If you are a small team looking to shed operational burden, HCP Vault Dedicated or a SaaS alternative makes more sense even at higher sticker price.
What is your compliance exposure?
SOC 2 and ISO 27001 auditors care about secrets governance, audit logging, and access control, but they generally do not mandate specific tools. FIPS 140-2 compliance for cryptographic modules, however, does constrain your options. Vault Enterprise supports FIPS 140-2 validated cryptography. OpenBao’s FIPS posture is less mature. If your compliance requirements mandate FIPS-validated HSM integration, that is currently a differentiator that points toward Vault Enterprise.
The decision matrix I would draw:
Stay on HCP Vault Dedicated if: you need managed operations, your compliance requirements need Vault Enterprise features, and the cost fits your budget after getting an IBM/HashiCorp contract negotiation.
Move to OpenBao if: you run Vault Community Edition self-hosted today, you need Vault’s full capability set under neutral governance, and you have the operational capacity to run it yourself. The migration is low-risk given API compatibility.
Move to Infisical or Doppler if: you use Vault primarily as a static secrets store, your team struggles with Vault’s operational complexity, or you are starting a new service and do not want to inherit Vault’s learning curve.
Move to AWS Secrets Manager if: you are AWS-native, your rotation needs are covered by what AWS supports natively, and you accept the lock-in trade-off.
Migration Considerations
If you decide to move from Vault Community Edition to OpenBao, the mechanics are straightforward. You export your Vault data using the vault operator migrate command or the Raft snapshot approach, stand up an OpenBao cluster on the same storage backend, and import. Because the APIs are identical, your Kubernetes External Secrets Operator configuration, your Vault Agent Injector sidecars, and your Terraform infrastructure code require no changes. The Vault Terraform provider version pinning is the main thing to check: OpenBao maintains its own provider that mirrors the Vault provider’s interface.
I would be remiss not to mention workload identity federation here. One of the cleanest patterns in modern Vault deployments is eliminating long-lived credentials entirely by using Kubernetes service accounts or IRSA to authenticate to Vault without static tokens. OpenBao supports this exactly as Vault does. If you have not moved to keyless authentication for your services yet, a migration to OpenBao is a good moment to fix that while you are touching your secrets infrastructure anyway. The same applies to SPIFFE/SPIRE-based workload identity if you are running a multi-cluster or multi-cloud environment.
If you are migrating to Infisical or Doppler, the approach is service-by-service rather than a bulk migration. You stand up the new secrets manager, start rotating secrets into it as services are updated to consume from the new source, and retire the old Vault paths over time. I prefer this gradual approach because it keeps you from doing a big-bang cutover that breaks everything simultaneously.
What I Would Do in Production Today
I have three types of clients right now dealing with this decision. The first are large enterprises running Vault Enterprise with advanced replication and HSM integration. For them, I am recommending they negotiate aggressively with IBM/HashiCorp rather than migrate immediately. The capability gap between Vault Enterprise and OpenBao on the high end is real, and the migration cost is high. But they need to start evaluating OpenBao seriously, because if IBM’s pricing trajectory continues and OpenBao closes the capability gap (which v2.6 suggests it is doing), the calculation will flip.
The second group are teams running Vault Community Edition self-hosted. For them, I am recommending a migration to OpenBao within the next six to twelve months. The operational experience is identical, the API is compatible, and they escape the BSL licensing ambiguity. There is no good reason to stay on Vault Community Edition when OpenBao offers the same thing under clean open-source terms.
The third group are teams that have been using HCP Vault Secrets and need to migrate now given the July 2026 EOL. For most of them, Infisical or Doppler is the right answer. The typical HCP Vault Secrets user was using about a quarter of what Vault is capable of, and a simpler product will serve them better.
The broader lesson here is familiar to anyone who has been doing this long enough. Open-source infrastructure tools that get acquired by large enterprise software companies tend to follow a predictable path: feature development slows or pivots toward enterprise needs, the free tier shrinks, pricing increases, and the community forks. We saw this with Sun/MySQL (MariaDB), we saw it with Red Hat/CentOS (Rocky Linux, AlmaLinux), we saw it with HashiCorp/Terraform (OpenTofu), and now we are seeing it with HashiCorp/Vault (OpenBao).
This is not a criticism of IBM. It is the natural economics of enterprise software. But it does mean that the appropriate response for a principal architect is to make deliberate, documented decisions about which vendor you are willing to depend on and under what terms, rather than inheriting those dependencies by inertia.
If you have not reviewed your secrets management strategy in the last twelve months, the HCP Vault Secrets EOL is a reasonable forcing function. Use it. For your Kubernetes-specific secrets patterns, our External Secrets Operator and Sealed Secrets guide is still the most practical reference for getting secrets from wherever you store them into running pods. And for the broader question of what zero trust security means for credential governance at the layer below your secrets manager, that is a conversation worth having with your security architecture team before you pick your next tool.
The right answer here is not the same for every team. But the wrong answer is to not have a position at all.
Updated September 1, 2026: This article reflects the state of HashiCorp Vault, HCP Vault Dedicated, and OpenBao as of August-September 2026, including OpenBao v2.6 (August 2026) and HCP Vault Secrets end of life (July 1, 2026). Pricing information is directional; verify current rates with HashiCorp/IBM directly.
Get Cloud Architecture Insights
Practical deep dives on infrastructure, security, and scaling. No spam, no fluff.
By subscribing, you agree to receive emails. Unsubscribe anytime.