After HashiCorp's license change: own Vault in 2026

On 10 August 2023, HashiCorp moved Vault and its other core tools from an open-source license to the Business Source License. On 27 February 2025, IBM completed its acquisition of HashiCorp. Neither event broke Vault for most teams. Both made teams ask a sharper question: who controls the terms your secrets tooling runs under.

TL;DR

• The license changed on 10 August 2023. Vault went from MPL 2.0 to the Business Source License 1.1.
• The BSL is source-available, not open-source. It permits almost all production use and restricts only competing hosted offerings.
• IBM completed its $6.4 billion acquisition of HashiCorp on 27 February 2025. Vault is now an IBM product, still under the BSL.
• The community forked Vault into OpenBao, an API-compatible project under the Linux Foundation and the MPL 2.0 license.
• Running Vault yourself keeps the control plane and the unseal keys on infrastructure you choose. We run managed Vault for €9 per app, per month.

What changed, and what didn't

The change was a license, not a code lockdown. On 10 August 2023, HashiCorp switched Vault from the Mozilla Public License 2.0 to the Business Source License 1.1. The source code stays public on GitHub. You can still read it, modify it, and run it in production.

The Business Source License is source-available. The Open Source Initiative does not class it as open-source. That line matters for some teams and is academic for most. The code is published; the terms around one commercial use changed.

Most large teams have seen this license before. The BSL is the same framework MongoDB, Elastic, and others adopted in the years prior. If your legal and procurement people reviewed those moves, they likely hold a position on the BSL already. The novelty is which tool it now covers, not the license itself.

Here is the restriction in plain terms. You may not take Vault's code and offer it as a competing hosted or embedded service against HashiCorp's commercial products. Running Vault internally, including in production, sits outside that restriction. The vast majority of teams never touch the line.

The license has a time limit built in. Each BSL release converts to the MPL 2.0 open-source license four years after it ships. So a release that is restricted today becomes open-source on a known date. The mechanism is the one MariaDB designed for the BSL in 2013.

The free tier has a new name too. What HashiCorp once called open-source Vault is now Vault Community Edition. Vault Enterprise remains the paid, commercial tier. The APIs, SDKs, and most libraries stayed on the MPL 2.0 license.

Then IBM bought the company

A second change landed eighteen months later. On 27 February 2025, IBM completed its acquisition of HashiCorp for $6.4 billion in cash. The deal was announced in April 2024. Antitrust reviews in the US and the UK pushed the close past its original end-of-2024 target.

The delay is worth a sentence, because it shows the deal was not routine. Regulators in two countries opened reviews before signing off. The close came within days of the final approval, ten months after the announcement. The size of the bet is the reason it drew that scrutiny.

Vault is now an IBM product. The license did not revert. Days after the deal closed, the public repositories were still under the BSL, and they have stayed there. The BSL license page now lists an IBM contact address.

For a team already running Vault, the acquisition changed nothing on day one. The binary you deployed still works. Your policies still apply. What changed is the owner of the roadmap and the terms, and that is the part worth thinking about.

Why teams reassessed control of their secrets

Two events stacked: a license change, then a change of owner. On its own, each is survivable. Together they reset an assumption many teams had not examined. The assumption was that the tool holding every credential would keep its terms and its steward stable.

Secrets tooling is not an ordinary dependency. It holds the keys to databases, cloud accounts, and service-to-service traffic. When the terms around that layer move twice in eighteen months, careful teams take a look. Not a fire drill. A review.

The question is narrow and practical. Who controls the license your secrets infrastructure runs under, and who sets its direction. For an internal Vault deployment, the answer today is IBM, under the BSL. For some teams that is fine. For others it is the whole decision.

This is about control, not panic. Vault works. It is mature, widely deployed, and well understood. The reassessment is about ownership of the terms, which is a different axis from whether the software is good. It is good.

The control questions are concrete, not abstract. Who decides the next version's terms. Whether Enterprise pricing moves. Whether a feature you rely on stays in the free tier or shifts behind a contract. None of these has a bad answer today. All of them now sit with a single owner.

What owning your secrets means in practice

Owning your secrets means running the control plane yourself. You hold the unseal keys. The secrets live on storage you chose, in a region you chose. Nothing routes through a vendor's shared service that you do not operate.

Vault is built for this. It encrypts every secret before it writes to storage. Reading the raw storage backend returns ciphertext, not credentials. The encryption barrier is part of the design, not a bolt-on.

Self-hosting keeps the capabilities that made Vault the standard. Dynamic secrets generate short-lived credentials on demand for databases and Kubernetes. The PKI engine issues certificates. The key-value engines hold static secrets. Policies decide who can read what.

