What is OpenTofu?

OpenTofu is the open-source fork of Terraform: MPL 2.0 licensed, run by the Linux Foundation, and a CNCF project since April 2025. It was created in August 2023, after HashiCorp moved Terraform to the Business Source License (BSL), by a group of infrastructure companies including Gruntwork, Spacelift, Harness, env0, and Scalr. For most teams the switch is a binary swap. It reads the same HCL, uses the same providers, and writes the same state file, and it adds a few things Terraform's CLI never shipped, like built-in state encryption and provider for_each. The current stable release is v1.12.2 as of June 2026.

What is OpenTofu?

OpenTofu is a drop-in replacement for Terraform. It stays compatible with your existing configurations and adds real improvements on top. It's an Infrastructure as Code (IaC) tool that lets engineers define infrastructure resources declaratively using HashiCorp Configuration Language (HCL).

Core Capabilities

OpenTofu uses human-readable configuration files to define infrastructure declaratively, so engineers describe the infrastructure state they want instead of writing procedural scripts. It builds a resource graph to work out dependencies, then applies changes in the right order.

resource "aws_instance" "example" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
 
  tags = {
    Name = "example-instance"
  }
}

State File Management

The state file is the source of truth that maps your configuration to real infrastructure objects. OpenTofu reads and writes the same state format as Terraform, so an existing remote backend keeps working after the switch; the backend configuration guide covers where to put it and how to lock it.

Community and Governance

With over 29,000 GitHub stars as of June 2026 and more than 70 active contributors, OpenTofu is a busy open-source project. As a Linux Foundation project, it's guided by a Technical Steering Committee that represents several companies, so no single vendor controls it. The CNCF accepted OpenTofu in April 2025, which cements its place in the cloud-native ecosystem.

What ships next isn't a secret. The roadmap lives in GitHub milestones, and anything bigger than a bug fix goes through a public RFC you can comment on before it's built. There are weekly community meetings and an active Slack. CNCF acceptance also means no single company can pull the project back under its own license.

OpenTofu History & Milestones

OpenTofu moved from a community manifesto to a CNCF project quickly:

• August 2023: HashiCorp changes Terraform's license from MPL v2.0 to the Business Source License (BSL). Leading infrastructure companies rally in response.
• August 2023: Work on the OpenTF fork (later renamed OpenTofu) begins, with the project finding a home at the Linux Foundation and a path to the Cloud Native Computing Foundation (CNCF). Scalr announces first-class support for OpenTF as a drop-in replacement for legacy Terraform, allowing teams to migrate at their own pace with OpenTF and Terraform workspaces coexisting side by side.
• January 2024: OpenTofu v1.6 launches as the first stable release, fully compatible with Terraform v1.5.x.
• April 2024: OpenTofu v1.7 ships with several long-requested features:
  • State Encryption: protects sensitive state files at rest with local passphrases and cloud integrations for key management systems such as AWS KMS, GCP KMS, and OpenBao.
  • Provider-defined Functions: lets providers ship custom functions (implemented in the provider plugin) that users can invoke directly from HCL, expanding what's possible beyond OpenTofu's built-in function set.
  • Loopable Imports: enables the use of for_each in import blocks, making bulk infrastructure imports much easier.
  • "Removed" blocks: make it easy to export infrastructure from tofu configs.
• Late 2024: OpenTofu v1.8 and v1.9 introduce early variable evaluation, provider iteration with for_each, and the resource exclusion flag.
• April 2025: The CNCF officially accepts OpenTofu, solidifying its position in the cloud-native ecosystem.
• 2025-2026: OpenTofu v1.10+ delivers OCI registry support for modules and providers, experimental OpenTelemetry tracing, and native S3 state locking without DynamoDB. As of June 2026 the current stable release is v1.12.2 (June 12, 2026).

OpenTofu vs Terraform: Key Differences

OpenTofu still runs Terraform configurations, but as the two projects drift apart, some real differences have shown up. This section covers the highlights; for a feature-by-feature comparison with a decision framework, see OpenTofu vs Terraform. For larger architectural patterns, see our take on the Terraform & OpenTofu Terralith and understanding Terraform & OpenTofu workspaces.

Licensing Model

OpenTofu: Uses the Mozilla Public License v2.0 (MPL v2.0), a true open-source license recognized by the Open Source Initiative. Users can freely use, modify, and distribute the software without ambiguity about competitive restrictions.

Terraform: Licensed under the Business Source License (BSL), a "source-available" license that prohibits using the software in ways that compete with HashiCorp's commercial offerings.

Governance and Development

OpenTofu: Community-driven development under Linux Foundation's neutral governance. Development priorities are set through transparent RFCs and community voting.

Terraform: Controlled by HashiCorp (now IBM), with development priorities set by commercial interests.

Innovative Features

