Vault's BSL 1.1 license (Business Source License) allows the vast majority of uses, including production deployment for your own company. Vault Community Edition (CE) is free of charge, but it is not open source. The license mainly forbids offering third parties, for a fee, a service that competes with the paid versions sold by IBM, which now owns HashiCorp.
This page clarifies what you can do depending on your professional
context. It is based on the LICENSE file of the upstream Vault
repository and does not replace the official text, which alone is binding.
To choose between Vault and its fork, the comparison is in
Vault vs OpenBao. The features
per edition are in
Vault Community vs Enterprise.
What you will learn
- Tell "source-available" from "open source"
- Read what the BSL license explicitly allows
- Identify the restrictions and the cases that need an agreement with the vendor
- Place your profile (company, consultant, software vendor, hosting provider)
- Compute the date when a version of Vault switches to MPL 2.0
Understanding the BSL 1.1
Before settling your case, you need to know what the BSL 1.1 really is: neither a classic proprietary license, nor an open source license in the sense of the OSI (Open Source Initiative, the organization that certifies which licenses count as open source). Two notions are enough to find your way: the distinction between source-available and open source, then the conversion mechanism that makes the restriction temporary. The following sections apply these two notions to concrete profiles.
Source-available vs open source
The BSL 1.1 license is not recognized as open source by the OSI. HashiCorp describes it as "source-available": the source code is published and you may read and modify it, but the license keeps a commercial restriction. By contrast, MPL 2.0 (Mozilla Public License 2.0) is a recognized open source license, used for example by OpenBao.
| Characteristic | Open source (MPL 2.0) | Source-available (BSL 1.1) |
|---|---|---|
| Source code accessible | Yes | Yes |
| Modification allowed | Yes | Yes |
| Internal use | Yes | Yes |
| Redistribution | Yes | Yes (with conditions) |
| Commercial use | Yes, no restriction | Partially: "paid competing offer" restriction |
| OSI recognition | Yes | No |
How does the BSL mechanism work?
The BSL 1.1 works in two stages:
- BSL period (4 years): restriction on paid competing offers
- Automatic conversion: after 4 years, the code becomes MPL 2.0
Concretely, Vault 1.15.0 is the first version published under the BSL:
1.14 was still under MPL 2.0. The LICENSE file names "Vault Version 1.15.0 or
later" as the Licensed Work, so every version since 1.15.0. It was
released on September 26, 2023, and its license file sets the Change
Date (the conversion date) to four years after publication, with MPL 2.0
as the Change License (the license the code switches to). This code will
therefore become MPL 2.0 again in September 2027.
The point to remember is not the date itself: it is that each version has its own, computed from its own publication. Version 2.1.2, published on October 7, 2026, will only switch to MPL 2.0 in October 2030. The conversion never frees the current version, only the one from four years ago.
What the license allows
Starting with the permissions avoids a frequent misreading: the BSL limits neither features, nor volume, nor production use. The Community edition (the free edition) remains complete and deployable as it is. The two tables below separate technical uses from commercial uses, because the latter are the ones that raise questions.
Which uses are explicitly allowed?
These uses cover the daily life of a team running Vault for itself. Keep an eye on the Comment column: the text explicitly excludes from the restriction the internal use by an organization, including its affiliates under common control (a group and its subsidiaries count as a single organization).
| Use | Allowed | Comment |
|---|---|---|
| Deploy Vault in production | Yes | For your own internal needs |
| Use all the CE features | Yes | No functional limitation |
| Modify the source code | Yes | For your internal needs |
| Integrate it into your applications | Yes | Vault as a component of your infrastructure |
| Train your teams | Yes | Internal training |
| Distribute modifications | Partially | Under conditions (see below) |
Which commercial uses are allowed?
Earning money with an activity that relies on Vault is not a problem in itself. The rows below have one thing in common: in each of them, what you sell to the customer is something other than Vault itself, or does not overlap with IBM's paid versions.
| Activity | Allowed |
|---|---|
| Use Vault for your business (e-commerce, SaaS, etc.) | Yes |
| Store your customers' secrets (inside your application) | Yes |
| Advise on and deploy Vault at your customers' (consulting) | Yes, see the nuance below |
| Train third parties on Vault (commercial training) | Yes |
| Create plugins for Vault | Yes |
Consulting deserves a nuance. Deploying Vault at a customer's or helping them use it does not look like a competing offer: you do not provide the product, you work on the customer's infrastructure. But the text does not name consulting explicitly, and it places paid support inside the definition of a competing offer. A recurring support service on Vault should therefore be confirmed in writing.
What the license restricts
The whole restriction fits in a single paragraph of the license, the Additional Use Grant (the clause that adds permissions on top of the base license terms). It mentions neither revenue, nor number of users, nor business sector: it targets a paid competing offer. Read it to the letter before concluding anything about your case.
What does the Additional Use Grant say?
The current text of the upstream LICENSE file grants production use,
provided you do not provide the product to third parties "on a hosted or
embedded basis in order to compete with IBM Corp's paid version(s)". The
licensor (the party granting the license) is therefore IBM, owner of
HashiCorp since February 2025, and not HashiCorp alone as in the older versions
of the text.
The text then defines what a competing offer is: a product offered to third parties for a fee, including through paid support agreements, and that significantly overlaps the capabilities of IBM's paid versions. It specifies that a non-paid product is not competing, and that internal use within an organization (affiliates under common control included) is not a competing offer. The deciding criterion is therefore whether it is paid, not whether it is hosted.
What does this mean in practice?
The table applies the clause to five common business models, with the same criterion on each row: is the offer paid for by third parties, and does it significantly overlap Vault Enterprise or HCP Vault? (HCP Vault is HashiCorp Cloud Platform's managed Vault service.) The first two rows differ only by the price.
| Activity | Paid offer for third parties? | Allowed? | Reason |
|---|---|---|---|
| Offer a "Vault-as-a-Service" billed to third parties | Yes | No | Hosted, paid offer that overlaps IBM's paid offers |
| Offer a hosted Vault for free to third parties | No | Yes | A non-paid product is not competing; confirm if any consideration exists |
| Build a "Secrets Manager" based on Vault and sell it | Yes | No | Paid product that embeds Vault and overlaps its capabilities |
| Embed Vault in your paid SaaS (backend only) | Yes, but for something else | Yes | Vault is a component, your product does not significantly overlap IBM's offers |
| Sell paid support on Vault | Yes | To confirm in writing | Paid support falls under the definition of a competing offer: ask for a written agreement |
Which edge cases need clarification?
If your model includes one of these elements, contact the licensing department (see below):
- A paid multi-tenant offer where each customer gets their own "Vault"
- A paid secrets management product based on Vault
- A managed HashiCorp Vault service, even if it is not your core business
- Resale of licenses or of paid support
Which situation matches your profile?
Four profiles cover most of the cases this license raises. Identify yours and read only the matching section: the first two are mostly green lights (the consultant with one caveat on paid support), the other two depend on the exact model. The criterion that separates them is always the same: do you offer Vault to third parties, for a fee?
Company using Vault internally
Verdict: no restriction
Whether you are a startup, a small business or a large group, using Vault to manage your own secrets is the standard use case. Internal use is explicitly excluded from the notion of a competing offer, subsidiaries included.
Examples of allowed uses:
- Store your database credentials
- Manage your applications' API tokens
- Internal PKI (public key infrastructure, to issue your own certificates)
- Transit encryption for your data
- Dynamic secrets for your environments
Consultant or integrator
Verdict: allowed for one-off services
Consulting around Vault does not provide the product to third parties, it works on the customer's infrastructure:
- Audit a Vault installation
- Deploy Vault at a customer's
- Train a customer's teams
- Write Ansible playbooks for Vault
- Develop custom plugins
What would fall outside the frame:
- Offering a paid managed Vault service to several customers
- Selling a recurring paid support contract on Vault, to be confirmed
Software vendor or SaaS
Verdict: generally allowed, with nuances
If Vault is a component of your architecture, these uses are allowed:
- Secrets backend for your SaaS application
- Transit encryption in your pipeline
- PKI for your internal certificates
If Vault becomes the product you sell, these uses are not allowed without an agreement:
- Paid "Vault-as-a-Service" for your customers
- Paid "Enterprise Secrets Manager" based on Vault
In that second case, contact the licensing department for a commercial agreement.
MSP or hosting provider
Verdict: depends on the model
This profile is particularly exposed, because the activity of a hosting provider (an MSP, managed service provider) naturally looks like a managed service. Everything hinges on whether you bill your customers for access to Vault.
| Model | Allowed? |
|---|---|
| Vault for your own hosting infrastructure (internal use) | Yes |
| Dedicated Vault cluster per customer, billed | To confirm: probably competing, ask for a written agreement |
| Multi-tenant "managed Vault", billed | No |
| Vault hosted for free for your customers | Yes, a non-paid product is not competing |
If you are an MSP and want to offer Vault to your customers, clarify with the licensing department or consider OpenBao.
How does it compare with the alternatives?
If your model runs into the restriction, or if your internal policy requires a license recognized by the OSI, two comparable solutions exist. OpenBao is the Vault fork under MPL 2.0, detailed in Vault vs OpenBao and in the OpenBao guide (in French). Infisical is a separate product, to be assessed on its features and not as a direct replacement.
One nuance not to miss about Infisical: it is often described as "MIT", which is true for the core only. Its license file reserves all the code located under an ee/ directory for a separate enterprise license, and these directories do exist in the repository. GitHub does not classify the project as MIT either, but under an "other" license. It is an open-core model (a free core plus paid extensions): if the feature driving your choice lives in ee/, the MIT license does not cover you. Check feature by feature.
| License | Vault BSL | OpenBao MPL 2.0 | Infisical (open-core) |
|---|---|---|---|
| Internal use | Yes | Yes | Yes |
| Consulting | Yes | Yes | Yes |
| SaaS (component) | Yes | Yes | Yes |
| Paid managed service | No | Yes | Partially: outside the ee/ modules |
| Modification/fork | Yes | Yes | Partially: outside the ee/ modules |
| OSI recognition | No | Yes | Partially: MIT core only |
What should you do if you have doubts?
A doubt about a license is settled in writing, not by interpreting a blog post. The approach takes four steps, the first of which matters most: describe your architecture precisely before asking the question. A request phrased in terms of access flows and billing gets a clear answer, a request phrased in terms of business model gets a vague one.
What are the recommended steps?
Follow them in order. The fourth is not an admission of failure: switching to OpenBao is sometimes faster than getting a written agreement.
- Describe your use clearly (who accesses Vault, how, and who pays for what)
- Read the official FAQ: HashiCorp license FAQ
- Contact the licensing department if needed (
licensing@hashicorp.com) - Consider OpenBao if the BSL license is a problem
When should you contact the licensing department?
These four situations share one point: a third party gets direct access to Vault for a fee, or a financial consideration relates to Vault itself. In all other cases, reading the license is enough.
- Your model involves exposing the Vault APIs to third parties for a fee
- You are considering a paid managed service
- You want to sell paid support
- Your legal department asks for a written clarification
What does it imply for your strategy?
The BSL is a license with a built-in clock: each published version carries its own switch date to MPL 2.0. An architecture decision made today is therefore not judged on the current state of the license, but on the state it will have when the version you deploy reaches the end of its period. The three horizons below frame this thinking, they do not predict the market.
Short term (1-2 years)
Nothing to change if your use is standard. The useful effort is documentary: record your analysis so you can produce it during an audit.
- The BSL license is not a brake for most uses
- Vault 1.15.0 becomes MPL 2.0 in September 2027
- Keep using Vault CE if your use is standard
- Document your license analysis (for audits)
Medium term (2-4 years)
This is the period when the versions published after 1.15.0 convert to MPL 2.0, one date per version, and when OpenBao's maturity becomes measurable. The right reflex is to watch, not to migrate in advance.
- OpenBao matures and may become a viable alternative
- Follow what HashiCorp/IBM does, and reread the license text at each major version
Long term (5+ years)
At this horizon, all the code published today will have switched to MPL 2.0: version 2.1.2, for example, in October 2030. The projections below remain hypotheses and must not ground a contractual commitment.
- The ecosystem will stabilize (Vault BSL + OpenBao MPL)
- The converted versions will be 100% open source
- Alternative tools (Infisical, etc.) gain maturity
Key points
- Internal use = OK: no restriction, affiliates under common control included
- The deciding criterion is whether it is paid: a non-paid product is not a competing offer, paid support counts as paid
- Consulting and SaaS (backend) = OK: Vault as a component, with written confirmation for recurring support
- Paid competing managed service = No: offering Vault-as-a-Service for a fee is forbidden
- Licensor and contact: IBM,
licensing@hashicorp.com, FAQ athashicorp.com/license-faq - Automatic conversion: each version becomes MPL 2.0 four years after its publication (1.15.0 in September 2027)
Knowledge check
Check that the essentials of this lesson are in place. The questions only cover what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
A new full quiz with random questions
Work again only on the questions you missed
Frequently asked questions
These five questions come up systematically, and four of them rest on the same misunderstanding: believing that merely having customers or making money triggers the restriction. The answers below bring each one back to the real criterion: a paid offer that competes with IBM's paid versions.
offer Vault itself to third parties, for a fee, in competition with
IBM's paid versions. A non-paid product is not competing.
OSI licenses, you must use OpenBao (MPL 2.0) or another solution.
production. If you redistribute your modifications, you must publish them
under the BSL (or wait for the MPL 2.0 conversion).
If your plugin embeds Vault code, the BSL license applies to that part:
reread the text or ask the licensing department
(
licensing@hashicorp.com).years. In addition, the OpenBao fork exists as a lasting alternative.