The split between dynamic and static secrets is the point. A static secret you store once and rotate by hand. A dynamic secret Vault mints on request and revokes on a lease. Run this yourself and the credentials never sit in a config file or a vendor's shared store. They live briefly, then expire.

The encryption barrier matters because of a specific threat. If someone copies a disk snapshot or reaches the storage backend, they hold ciphertext, not your credentials. The unseal keys, which you control, are what turn that ciphertext back into secrets. Lose the keys and even you cannot read the data, which is the point.

The control plane is what you are actually keeping. Strip away the marketing and these are the concrete things that stay in your hands when you run Vault on infrastructure you choose.

• The unseal keys and the root of trust for your secrets.
• The storage backend and the region your secrets sit in.
• The upgrade cadence and the exact version you run.
• The access policies that decide who reads which secret.
• The license and governance model you commit to.
• A record of every secret read, kept on systems you run.

The options on the table

Three paths are worth knowing before you commit. They differ mostly on license and governance, not on day-to-day features. If you have run Vault, all three feel familiar. The choice is about who holds the terms.

Vault Community Edition (BSL)

This is the free Vault most teams already run. It is source-available under the BSL and stewarded by IBM. Internal production use is permitted, so the license restriction rarely bites. You get the full secrets-engine set without a contract. The trade-off is single-vendor control of the terms and the roadmap.

Vault Enterprise (commercial)

The paid tier adds replication, namespaces, and hardware security module support. It comes with a vendor contract and per-cluster pricing. Teams that need cross-region disaster recovery or strict workload separation often land here. The trade-off is cost and commercial terms set by one vendor.

OpenBao (MPL 2.0, Linux Foundation)

OpenBao is the community fork of Vault, taken from the last MPL 2.0 release before the relicensing. It is API-compatible: the same auth methods, secrets engines, and policies work without code changes. The Linux Foundation governs it, so no single company can relicense it alone. It reached version 2.5.0 in February 2026 and includes namespaces for free.

For teams whose own rules require an open-source license, or who want governance spread across many contributors, OpenBao is the honest alternative. There is a small irony worth noting: IBM engineers were among its early contributors, though IBM has not adopted it as an official project.

Notice the pattern. At the level of secrets engines and API calls, Vault and OpenBao are the same software. The reason to pick one is license and governance, not capability. That is a calmer decision than the relicensing headlines suggested.

The operational reality of running Vault yourself

Self-hosting Vault is not like self-hosting a wiki. It is a power tool, and it earns that label the first time it seals. Run it yourself and you own the operations. That is the honest cost, before any price comparison.

Start with the seal. Vault boots sealed and cannot serve secrets until it is unsealed. You either manage unseal keys by hand or wire up auto-unseal against a cloud key service. Get this wrong and every service that depends on Vault stalls at once.

Then the storage. Production Vault runs an integrated Raft cluster, usually three or five nodes for quorum. You keep the nodes healthy, patched, and reachable. You also back up the storage and the keys, because a backup of one without the other does not restore.

Then the upkeep. TLS certificates renew. New versions ship with fixes you want. The cluster needs someone on call for when it seals at 2am, which it will, on the day a node reboots. None of this is exotic. All of it is real work.

Backup discipline is its own job. You back up the storage data and the unseal keys, and you keep them apart. A snapshot of the data without the keys restores nothing. A copy of the keys without the data restores nothing either. Test a real restore on a schedule, not the day you need it.

Then the watching. Vault fails in quiet ways. A node can fall out of the Raft quorum, a token can expire mid-job, a storage volume can fill. You want alerts on seal status, leader changes, and storage health, or the first sign of trouble is an outage. Observability here is not optional.

Plenty of teams should still do it themselves. If you have platform engineers, an on-call rotation, and the appetite to own this layer, self-hosting on your own infrastructure or a production-class VPS is a sound path. The work is the price of the control. For those teams it is a fair trade.

If you already run Vault

Most readers here are not starting fresh. You have a Vault cluster, a set of policies, and apps that authenticate against it. The useful news is that none of the options demands a rewrite. The decision is about where the cluster runs and under whose terms, not about replacing your integration.

Moving between Vault and OpenBao is the gentlest case. Because OpenBao speaks the same API, your auth methods, secrets engines, and policy files carry over. Teams report it feeling identical in daily use. The migration is an infrastructure move, not an application rewrite.

Moving from a self-run cluster to a managed one has the same shape. Your policies and auth integrations come with you, because the API does not change. What changes is who runs the nodes, the unseal flow, and the backups. Plan the cutover around your secret leases and a downtime window, and test against a copy first.

Where DANIAN fits

If you want the control of self-hosted Vault without the on-call, that is the gap we run in. We offer managed Vault hosting at €9 per app, per month. You pick the region. We patch it, monitor it, and keep encrypted off-site backups. A human answers on chat, around the clock.

