Back to blog

// OSSeva Blog

Migration

HashiCorp Consul End of Life: The BSL Licence, IBM Support Cycles and Your Options

Randall McClure11 min read

The short answer

Two separate things happened to HashiCorp Consul, and they are often confused. The first is the licence. On 10 August 2023 HashiCorp announced that future releases of its products would move from the Mozilla Public License 2.0 (MPL 2.0) to the Business Source License 1.1 (BSL). For Consul, the first minor release under the BSL is 1.17.0. The last minor line that is fully MPL is 1.16, up to and including 1.16.3.

The second is support. After IBM completed its acquisition of HashiCorp on 27 February 2025, Consul Enterprise moved to IBM's Support Cycle-2 model with the April 2026 release, 2.0. Consul 1.21.x is the last LTS release under the old scheme. As of 29 September 2026, the 1.15, 1.16, 1.17, 1.18, 1.19 and 1.20 lines are past end of support, and 1.22 ends on 31 October 2026. Only 2.0.x, 1.22.x and 1.21.x are still supported.

If you run self-managed Consul on an older line, you have four options: upgrade to 2.x, buy Consul Enterprise, move service discovery to etcd or to Kubernetes, or stay on an MPL-licensed line with third-party security patches while you decide.

What the BSL change did to the Consul licence

HashiCorp's announcement said that all future releases of its products would ship under the BSL, and Consul was on the list. APIs, SDKs and most libraries stayed on MPL 2.0. The LICENSE file in the Consul repository changed the next day, 11 August 2023.

The dividing line is set in the LICENSE file itself, and it is not quite as clean as "1.16 is MPL, 1.17 is BSL":

  • Consul 1.17.0 and later are BSL. The licence names the licensed work as Consul version 1.17.0 or later.
  • Consul 1.16.0 to 1.16.3 are MPL 2.0.
  • Later patches on older branches are BSL too. The LICENSE in v1.16.6 covers 1.16.4 or later, and the LICENSE in v1.15.10 covers 1.15.8 or later. So 1.15.7 is MPL and 1.15.8 is not.

That last point matters for anyone planning to "stay on the open source version". A patch release on the 1.15 or 1.16 branch is not automatically MPL. Check the LICENSE file in the exact tag you deploy.

How the Change Date works

The BSL is a delayed open source licence. Each version carries a Change Date, and on that date the version converts to the Change License. For Consul the Change Date is four years after a version is published and the Change License is MPL 2.0. Consul 1.17.0 was published on 3 November 2023, so that release becomes MPL 2.0 in November 2027. Every later release follows on its own four-year clock, which means the MPL code you can use freely always trails the current release by four years.

What the Additional Use Grant allows

The BSL itself permits copying, modification, redistribution and non-production use. Production use comes from the Additional Use Grant, which allows it unless your use is a competitive offering: offering Consul to third parties, hosted or embedded, in competition with IBM's paid versions. The definition counts paid support arrangements that significantly overlap with IBM's paid versions. Running Consul for internal purposes within your own organisation is not a competitive offering.

For most self-managed users, then, the BSL does not stop you running Consul in production. It does limit what a third party can sell you around the BSL releases, and that shapes the options below. The licence links to HashiCorp's licence FAQ for binding interpretation. Read both, and involve your legal team, before you rely on any reading of it, including ours.

What IBM changed

IBM completed the HashiCorp acquisition on 27 February 2025. On 18 March 2026 the Licensor in Consul's LICENSE changed from HashiCorp, Inc. to International Business Machines Corporation. The licence is still BSL 1.1 with the same four-year Change Date. What changed more for operators is the support model.

Consul support policy: from STS and LTS to IBM Support Cycle-2

Before 2026, Consul used two tracks:

  • Standard Term Support (STS). Each major release got approximately one year of support and was maintained until it was three releases behind the latest major release. Consul 1.14.x, for example, was maintained until 1.17.0 shipped.
  • Enterprise Long-Term Support (LTS). Starting with 1.15, the first major release of each calendar year got about two years of support, maintained until it was six releases behind. The LTS lines were 1.15, 1.18 and 1.21.

