HashiCorp BSL and Disaster Recovery Environments

Disaster recovery is built on duplication. Every important system is mirrored somewhere, ready to take over when the primary fails. That duplication is sensible engineering, and it is also why a license change can feel larger than it is. If a license restricts your use of Terraform, and you run Terraform in three places to survive an outage, it is natural to wonder whether you now carry three times the exposure. The answer turns on what the Business Source License actually restricts, and it does not restrict copies. It restricts a kind of use.

What the BSL restricts, and what it does not

As of August 2023, HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer from an open source license to the Business Source License 1.1. The license permits broad use and then carves out one category: you may not use the software in a product that competes with HashiCorp's commercial offerings. It also converts to an open license after a delay, commonly four years from a release. Source available is not the same as open source, and the Business Source License is not approved by the Open Source Initiative. These are accuracy anchors, dated as of June 2026, in an area that moves quickly.

The restriction is framed around the purpose of the deployment, not its footprint. A single instance used to build a competing product is in scope. A thousand instances used to run your own internal infrastructure are not, on the face of the license, in the restricted category at all. Disaster recovery sits squarely inside that distinction. A standby copy exists to keep your own systems running, which is the ordinary, permitted case. The number of copies does not change the character of the use.

Why disaster recovery copies usually share the primary's posture

A disaster recovery environment is a copy of a production environment that has not yet been called on. Its purpose is identical to the primary: to run the service the primary runs. If the primary use is permitted under the Business Source License, the standby that mirrors it is doing the same kind of work and shares the same posture. If the primary use were competitive and restricted, the standby would carry that same restriction, because it is built to do the same thing. The disaster recovery label does not create a new category of risk. It inherits the category of whatever it protects.

This is why the first question is never how many copies you keep. It is whether the workload those copies support is internal infrastructure or a competing offering. The same logic that decides the primary decides the standby. The way to settle that question for your own estate is covered in is your Terraform use competitive under the BSL, which works through where the line sits in practice.

Hot, warm, and cold standby under the license

Disaster recovery comes in degrees. A hot standby runs continuously alongside the primary. A warm standby is provisioned but idle until needed. A cold standby is little more than stored configuration and images waiting to be brought up. Buyers sometimes assume these tiers carry different license weight, with a running hot copy treated as more exposed than a dormant cold one. The Business Source License does not draw that distinction. It does not meter running time or charge per active instance. What matters is the use to which the software is put, and a recovery copy at any temperature is put to the same use as the primary when it is finally called on.

The version that sits in each tier does matter, however, and for a different reason. A cold standby that holds an image built years ago may be running a Terraform release from before the license change, which remains under the prior open license entirely. A hot standby kept current with the primary may carry the newer Business Source License version. Two copies that look like the same disaster recovery setup can sit under two different licenses, simply because of when their images were built. This is the detail an inventory catches and an assumption misses.

Where disaster recovery use can drift into a concern

There are setups where a recovery environment is not a clean mirror of internal use. A managed service provider that runs disaster recovery on behalf of many customers, using Terraform to stand up and recover infrastructure as part of a service it sells, is in a different position from an enterprise protecting its own systems. The relevant test is the same competitive use question, applied to the service being offered. Where your disaster recovery sits inside a service you sell rather than infrastructure you run, the analysis shifts, and it is worth treating that case explicitly. The provider angle is taken up in HashiCorp BSL and managed service providers.

A second drift point is the failover drill. Teams test recovery by actually failing over, running the standby as if it were live. A drill that exercises your own internal infrastructure is the same category of use as running that infrastructure on an ordinary day. It does not convert permitted internal use into something restricted. The act of testing recovery is not itself a competitive use. The character of the recovered service is what the license looks at, and a drill does not change that character.

What a vendor may raise, and how to be ready

A commercial conversation can still surface total deployment, including disaster recovery copies, as a basis for pricing. That a per copy fee is not written into the license does not stop a list price from being built around instance counts. The defense is evidence. A dated inventory that separates primary from standby copies, records the Terraform version in each, and states the nature of the workload turns an instance count into a bounded, explainable picture. It lets you show which copies run pre change open versions, which sit under the Business Source License, and that the use across all of them is internal infrastructure. The way that footprint is assembled across an estate is set out in Terraform exposure in a multicloud estate, and the obligations that attach once a version is in scope are covered in HashiCorp BSL compliance obligations.

The broader mechanics of the change, the four year conversion, and the OpenTofu fork all sit on the HashiCorp and Terraform BSL pillar. Sizing the disaster recovery question for your own estate is the job of a focused relicensing exposure review, which maps every copy, primary and standby, against its version and use.

We are independent and buyer side. We take no vendor fees and resell no software, so the inventory and the recommendation reflect your risk and nothing else. This is commercial and licensing risk advisory, not legal advice. For interpretation of the Business Source License against your disaster recovery setup, engage your own counsel.