BSL is not an open-source license as defined by the Open Source Initiative: it restricts commercial use deemed competitive with HashiCorp’s offerings. Overnight, thousands of organizations that had built their infrastructure around Terraform found themselves in uncomfortable legal uncertainty.
The response was swift. Less than a month after the announcement, a manifesto calling for a return to an open-source license had gathered 33,000 GitHub stars and the support of nearly 140 companies. HashiCorp did not budge. The fork was published in September 2023, brought into the Linux Foundation, and renamed OpenTofu. Since January 2024, it has been in stable production. Since April 2025, it has been part of the Cloud Native Computing Foundation (CNCF).
Our Terraform provider is fully compatible with OpenTofu. No changes to your configurations are needed to use it.
What is OpenTofu?
OpenTofu is an open-source infrastructure as code (IaC) tool, forked from the last MPL 2.0-licensed version of Terraform (1.5.x), distributed under that same Mozilla Public License 2.0. It lets you describe, provision, and manage cloud infrastructure through declarative configuration files written in HashiCorp Configuration Language.
It is developed under the governance of the Linux Foundation, with a Technical Steering Committee made up of representatives from multiple organizations — Gruntwork, Spacelift, Harness, Env0, Scalr — so that no single company can control its direction. That governance model is precisely what convinced many teams to make the switch: a guarantee that the tool will remain truly open source, regardless of how its contributors evolve commercially.
In practice, OpenTofu works with the same .tf files, the same providers, the same modules, and the same CLI workflow as Terraform — init, plan, apply, destroy. For the vast majority of teams, migrating comes down to replacing the binary.
What’s the actual difference with Terraform?
The main difference is the license, and everything it implies in the long run.
Terraform is now distributed under the BSL, which restricts commercial uses that could be considered competitive with HashiCorp — a deliberately vague notion that HashiCorp (now a subsidiary of IBM) may interpret differently in the future. OpenTofu is distributed under MPL 2.0, a true open-source license with no commercial restrictions.
Beyond the license, the two projects have started to diverge technically since the fork. The most notable differences to date:<ul> <li><strong>State encryption:</strong> OpenTofu natively supports client-side encryption of state files — a feature long requested by the community that Terraform has still not implemented.
- Governance: OpenTofu is steered by a multi-organization technical committee within the Linux Foundation. Terraform is controlled by IBM via HashiCorp, with a roadmap driven by commercial priorities.
- Compatibility: OpenTofu maintains syntactic and functional compatibility with Terraform. Existing providers, modules, and configurations work without modification for the vast majority of use cases.
- The
.tofuextension: OpenTofu supports this extension alongside.tf, allowing module authors to provide OpenTofu-specific variants while remaining compatible with Terraform. - Terraform Actions: HashiCorp introduced “actions” in Terraform 1.9+, a feature that lets you trigger custom behaviors during resource lifecycle events. OpenTofu does not yet support them — this is the inherent trade-off of any fork: new proprietary Terraform features are not automatically available, and their implementation in OpenTofu depends on the technical committee’s priorities.
Why teams are migrating to OpenTofu
Three reasons come up consistently.
Legal risk. The BSL prohibits using Terraform in products that could compete with HashiCorp’s commercial offerings. For teams building internal platforms, cloud products, or managed services, this uncertainty is a real operational risk — especially since the definition of “competitive” belongs to HashiCorp and can evolve. On top of that, there is a less visible but equally significant reality: in the Terraform registry, open-source providers get no special visibility. Getting an “official” badge requires negotiating directly with HashiCorp — and paying for it. In the OpenTofu registry, all providers are on equal footing, regardless of the size or resources of their maintainers.
Strategic autonomy over tooling. Your infrastructure as code is the foundation of everything else. Depending on a tool controlled by a US company subject to the Cloud Act means introducing an additional dependency that many organizations would rather avoid. OpenTofu, under Linux Foundation / CNCF governance, offers continuity independent of any commercial actor.
Features Terraform doesn’t ship. Native state file encryption is the most frequently cited example: requested by the community for years, implemented within months by OpenTofu. It is also a signal about how quickly community-driven governance can respond to real needs, compared to a roadmap driven by commercial interests.
Migrating from Terraform to OpenTofu
For the vast majority of teams, migration takes a matter of minutes. All you need to do is make sure the state is clean, install OpenTofu, and replace terraform with tofu in your commands.
# Make sure your state is clean before migrating terraform plan
# → “No changes. Your infrastructure matches the configuration.”
# Install OpenTofu on macOS brew install opentofu
# Install OpenTofu on Linux
curl –proto ‘=https’ –tlsv1.2 -fsSL https://get.opentofu.org/install-opentofu.sh | sh
# Resume your normal workflow
tofu init
tofu plan
tofu apply
Existing .tf files do not need to be modified. The OpenTofu registry mirrors all providers available on the Terraform Registry — including the Clever Cloud provider.
OpenTofu on Clever Cloud: nothing to change
Our official provider (CleverCloud/clevercloud, currently version 1.10) works identically with both Terraform and OpenTofu. The provider source, HCL syntax, and all available resources are exactly the same. A minimal example to deploy a Node.js application with a PostgreSQL database:
terraform {
required_providers {
clevercloud = {
source = “CleverCloud/clevercloud”
version = “~> 1.10”
}
}
}
provider “clevercloud” {organisation}
resource “clevercloud_node” “app” {
name = “mon-app-node”
region = “par”
min_flavor = “XS”
max_flavor = “M”
}
resource “clevercloud_postgresql” “db” {
name = “ma-base-postgres”
region = “par”
plan = “dev”
}
tofu init
tofu plan
tofu apply
The OpenTofu + Clever Cloud combination is a fully sovereign IaC stack: open-source tooling under Linux Foundation / CNCF governance, infrastructure hosted in our own data centers in France, outside the reach of the US Cloud Act. It is the choice increasingly made by teams who want full control over their entire toolchain — not just their data.
The Clever Cloud provider is available on the Terraform Registry and fully open source on GitHub.
Q&A
Is OpenTofu compatible with my existing Terraform configurations?
For the vast majority of use cases, yes. OpenTofu maintains syntactic and functional compatibility with Terraform. Existing .tf files, providers, and modules work without modification. Testing in a non-production environment before switching critical workloads is recommended.
Is OpenTofu production-ready?
Yes. The first stable version was released in January 2024. The project has since surpassed 10 million downloads and is used in production by organizations of all sizes, including Fortune 500 companies. Its integration into the CNCF in April 2025 reinforced its credibility for enterprise environments.
What is the open-source alternative to Terraform?
OpenTofu is the primary open-source alternative to Terraform. Distributed under MPL 2.0, maintained by the Linux Foundation, and a CNCF member, it is the direct continuation of Terraform in its original open-source state.
Is the Clever Cloud Terraform provider compatible with OpenTofu?
Yes, with no configuration changes required. Our official provider (CleverCloud/clevercloud) works identically with both Terraform and OpenTofu.
How does OpenTofu work?
In the same way as Terraform: you describe the target state of your infrastructure in HCL, OpenTofu computes the necessary changes (tofu plan) and applies them (tofu apply). It manages dependencies between resources, the state, and the full lifecycle of each resource. This is also where IBM’s acquisition of HashiCorp introduces additional uncertainty: projects built around Terraform, such as CDK for Terraform, could be deprioritized or discontinued based on IBM’s commercial decisions. With OpenTofu, the roadmap is public, discussed through open RFCs, and does not depend on decisions made behind closed doors by a single actor.