From the April 2026 release, 2.0, Consul Enterprise follows IBM Support Cycle-2 (SC2). It is a "2 + 1 + 3" model: two years of base support, one year of critical extended support, and three years of sustained support. Versioning moves from semantic versioning to IBM's V.M.F scheme, with a Version each April, a Modification each October and monthly Fixes. HashiCorp's documentation says Consul v1.21.x is the last LTS release.

Consul versions and end-of-support dates

The table combines the first release date of each line from GitHub, the licence from each LICENSE file, and the end-of-support dates IBM publishes for Consul Enterprise. Where IBM does not list a date, the line ended under the three-release STS rule.

LineFirst releaseLicenceEnd of supportStatus on 29 Sep 2026
1.15 (LTS)24 Feb 2023MPL 2.0 to 1.15.7; BSL from 1.15.830 Apr 2025End of life
1.1626 Jun 2023MPL 2.0 to 1.16.3; BSL from 1.16.4Ended under STS ruleEnd of life
1.173 Nov 2023BSLEnded under STS ruleEnd of life
1.18 (LTS)27 Feb 2024BSL30 Apr 2026End of life
1.1912 Jun 2024BSLEnded under STS ruleEnd of life
1.2015 Oct 2024BSLEnded under STS ruleEnd of life
1.21 (last LTS)6 May 2025BSL30 Apr 2027Supported
1.2227 Oct 2025BSL31 Oct 2026Supported, ends in weeks
2.024 May 2026BSL30 Apr 2028; extended to 30 Apr 2029; sustained to 30 Apr 2032Supported

The latest GA release is v2.0.4, published on 10 September 2026. A v2.1.0 release candidate was tagged on 29 September 2026.

What end of life means for self-managed community users

The dates above are IBM's commitments to Consul Enterprise customers. The community edition has no support contract behind it: fixes arrive as new releases on the lines that are still maintained, and a line past its end-of-support date should be expected to get no further patches. HashiCorp's upgrade guidance tells community edition users to upgrade about every four months.

In practice that leaves three groups exposed:

  • Clusters still on 1.15 or 1.16. Often held there on purpose, because they are the last MPL releases. They get no fixes from upstream, and any fix published since is in a BSL release.
  • Clusters on 1.17 to 1.20. Already under the BSL, now also out of support. The licence change has happened to them without the benefit of a supported line.
  • Clusters on 1.22. Supported for a few more weeks. The next move is to 2.0.x, which is also the first release under the IBM versioning scheme.

An unpatched Consul cluster is not a minor component. It holds your service catalogue, node health checks, key/value configuration and, if you use Consul service mesh, the TLS certificates and intentions that control which services may talk to each other. A security finding against it is a finding against the control plane of every service that registers there.

Your options

1. Upgrade to Consul 2.x

This is the path IBM expects. Consul's general upgrade procedure is a rolling one: read the upgrade notes for the target version, including any changed default setting, install the new binary on each server, restart servers one at a time and wait for each to rejoin the cluster and report healthy, then do the same for client agents and any Envoy proxies. Take a consul snapshot save before you start, and monitor leader elections and Raft health while each node rejoins. Enterprise clusters moving from 1.21.x to 2.0.x have their own upgrade guide, and HashiCorp notes that LTS releases support an upgrade jump of at most three major versions. From 1.15 or 1.16 that means planning intermediate hops, not a single jump.

The trade-off is the licence. Upgrading moves you onto BSL code for good. For internal use that is usually acceptable. Confirm it with legal before you start, not after.

2. Move to Consul Enterprise

Enterprise gives you the SC2 support cycle, with up to six years on a 2.x release across base, extended and sustained support, plus the LTS history on 1.21. It is the least disruptive route if you are staying on Consul long term and want a vendor on the hook.