The split is honest. We run the instance, the upgrades, the backups, and the monitoring. You own your policies, your auth integrations, and the apps that read from Vault. We will not change your configuration or your resources without your say-so. Your secrets stay on the instance we run for you, in the region you chose.

Migration is the common way in. If you already run Vault, your policies and auth methods move with you, because the API does not change. We help you stage the cutover, move the data, and check that your apps still authenticate. You are changing who operates the cluster, not how your services talk to it.

None of this is a lock-in trade. Because the API is shared, you can move off a managed instance later the same way you moved on. We run the cluster while it suits you, and your policies stay portable the whole time. The control you wanted is the control you keep.

For the smaller jobs around a platform team, there is IT-Tools for sysadmin utilities. It bundles offline tools, token generators, encoders, formatters, hash helpers, that run in the browser without sending data anywhere. It is not secrets management. It is the everyday bench beside it, hosted at the same €9 floor.

How to think about the decision

Three questions settle most of this. Answer them honestly and the path tends to pick itself. None of them is about whether Vault is good software. It is.

1. Do your own procurement or licensing rules require an open-source license? If yes, OpenBao under the MPL 2.0 is the cleaner fit. Vault Community Edition is source-available, which some rules do not accept.
2. Do you have the people and the on-call to run a sealed storage cluster? If yes, self-host Vault or OpenBao on your own infrastructure. If no, that gap is where managed hosting earns its keep.
3. Do you want self-hosted control without operating it at 2am? If yes, managed Vault gives you the region choice and the key ownership while we run the cluster for you.

What to do this week

Start by reading the license, not the headlines. The BSL text is short, and it states plainly what it restricts. Confirm whether your own rules accept a source-available license or require an open-source one. That single answer rules several options in or out.

Then map your real needs. Count whether you require replication or namespaces, or whether Community Edition covers you. Decide whether you have the on-call to run the cluster, or whether you would rather hand that off. Match the path to the answer.

Take the answer to your team as a short brief. Name the license you need, the features you actually use, and whether you have the on-call to run a cluster. Those three lines turn a vague worry about the relicensing into a decision you can defend. Most teams find the choice clearer than the news made it feel.

If the answer is managed Vault, you can start a 7-day trial and have an instance running in the region you choose. This is a factual overview of the licensing landscape, not legal advice. For your own situation, read the license text or ask your counsel.

Frequently asked questions

Did HashiCorp Vault become closed-source?
No. Vault moved to the Business Source License, which is source-available, not closed. The code stays public on GitHub, and you can read, modify, and run it in production. Only one use is restricted: offering Vault as a competing hosted service against HashiCorp's commercial products.

Why did HashiCorp change Vault's license?
HashiCorp wanted more control over how its code was commercialized. The change blocks vendors from taking Vault and selling it as a competing hosted service. The company said its goal was to keep most use free while limiting that one case. The same reasoning drove similar moves at MongoDB and Elastic.

What does the Business Source License restrict?
One thing: you may not offer Vault as a hosted or embedded service that competes with HashiCorp's commercial products. Everything else is permitted, including production use. Each release also converts to the open-source MPL 2.0 license four years after it ships.

When does the Business Source License convert to open-source?
Four years after each release ships. The BSL has a built-in change date: every version flips to the open-source MPL 2.0 license once four years pass. So the Vault build that is restricted today becomes fully open-source on a fixed, known date. MariaDB designed this mechanism in 2013.

Which HashiCorp products besides Vault changed license?
All of HashiCorp's core tools moved together on 10 August 2023. Alongside Vault, the change covered Terraform, Consul, Nomad, Boundary, Packer, Waypoint, and Vagrant. The APIs, SDKs, and most libraries stayed on the open-source MPL 2.0 license. The shift was the whole product line, not Vault alone.

Can I still run Vault in production for free?
Yes. Vault Community Edition is free to run in production under the BSL. The license restricts only competing hosted or embedded offerings, which most teams never build. If you run Vault internally for your own apps, the restriction does not affect you.

What is the difference between Vault Community Edition and Vault Enterprise?
Community Edition is the free tier, source-available under the BSL, with the full secrets-engine set. Enterprise is the paid tier and adds replication, namespaces, and hardware security module support. Both come from HashiCorp, now IBM. Most teams run Community Edition; Enterprise suits large, multi-region setups that need those extras.

Does the BSL affect running Vault in CI/CD?
Running Vault inside your own pipelines is fine. The restriction targets offering Vault as a competing hosted or embedded service to other companies, not your internal automation. If your CI/CD uses Vault to fetch secrets for your own builds, you are well inside the permitted use. The line is about reselling, not internal tooling.