OpenTofu has implemented several features long requested by the community but never added to Terraform:

File Extensions

OpenTofu supports both .tf and .tofu file extensions. When both exist with the same name, OpenTofu prioritizes the .tofu file, enabling module authors to provide OpenTofu-specific functionality while maintaining Terraform compatibility.

Migration Guide: From Terraform to OpenTofu

Moving from Terraform to OpenTofu is meant to be easy. In most cases it's just swapping one binary for another. For the syntax-level details on what's the same and what's diverged, see the OpenTofu Language Guide.

The hesitation usually outweighs the work. A pattern we see across Scalr demos and conference conversations: teams stay on Terraform 1.5.7 because the migration feels like a project that needs a strategy (do it in CI/CD only, or team by team?) while the actual technical change is small. The question that reframes the decision is which engine you want to validate against going forward: a frozen Terraform 1.5.7, or a maintained release line. Large enterprises still tend to run a multi-month risk analysis; engineering-led teams typically switch a pilot workspace the same week.

That choice is reflected in the tooling, too: Scalr supports Terraform only through its last MPL release, 1.5.7, and uses OpenTofu for anything newer, treating OpenTofu as the open-source continuation of Terraform. Within that open-source line, OpenTofu is increasingly the default for new work. On Scalr's platform it is now the majority engine, about 63% of runs and 72% of newly created workspaces as of mid-2026, and its share of new workspaces climbed from roughly 56% to 76% over the first half of 2026. (Scalr platform telemetry; the two engines are used by a similar number of accounts, so the majority is activity-weighted.)

Step-by-Step Migration

1. Verify Your Current State

Ensure your Terraform state is clean and there are no pending changes:

$ terraform plan
No changes. Your infrastructure matches the configuration.

If there are changes, apply them before proceeding.

2. Back Up Your State File

Always back up your terraform.tfstate file and any remote state before migration. This is critical and non-negotiable.

3. Install OpenTofu

Install the OpenTofu CLI on your machine:

$ brew install opentofu
$ tofu --version
OpenTofu v1.12.2

You can now use the tofu command as a drop-in replacement for terraform.

4. Initialize OpenTofu

Run tofu init -upgrade in your project directory. The -upgrade flag ensures there are no conflicts with pulling providers from the OpenTofu registry:

$ tofu init -upgrade
Initializing the backend...
Initializing provider plugins...

5. Plan and Apply with OpenTofu

Run tofu plan to ensure OpenTofu recognizes your existing infrastructure without planning unexpected changes:

$ tofu plan
No changes. Your infrastructure matches the configuration.

Once confident, run tofu apply to update the state file to the OpenTofu format:

$ tofu apply
No changes. Your infrastructure matches the configuration.
Apply complete!

Version Compatibility Considerations

Migrating from Terraform v1.5.x or lower: Migrate to OpenTofu v1.6.x first, then upgrade to the latest version. OpenTofu v1.6+ is fully compatible with Terraform v1.5.x.

Migrating from Terraform v1.6.x and newer: The migration is straightforward, but be aware of any new features or syntax introduced in later Terraform versions that may not yet be supported by OpenTofu.

Important Considerations

• Provider Sources: By default, OpenTofu uses registry.opentofu.org. If your configurations explicitly use registry.terraform.io, update them to use the OpenTofu registry.
• Execution Environment Versions: OpenTofu releases faster than Terraform did, and the surroundings have to keep pace. Through spring 2026, the most common OpenTofu tickets in Scalr's support queue were not about the engine itself: agent images needed upgrading before workspaces could adopt 1.12.x, version constraints set to "auto" resolved to unexpected releases, and older runner base images lacked the glibc that newer provider binaries expect. Before raising a workspace's OpenTofu version, upgrade the agents and runner images that execute it.
• Tooling and Integrations: Verify compatibility with third-party tools (CI/CD pipelines, linters, security scanners). Most tools supporting older Terraform versions work fine with OpenTofu.
• Module Compatibility: Confirm that any modules you rely on are compatible with OpenTofu.
• Testing: Perform small, non-critical changes first to ensure everything works before making major infrastructure updates.

Advanced OpenTofu Features

State File Encryption

One of OpenTofu's biggest additions is built-in state file encryption, which landed in version 1.7. It fixes a security worry that had been around in the infrastructure as code community for a long time. For broader state management context (backends, locking, sharing), see our Terraform & OpenTofu state backends guide.

Why State Encryption Matters

State files hold sensitive data: database passwords, API keys, private IPs. Remote backends like S3 give you some protection, but client-side encryption adds another layer of defense at rest.

Implementing State Encryption

OpenTofu supports multiple key provider options:

terraform {
  encryption {
    key_provider "pbkdf2" "mykey" {
      passphrase = "secure-passphrase"
      key_length = 32
      iterations = 600000
    }
    method "aes_gcm" "default" {
      key_provider = key_provider.pbkdf2.mykey
    }
    state {
      method = method.aes_gcm.default
    }
  }
}

You can also use AWS KMS, GCP KMS, or other external key management services for enterprise deployments.

One question that reaches Scalr support regularly (most recently April 2026): how does CLI-level encryption interact with platform-managed state? The encryption applies before state leaves the OpenTofu process, so a platform storing your state holds ciphertext it cannot read. That is the point of the feature, and it has a consequence: platform features that parse state, such as resource views and drift comparison against live infrastructure, stop working on encrypted workspaces. Decide which layer owns state protection before turning it on.

Dynamic Provider Configurations with for_each

Provider iteration using for_each (added in version 1.9) lets you configure providers dynamically, which cuts a lot of duplicated code in multi-region deployments.

Multi-Region Deployment Pattern

Instead of defining separate provider blocks for each region:

provider "aws" {
  alias    = "by_region"
  for_each = toset(var.regions)
  region   = each.key
}
 
resource "aws_instance" "servers" {
  for_each = {
    for region in var.regions : region => {
      instance_type = "t3.micro"
    }
  }
 
  provider      = aws.by_region[each.key]
  ami           = data.aws_ami.ubuntu[each.key].id
  instance_type = each.value.instance_type
 
  tags = {
    Name = "server-${each.key}"
  }
}

This pattern gets rid of the repetition and keeps your configurations easier to maintain.

Dynamic Backend Blocks

OpenTofu allows backend configurations to use variables and locals, enabling dynamic backend selection based on environment:

terraform {
  backend "s3" {
    bucket  = var.state_bucket
    key     = "${var.environment}/terraform.tfstate"
    region  = var.aws_region
    encrypt = true
  }
}

This enables a single configuration to support multiple deployment environments without code duplication.

Early Variable Evaluation

OpenTofu allows variables, locals, and data sources inside the top-level tofu block and for backend configurations, something Terraform traditionally restricts to static values. This enables powerful patterns:

locals {
  environment = var.env
  region      = var.aws_region
}
 
terraform {
  backend "s3" {
    bucket = "tf-state-${local.environment}"
    key    = "${local.region}/terraform.tfstate"
  }
}

The Native Test Framework

OpenTofu v1.10 introduced a native testing framework, eliminating the need for external test tools. The framework uses .tftest.hcl files:

run "validate_bucket_creation" {
  command = apply
 
  assert {
    condition     = aws_s3_bucket.main.id == "my-test-bucket"
    error_message = "S3 bucket name does not match expected value"
  }
}
 
run "validate_encryption_enabled" {
  command = apply
 
  assert {
    condition     = aws_s3_bucket_server_side_encryption_configuration.main.rules[0].apply_server_side_encryption_by_default[0].sse_algorithm == "AES256"
    error_message = "S3 bucket encryption is not enabled"
  }
}

The test framework supports:

• Multiple test runs with setup/teardown
• State assertions to validate resource creation
• Plan-time and apply-time validation
• Test variables and overrides

Resource Exclusion with the exclude Flag

The exclude flag (v1.9) enables selectively skipping resources during operations. This complements the target flag by providing inverse selection logic:

# Apply all resources except database
tofu apply -exclude 'aws_db_instance.prod'
 
# Exclude multiple resources
tofu apply \
  -exclude 'aws_db_instance.prod' \
  -exclude 'aws_rds_cluster.analytics'

Use Cases for Exclusion

• Gradual rollouts: Apply changes to non-critical resources first
• Maintenance windows: Skip resources undergoing maintenance
• Manual management: Exclude resources managed outside IaC
• Risk mitigation: Apply low-risk changes while deferring high-risk ones

What Do You Do When tofu apply Fails?

The same things you'd do with Terraform: read the error class first (provider auth, state lock, dependency ordering, a resource changed outside IaC), turn on TF_LOG=DEBUG when the message isn't enough, and reach for tofu force-unlock only after you've confirmed nothing else holds the lock. The worked failure catalogue is in debugging OpenTofu apply failures. Editor support is unchanged too: terraform-ls and the HashiCorp VS Code extension work with .tf and .tofu files.

Provider Ecosystem

OpenTofu stays fully compatible with existing Terraform providers, so you get thousands of infrastructure providers without changing a thing.

Provider Declaration

Providers are declared in the required_providers block:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.0"
    }
  }
}

OpenTofu Registry

The OpenTofu Registry at registry.opentofu.org mirrors and extends the Terraform provider ecosystem. All major providers are available, including AWS, Azure, GCP, and Kubernetes, and as of June 2026 the ecosystem counts 3,900+ providers and 23,600+ modules (per opentofu.org).

Community Providers

