OpenTofu: The Open Source Infrastructure as Code Tool Your Team Actually Owns

What is OpenTofu?

OpenTofu is a fully open source infrastructure as code tool that lets you declaratively define and manage cloud infrastructure using HashiCorp Configuration Language (HCL) or JSON configuration files. The project emerged as a fork of Terraform 1.5.7, the last version released under the Mozilla Public License, and is now maintained under the governance of the Linux Foundation with additional oversight from the Cloud Native Computing Foundation, which accepted OpenTofu as a sandbox project in April 2025.

At its core, OpenTofu works exactly as Terraform users expect. You write configuration files that describe the desired state of your infrastructure, run tofu plan to generate an execution plan showing what changes will be made, and run tofu apply to provision the actual cloud resources.

The tool maintains a state file that maps your configuration to real-world infrastructure objects, enabling it to track changes over time and ensure resources are created, modified, or destroyed in the correct order based on the resource graph it constructs from your dependencies.

The OpenTofu registry hosts thousands of providers and modules, covering major cloud providers like AWS, Azure, and Google Cloud Platform alongside services ranging from Kubernetes and Datadog to GitHub and Cloudflare.

Because OpenTofu maintains backward compatibility with Terraform configurations and existing Terraform providers, teams can manage infrastructure across multiple cloud providers and services without learning a new syntax or abandoning their existing module library.

OpenTofu supports both .tf and .tofu file extensions, with the latter allowing module authors to provide OpenTofu-specific functionality while maintaining Terraform compatibility in the same codebase. It is a production-ready infrastructure as code tool backed by companies whose business depends on its stability and continued development.

What are the origins of OpenTofu?

Something broke in the infrastructure as code world in the summer of 2023, and it wasn't a misconfigured resource or a corrupted state file. HashiCorp announced they were changing Terraform's license and, within days, a coalition of companies and individual contributors had forked the project under a new name and a renewed commitment to open source principles.

That fork is OpenTofu, and in the months since its creation, it has grown from a reactionary project into a genuine alternative with features the community had been requesting for years but never received.

On August 10, 2023, HashiCorp announced they were switching Terraform's license from the Mozilla Public License v2.0 to the Business Source License, a change that would take effect with the release of Terraform 1.6. The BSL is not an open source license. It is a source-available license that allows you to view and modify the code but restricts commercial use, particularly for companies that might offer competing managed services built on Terraform.

Within days, the OpenTF initiative had formed with backing from Gruntwork, Spacelift, Harness, Env0, Scalr, Terrateam and numerous other companies whose platforms and tooling depended on a truly open source Terraform. The initiative's manifesto quickly garnered over 30,000 GitHub stars, demonstrating just how many users cared about the licensing question.

By September 2023, the project had joined the Linux Foundation, ensuring neutral governance and community oversight that no single vendor could override.

The companies backing OpenTofu committed to supporting the project for at least five years with engineering resources, funding, and infrastructure, meaning that this is not an abandoned fork waiting to wither. The Technical Steering Committee includes representatives from multiple organizations, ensuring balanced decision-making, while the transparent roadmap using GitHub milestones lets users see and influence which feature requests get prioritized.

The shift to CNCF in April 2025 further solidified OpenTofu's position in the cloud native ecosystem. The CNCF even granted a special exception to its standard Apache 2.0 licensing requirement, allowing OpenTofu to remain under the MPL-2.0 license it inherited from Terraform. That exception demonstrates how seriously the foundation takes the project's importance to the broader infrastructure management landscape.

OpenTofu vs. Terraform

To understand the differences between OpenTofu and Terraform you need to look at licensing, governance, and feature divergence, because all three have meaningful implications for how teams manage infrastructure.

When it comes to licensing, the distinction is straightforward:

• OpenTofu uses the Mozilla Public License 2.0, which is a genuine open source license approved by the Open Source Initiative
• Terraform uses the Business Source License, which restricts certain commercial uses and is explicitly not an open source license

For internal infrastructure teams, this distinction may not matter operationally, but for companies building products and services on top of the tooling, or for organizations with policies requiring open source dependencies, the licensing question is decisive.

Governance tells a similar story of differentiation:

• OpenTofu development is community-driven through the Linux Foundation's Technical Steering Committee, with representatives from multiple organizations, meaning no single vendor can unilaterally change the project's direction or licensing terms
• Terraform development is controlled entirely by HashiCorp (now part of IBM following the 2024 acquisition), which means the company's business priorities naturally influence the roadmap

OpenTofu vs. Terraform comparison table

Here's a quick comparison table to help you see the key differences between the two:

Aspect	OpenTofu	Terraform
License	Mozilla Public License 2.0 (open source)	Business Source License (source-available)
Governance	Linux Foundation & CNCF, community-driven TSC	HashiCorp/IBM controlled
State encryption	Native client-side encryption with AWS KMS, GCP KMS, Azure Key Vault, OpenBao	Not available
Provider for_each	Supported (v1.9+)	Not available
-exclude flag	Supported (v1.9+)	Not available
Ephemeral resources	Supported (v1.11+)	Not available
Provider compatibility	Full compatibility with Terraform providers	N/A
Registry	OpenTofu Registry (3,900+ providers, 23,600+ modules)	Terraform Registry
Configuration syntax	HCL (.tf and .tofu files)	HCL (.tf files)
Current version	1.11.x	1.10.x

The feature divergence is where things get interesting.

Both OpenTofu and Terraform started from the same codebase at version 1.5.7, and both teams have continued developing new capabilities since the fork. OpenTofu has implemented several long-requested features that Terraform never delivered, while Terraform has introduced its own new features that OpenTofu has sometimes replicated. The result is two tools that share a common foundation but are beginning to diverge in meaningful ways.

OpenTofu and Terraform feature differences

State encryption stands as OpenTofu's flagship differentiator. Introduced in version 1.7, this feature protects sensitive infrastructure data at rest using industry-standard AES-GCM encryption with support for multiple key providers, including AWS KMS, GCP KMS, Azure Key Vault, OpenBao (the open source Vault fork), and a passphrase-based PBKDF2 option for simpler setups.

The Terraform community had requested state encryption for years, but HashiCorp never implemented it. OpenTofu shipped it within months of the fork.

The for_each support for provider configurations, introduced in OpenTofu 1.9, addresses one of the most frustrating pain points in multi-region or multi-zone deployments. Instead of duplicating provider blocks and module calls for each region, you can now define a single provider with a for_each expression and iterate over a set of regions dynamically. This dramatically reduces code duplication for teams managing infrastructure across various cloud providers and regions.

The -exclude flag provides the inverse of -target, letting you apply changes to everything except specified resources or modules. This was one of the most upvoted feature requests on the original Terraform repository and never made it into the product. OpenTofu delivered it in version 1.9.

Deprecation attributes let module authors mark variables and outputs as deprecated with clear warning messages, helping users migrate away from legacy interfaces while maintaining backward compatibility. This feature became stable in OpenTofu 1.11 to better help teams ship reusable modules that evolve gracefully over time.

Version 1.11 also introduced ephemeral resources and write-only attributes, allowing OpenTofu to work with confidential data and temporary credentials without ever persisting them to state or plan files. This addresses a fundamental security concern with infrastructure as code tools that store sensitive values in state, and the enabled meta-argument in the same release provides a cleaner alternative to the count = var.enabled ? 1 : 0 pattern for conditionally creating resources.

OpenTofu 1.10 added OCI registry support for air-gapped environments and native S3 state locking without requiring DynamoDB, two features that simplify operations for enterprise teams with strict security requirements.

Key OpenTofu features

Beyond the features that differentiate it from Terraform, OpenTofu offers the core capabilities that made infrastructure as code successful in the first place.

Declarative configuration

Declarative configuration using HCL syntax means you describe what your infrastructure should look like rather than writing imperative scripts that specify how to create it.

OpenTofu figures out the dependencies between resources, determines the correct order for creating them, and handles the complexity of API calls to your cloud providers.

A few lines of configuration is all you need to define virtual machines, DNS entries, storage buckets, or any other resource your provider supports.

Execution plans

Execution plans let you preview infrastructure changes before applying them.

When you run tofu plan, OpenTofu compares your configuration files to the current state and shows exactly what it will create, modify, or destroy. This review step catches mistakes before they impact production and gives teams the confidence that changes will behave as expected.

State management

State management tracks the mapping between your configuration and real-world infrastructure objects. The state file records resource IDs, metadata, and dependencies so OpenTofu knows what already exists and what needs to change. Remote backends like S3, Azure Blob Storage, and Google Cloud Storage let teams collaborate on shared infrastructure while optional client-side state encryption ensures sensitive data never leaves your machine unprotected.

A strong provider ecosystem

The provider ecosystem includes over 3,900 providers supporting major cloud platforms, SaaS services, developer tools, and on-premises infrastructure. OpenTofu maintains full compatibility with existing Terraform providers, so you get access to the same thriving ecosystem without modification.

The OpenTofu registry indexes documentation for these providers alongside over 23,600 modules that package common infrastructure patterns for reuse.

Modules

Modules let you create reusable infrastructure components that encapsulate best practices and reduce duplication across your organization. You can publish private modules to your own private registry or use community modules from the public OpenTofu registry to accelerate development.

How to install OpenTofu

Getting OpenTofu running on your machine takes only a few commands, depending on your operating system and preferred package manager.

On macOS or Linux with Homebrew, the installation is a single command since the OpenTofu package is available in the Homebrew Core repository:

1. Run brew install opentofu and the package manager handles downloading and configuring the binary
2. Verify the installation with tofu --version to confirm everything is working

On Debian-based Linux distributions like Ubuntu, you'll need to add the OpenTofu repository and GPG key before installing via apt. The process involves:

1. Creating the keyring directory
2. Downloading the GPG keys for package verification
3. Adding the OpenTofu source list to your apt configuration
4. Running sudo apt-get update followed by sudo apt-get install -y tofu.

For RPM-based distributions like Fedora, RHEL, or openSUSE, you can use yum or zypper after configuring the appropriate repository. Snap packages are also available for users who prefer that installation method.

If you need to run multiple versions of OpenTofu simultaneously or want more control over version management, tools like tofuenv provide functionality similar to what tfenv offers for Terraform, letting you switch between versions easily for different projects.

OpenTofu can coexist with Terraform installations if needed, though the two tools use different binary names, so there's no conflict in your PATH. This coexistence makes it possible to pilot OpenTofu on non-production infrastructure while continuing to use Terraform for existing workloads during a migration period.

Some basic OpenTofu commands to memorize

The OpenTofu CLI follows the same command structure that Terraform users already know, with the tofu binary serving as a drop-in replacement in most workflows.

The tofu init command initializes your working directory by downloading any providers and modules referenced in your configuration files from the OpenTofu registry. This is always the first command you run in a new project or after adding new provider or module dependencies. The command also configures your backend for state storage.

The tofu plan command generates an execution plan showing what changes OpenTofu will make to your infrastructure. The output displays resources to be created, modified, or destroyed, along with the specific attribute changes for each. This preview step is essential for catching errors before they affect real infrastructure.

The tofu apply command provisions your infrastructure according to the configuration. By default, it prompts for confirmation before making changes – though you can use the -auto-approve flag in automated pipelines where interactive approval isn't possible. The tofu apply command updates your state file to reflect the new infrastructure state.

The tofu destroy command tears down all resources managed by your configuration, making it useful if you want to clean up test environments or decommission infrastructure that's no longer needed. Like apply, it shows a plan and prompts for confirmation before making changes.

The tofu validate command checks your configuration files for syntax errors and internal consistency without accessing any remote state or cloud provider APIs. This fast feedback loop helps catch typos and structural problems early.

The tofu state family of commands provides advanced state management capabilities, including listing resources, moving items between state files, removing resources from state without destroying them, and importing existing infrastructure into OpenTofu management.

How OpenTofu manages updates and new versions

OpenTofu follows a regular release cadence with the community driving feature prioritization through GitHub issues and voting. The most recent stable version is 1.11, which shipped in December 2025 with ephemeral resources, write-only attributes, and the enabled meta-argument for cleaner conditional resource creation.

Version 1.10 brought:

• OCI registry support for distributing providers and modules through container registries
• Native S3 state locking that eliminates the need for DynamoDB tables
• Experimental OpenTelemetry tracing for performance analysis
• Stable deprecation attributes for module authors

The release crossed 10 million downloads from GitHub releases alone.

Version 1.9 delivered provider iteration with for_each and the -exclude flag, two of the most requested features in the community. Version 1.8 introduced early variable evaluation, allowing variables in previously restricted contexts like module sources and backend configuration.

Version 1.7 was the landmark release that shipped state encryption, provider-defined functions, and loopable import blocks.

The OpenTofu Technical Steering Committee adopted the same support policy as Terraform. Patches continue for the most recent major release as well as up to two prior ones, meaning up to three releases receive security updates at any given time. The 1.11 series is supported until August 2026, and teams running older versions should plan upgrades accordingly.

Bug fixes and security patches flow through point releases, with the project maintaining transparency about CVE remediations and dependency updates. The community can track upcoming features through the public roadmap on GitHub milestones and influence priorities by voting on issues.

Migrating from Terraform to OpenTofu

For teams running Terraform 1.5.x or earlier, OpenTofu is effectively a drop-in replacement requiring only a binary change in most CI/CD pipelines. Existing state files, configuration files, and providers work without modification. For the migration:

1. Install OpenTofu, run tofu init
2. -upgrade to download providers from the OpenTofu registry
3. Verify with tofu plan that no unexpected changes appear
4. Run tofu apply to update the state file

For Terraform 1.6.x and newer versions, the process is similar but may require migrating to a specific OpenTofu version first before upgrading to the latest release. The official migration guides in the OpenTofu documentation walk through the exact steps, including any code changes needed for specific backend configurations.

Before migrating, ensure your Terraform state is clean with no pending changes by running terraform plan and confirming no infrastructure drift exists. Back up your state file (whether local or remote) and exercise your restore procedure at least once. Version your code so you can roll back if needed.