Will self-hosted Vault keep getting security patches under the BSL?
Yes. HashiCorp, now IBM, keeps publishing source and updates, including fixes, to the public repository. Community Edition receives them under the BSL. The fork, OpenBao, ships its own fixes under the Linux Foundation. Either way, a self-hosted instance has a maintained upstream you can pull patches from.

Does IBM owning HashiCorp change how I use Vault?
Not in daily use. Vault is now an IBM product, and the license stayed the BSL after the deal closed on 27 February 2025. Your existing deployment, policies, and integrations keep working. What changed is who owns the roadmap and the terms from here on.

What happens to Vault's roadmap and support now that IBM owns it?
IBM now sets Vault's direction and sells its commercial support. The company said it plans to keep investing in Vault and tie it into its wider tooling. For existing users, support contracts and releases continue. What you are trusting now is IBM's roadmap rather than an independent HashiCorp.

Do I need to do anything right now because of the relicensing?
For most teams, no urgent action is needed. If you run Vault internally, it keeps working under the BSL. The useful step is a short review: confirm your own rules accept a source-available license, and decide whether single-vendor control of the terms is acceptable. That review can happen on your schedule, not in a rush.

What is the difference between Vault and OpenBao?
They are the same software at the API level. OpenBao is a fork of Vault's last open-source release, governed by the Linux Foundation under the MPL 2.0 license. Vault is source-available under the BSL and owned by IBM. The choice is license and governance, not features.

Is OpenBao a drop-in replacement for Vault?
Close to it. OpenBao was forked from Vault's last open-source release and keeps the same API, auth methods, secrets engines, and policy format. Many teams report that day-to-day operations feel identical. Check the newest features and your specific plugins, since the two projects have diverged a little since the fork.

Is OpenBao mature enough for production?
It is maturing fast and already runs in production at several organizations. OpenBao sits under the Linux Foundation with a multi-company contributor base, and reached version 2.5.0 in February 2026 and version 2.7 by October 2026. It inherits Vault's proven architecture. The open questions are the pace of new features and the depth of its plugin ecosystem.

How do I migrate from Vault to OpenBao?
Because the API matches, the move is an infrastructure task, not an app rewrite. You stand up OpenBao, carry over your policies, auth methods, and secrets-engine config, and migrate the stored data. Your applications keep their existing integration. Test the cutover against a copy, and plan it around your secret leases.

Vault or OpenBao, which should I choose in 2026?
It depends on one thing: your stance on license and governance. Pick OpenBao if you need an open-source license or want governance spread across many contributors. Pick Vault Community Edition if you are comfortable with source-available terms and a single steward. At the feature level the two are close enough that this is the real deciding factor.

Can I get commercial support for self-hosted Vault or OpenBao?
Yes, through different channels. Vault has paid support from HashiCorp, now IBM, on the Enterprise tier. OpenBao has community support plus vendors that back it commercially. If you host Vault with us, we run the instance, monitor it, and answer on chat around the clock.

What does it take to run Vault yourself?
Real operational work. You manage unsealing or auto-unseal, run a Raft storage cluster of three or five nodes, renew TLS, and back up both the data and the keys. You also need someone on call for when the cluster seals. It is a power tool, not a set-and-forget app.

If I self-host, do my secrets ever leave my infrastructure?
That is the point of self-hosting. You run the control plane, hold the unseal keys, and keep the storage on infrastructure you chose. Vault encrypts secrets before writing them, so even the storage holds ciphertext. With a hosted setup, you trade some of that direct control for someone else running the cluster.

Can DANIAN run Vault for me?
Yes. We host managed Vault at €9 per app, per month, in the region you choose. We handle patching, monitoring, and encrypted off-site backups, with a human on chat around the clock. You keep your policies and integrations. We will not change your setup without your consent.

Can DANIAN host OpenBao instead of Vault?
We run managed Vault today. OpenBao speaks the same API, so if you would rather we host the open-source fork, tell us, we add apps to the catalog on request. Either way you get the region choice, the patching, the monitoring, and the encrypted off-site backups, with a human on chat.

Is this article legal advice?
No. This is a factual overview of the Vault licensing landscape and the options around it. License terms can change and your own rules may differ. Read the BSL text directly, and ask your own counsel before a decision that turns on the license.

Try managed Vault hosting for 7 days

Sources

1. HashiCorp, "HashiCorp adopts the Business Source License" (10 Aug 2023)
2. HashiCorp, Business Source License 1.1 text
3. HashiCorp, Vault documentation
4. HashiCorp Vault, source repository (GitHub)
5. IBM Newsroom, "IBM Completes Acquisition of HashiCorp" (27 Feb 2025)
6. OpenBao, project site (Linux Foundation, MPL 2.0)