3. Move service discovery to etcd or Kubernetes

Many Consul deployments exist to do service discovery and configuration for workloads that now run on Kubernetes. There, Kubernetes Services and cluster DNS do the discovery, and ConfigMaps and Secrets hold the configuration. Consul may be doing work the platform already does. Where you need a standalone, strongly consistent key/value store, etcd is Apache 2.0 licensed and currently maintains three release branches: v3.5, v3.6 and v3.7, with v3.4 at end of life since June 2026.

Neither is a drop-in alternative for every deployment. Consul's health checking, multi-datacenter federation, DNS interface and service mesh have no single equivalent, and the migration effort sits in the applications and sidecars that talk to the Consul API. For the design differences, see our comparison of ZooKeeper, etcd, Consul and KRaft.

4. Stay on an MPL line with third-party security patches

MPL 2.0 lets anyone modify and redistribute the code, provided changes to MPL-covered files are published under the MPL. A third party can therefore maintain patched builds of Consul 1.16.3, 1.15.7 and earlier MPL releases. This buys time without accepting the BSL, and it suits estates where a transition to etcd or Kubernetes is the real destination.

The limit is just as clear. The fixes have to be written against the MPL source code. Copying a fix from a BSL release brings the BSL terms with it, and selling paid support around BSL releases can fall within the licence's definition of a competitive offering. A patched MPL build also will not gain the features added since 1.16, so it is a bridge, not a destination.

Choosing a route

If this describes youLikely route
Consul is strategic, the BSL is acceptable for internal useUpgrade to 2.x; add Enterprise if you need vendor support
Workloads are on Kubernetes and Consul mainly does discoveryPlan the move to Kubernetes-native discovery
You need a key/value store with an open source licenceetcd, with an MPL Consul line patched in the meantime
Legal will not accept the BSL and the migration is a year outStay on 1.16.3 or 1.15.7 with third-party patches, and schedule the migration

Where OSSeva fits

OSSeva provides Consul extended support within the licence limits above: patched builds of the MPL-licensed Consul lines, upgrade planning for clusters moving to 2.x, and migration planning for estates moving discovery to etcd or Kubernetes. We do not redistribute patched BSL code. If Consul sits next to a ZooKeeper ensemble in your estate, the same team covers ZooKeeper extended support, and our end-of-life tracker lists the dates for the rest of the stack.

Frequently asked questions

Is HashiCorp Consul end of life?

Consul as a product is not end of life. IBM still releases it, and 2.0.4 shipped on 10 September 2026. Individual lines are: 1.15 through 1.20 are past end of support, and 1.22 ends on 31 October 2026.

Which Consul version is the last open source release?

The last minor line under MPL 2.0 is 1.16, up to 1.16.3. On the 1.15 branch, releases up to 1.15.7 are MPL. Everything from 1.17.0, and later patches on the older branches, is under the BSL.

Can I still use Consul in production under the BSL?

For internal use, generally yes. The Additional Use Grant allows production use unless you offer Consul to third parties in competition with IBM's paid versions. Check the licence and HashiCorp's licence FAQ with your legal team.

When does Consul 1.17 become open source again?

Each version converts to MPL 2.0 four years after it is published. Consul 1.17.0 was published on 3 November 2023, so it converts in November 2027.

What is the last Consul LTS release?

Consul 1.21.x, supported until 30 April 2027. From 2.0, Consul Enterprise follows IBM Support Cycle-2 instead of the LTS scheme.

Is there an open source alternative to Consul?

For key/value storage and coordination, etcd is Apache 2.0 licensed. For service discovery on Kubernetes, the platform's own Services and DNS cover most use cases. Neither replicates Consul's service mesh or multi-datacenter features one for one.

Tags

ConsulHashiCorpBSLEnd of LifeService DiscoveryIBM

Ready to get your open source under control?

Talk to an OSSeva engineer about CVE coverage, compliance, and migration support for your stack.