The migration touches your CI/CD pipelines, which need to be updated to use the tofu binary instead of terraform. Most third-party tools that worked with Terraform 1.5 or earlier work fine with OpenTofu. Spacelift, env0, Harness, and other platforms that backed the OpenTofu initiative offer native support.

If you encounter issues, the rollback path is straightforward. Back up any state changes, revert code modifications, run terraform init, and verify with terraform plan that your infrastructure matches the configuration. The OpenTofu Slack and GitHub Discussions provide community support for troubleshooting migration problems.

Why use OpenTofu?

The case for OpenTofu rests on five pillars that matter to different teams for different reasons:

1. No vendor lock-in
2. Community-driven development
3. Faster feature delivery
4. Linux Foundation and CNCF governance
5. Full compatibility with existing Terraform workflows

No vendor lock-in means your infrastructure management tooling cannot be unilaterally relicensed or made proprietary. The Linux Foundation and CNCF governance ensures the project remains community-owned with no single vendor able to dictate terms.

This concern is not theoretical. HashiCorp already changed Terraform's license once, and IBM's acquisition introduces additional uncertainty about long-term direction.

Community-driven development means features get prioritized based on what users actually need rather than what serves a vendor's commercial interests. The transparent roadmap, public issue voting, and Technical Steering Committee ensure the community's voice shapes the product. State encryption, provider for_each, and the -exclude flag all shipped because users asked for them persistently.

Faster feature delivery for capabilities the community has requested illustrates how an open governance model can move quickly when there's consensus on what matters. OpenTofu shipped state encryption within months of the fork when Terraform had ignored the request for years.

Linux Foundation and CNCF governance provides long-term project stability with infrastructure, funding, and organizational support that doesn't depend on any single company's business decisions. The special licensing exception that CNCF granted demonstrates the foundation's commitment to the project's success.

Full compatibility with existing Terraform workflows means migration is low-risk and reversible. You can pilot OpenTofu on development infrastructure, verify it meets your needs, and roll back to Terraform if necessary. The shared heritage ensures your investment in HCL knowledge, existing modules, and operational practices transfers directly.

Conclusion

OpenTofu represents what the infrastructure as code community asked for. An open source project with transparent governance, community-driven development, and features that solve real operational problems. The tooling has matured rapidly since the fork, the ecosystem support has solidified with CNCF adoption, and the feature velocity demonstrates that community governance can deliver results.

Whether you're evaluating OpenTofu for a new project or considering migration from Terraform, the path forward is clear. Install the tooling, test it against your infrastructure, and see how the OpenTofu community's priorities align with your own needs.

For teams looking to operationalize OpenTofu in production environments with proper access controls, audit trails, and collaborative workflows, Stategraph provides the infrastructure control plane to manage OpenTofu at scale. Check out the Stategraph documentation to learn how to integrate OpenTofu into your infrastructure management workflows.

OpenTofu FAQs

Is OpenTofu production ready?

Yes. OpenTofu reached its first stable version (1.6.0) in January 2024, just four months after the fork announcement. Major enterprises, including Fidelity, have migrated production infrastructure to OpenTofu, and the project has surpassed 10 million downloads from GitHub releases alone. The CNCF sandbox acceptance in April 2025 provides additional validation of the project's maturity and governance.

Can I use Terraform providers with OpenTofu?

Yes. OpenTofu maintains full compatibility with existing Terraform providers. The same 3,900+ providers that work with Terraform work with OpenTofu without modification because both tools share the same provider protocol. The OpenTofu registry indexes all major providers and their documentation.

How does OpenTofu handle state management?

OpenTofu uses a state file to track the mapping between your configuration and real infrastructure objects. The state file stores resource IDs, metadata, and dependencies. OpenTofu supports local state files and remote backends, including S3, Azure Blob Storage, GCS, PostgreSQL, and HTTP backends. Unlike Terraform, OpenTofu offers native client-side state encryption with support for AWS KMS, GCP KMS, Azure Key Vault, and OpenBao key providers.

Who maintains OpenTofu?

OpenTofu is maintained under the Linux Foundation with additional oversight from the Cloud Native Computing Foundation as a sandbox project. The Technical Steering Committee includes representatives from env0, Gruntwork, Harness, Spacelift, and Scalr.

Over 100 community contributors have participated in its development, with the core team receiving funding and engineering support from the founding companies for at least five years.

Is OpenTofu compatible with future Terraform releases?

OpenTofu aims to maintain compatibility with Terraform configurations written for version 1.5.x and earlier. As both tools evolve separately, they introduce unique features that may not exist in the other. OpenTofu supports .tofu file extensions that let module authors provide OpenTofu-specific functionality while maintaining .tf files for Terraform compatibility.

For new features introduced in Terraform after the fork, the OpenTofu community evaluates each feature and may implement similar functionality based on community priorities and demand.