Being open source, OpenTofu also supports community-maintained providers and modules, so you're not limited to the HashiCorp provider ecosystem.

Frequently Asked Questions

How can I install OpenTofu?

You can install OpenTofu by visiting the Installing OpenTofu page on the main OpenTofu site. Most users start with Homebrew on macOS (brew install opentofu), but packages are available for all operating systems. You can also test OpenTofu directly in Scalr, where you can select between Terraform and OpenTofu for any workspace.

What are the OpenTofu commands?

At this time, there is no difference between the Terraform and OpenTofu commands other than calling tofu rather than terraform. The primary workflow commands remain the same: tofu init (prepare working directory), tofu plan (show changes required), tofu apply (create or update infrastructure), and tofu destroy (destroy infrastructure).

Does OpenTofu need to fork the HashiCorp providers?

No. OpenTofu is compatible with all Terraform providers. There is a single provider format that both projects support. As a provider maintainer or author, you do not need to make any changes to your project, nor add additional tests. In the rare event that a provider works for Terraform but not for OpenTofu, the community addresses the issue promptly.

Can OpenTofu compatibility with Terraform be guaranteed long term?

The OpenTofu community is committed to ensuring support for all Terraform providers short, mid, and long term. The Linux Foundation provides a strong framework for long-term project success, including the Technical Steering Committee and a requirement that projects have maintainers from many organizations to provide redundancy. There are already several dozen contributors, ensuring the project moves forward steadily.

Why is it called OpenTofu?

The name was chosen to be easy to remember, short to type (just tofu in the CLI), and unique enough to be easily searchable. It was important to avoid confusion with Terraform in the market, which is why the original name "OpenTF" was changed at the advice of legal teams.

How can I contribute?

The community is encouraged to contribute by opening pull requests, reporting bugs, testing fixes, and participating in discussions in the public GitHub repository. You can also join the Slack community where core team members collaborate with the general community. The project is governed by a Technical Steering Committee that publishes meeting minutes publicly.

Alternatives to Terraform Cloud

The question arrives in roughly the same words every time: "OpenTofu is on my laptop, so how do we take it to production with a team of five?" Local state and laptop applies stop working the moment a second engineer runs a plan. And with HCP Terraform's free tier discontinued as of March 31, 2026, most OpenTofu teams looking for shared runs, state management, and access control land on one of the platforms below. Our guide to selecting a Terraform Cloud alternative walks through how to weigh these options against your team's needs. If you are still working out what that layer has to cover in the first place, start with what an OpenTofu management platform actually does.

Commercial Platforms

Scalr: Offers comprehensive OpenTofu support with OPA integration, RBAC, custom hooks, and state management.

env0: Provides native OpenTofu support with advanced RBAC, secrets management, and policy enforcement. Founded by one of the original OpenTofu initiative members.

Spacelift: Delivers enterprise-grade features including multi-IaC workflows, Policy as Code, and self-service infrastructure through Blueprints.

A practical note when comparing these commercial options: some alternatives use concurrency-based pricing, where you pay for a fixed number of parallel run slots regardless of whether they're used. That model tends to fail hardest exactly when you need it most: during an incident you're pushing many parallel fixes across workspaces and your slot cap throttles recovery. Scalr uses usage-based, per-run pricing instead, free up to 50 runs a month, with no charges for users, workspaces, or resources under management, so there's no slot to mis-provision.

Self-Hosted Options

For teams preferring self-hosted solutions:

• Terrakube: An open-source alternative to Terraform Enterprise
• Terralist: Registry for OpenTofu modules and providers
• Atlantis: Pull request automation for infrastructure changes

How Should You Run OpenTofu in Production?

Turn on state encryption (it's the one feature you can't get from Terraform's CLI), keep state in a remote backend with locking, and put every change through a pull request with a plan attached. Use tofu test for modules, -exclude when a resource is mid-maintenance, and keep variables in .tfvars files rather than environment soup. None of that is OpenTofu-specific advice except the first item, so the detailed guides are shared: Terraform state file best practices, the Terraform and OpenTofu testing guide, the tfvars guide, and 10 OpenTofu commands for the CLI reference.

Where OpenTofu stands today

OpenTofu has become a working alternative to Terraform for most teams. It keeps compatibility with the existing Terraform ecosystem while adding features the open-source Terraform CLI lacks: state encryption, provider iteration, and a native test framework. The MPL 2.0 license removes the licensing ambiguity that pushed many teams off Terraform in the first place, and development priorities are set through public RFCs and community voting rather than by a single vendor.

If you're a Terraform user weighing the move, the practical question is which engine you want to validate against going forward: a frozen Terraform 1.5.7, or a maintained release line under Linux Foundation and CNCF governance. The migration itself is usually a binary swap, as the step-by-step guide above shows, so most teams can pilot it on a single workspace within a week.