OpenTofu: Open-Source Infrastructure as Code

OpenTofu is an infrastructure as code tool. Engineers describe the infrastructure they want, such as networks, clusters, databases, DNS records and IAM roles, in declarative HashiCorp Configuration Language (HCL), and OpenTofu compares that description with recorded state, shows a plan, and calls provider plugins to create, change or destroy resources through cloud and platform APIs. It addresses repeatability and review: infrastructure becomes versioned code with a visible diff before every change, instead of console clicks that cannot be audited or reproduced. OpenTofu began in August 2023 as a community fork of Terraform, created after HashiCorp changed Terraform’s license from MPL 2.0 to the Business Source License. It was first named OpenTF, renamed OpenTofu in September 2023, adopted by the Linux Foundation, and uses MPL 2.0. The project joined the CNCF as a Sandbox project in April 2025, with the CNCF Governing Board granting an intellectual property exception because CNCF projects normally use Apache 2.0. The 1.12 release line is current.

CNCF daily · Sprint 1, day 6 · Automation & Configuration

At a glance

Category	Automation & Configuration
CNCF status	Sandbox. Accepted April 2025
Written in	Go
License	MPL 2.0 (CNCF exception to the usual Apache 2.0 rule)
Language	HCL, compatible with existing Terraform configurations and providers
Core workflow	init, plan, apply, destroy, plus test for configuration tests
Distinct features	Client-side state and plan encryption, ephemeral resources and write-only attributes (1.11), enabled meta-argument (1.11)
Governance	Linux Foundation project with a steering committee that includes env zero, Gruntwork, Harness, Spacelift and Scalr
Release line	1.12 (patch releases through mid-2026); 1.11 released December 9, 2025

Architecture

flowchart TB
  DEV[Engineer or CI pipeline] -->|tofu plan and apply| CORE
  subgraph TOFU[OpenTofu CLI]
    CORE[Core<br/>parse HCL, build graph, diff] --> PLAN[Plan<br/>proposed changes]
    CORE --> ENC[State encryption<br/>client side]
  end
  CORE -->|gRPC| PROV[Provider plugins<br/>AWS, GCP, Azure, Kubernetes]
  PROV -->|API calls| CLOUD[Cloud and platform APIs]
  CORE --> MOD[Modules<br/>local, Git, registry]
  ENC --> BACKEND[Remote backend<br/>S3 with locking, GCS, Azure Blob]
  KMS[Key provider<br/>KMS, passphrase, OpenBao] --> ENC
  REG[OpenTofu registry<br/>providers and modules] --> PROV
  PLAN --> REVIEW[Pull request review<br/>plan output]

Component	Responsibility
Core	Parses HCL, builds the dependency graph of resources, compares desired and recorded state and produces a plan.
Providers	Plugins that translate resource blocks into API calls for a platform. The same provider model as Terraform lets existing providers be reused.
State	A record that maps configuration to real resources. It can hold sensitive values, so where and how it is stored matters.
Backend	Remote storage and locking for state, such as S3, GCS or Azure Blob, so a team shares one source of truth.
State encryption	An OpenTofu feature that encrypts state and plan files on the client before they reach the backend, using a configured key provider.
Modules	Reusable packages of configuration, taken from local paths, Git or a registry.
Registry	The public source for providers and modules, which tofu init downloads and verifies.

Design principle. OpenTofu separates desired state, written in HCL and reviewed in Git, from the engine that reconciles it and the providers that talk to each platform. A saved plan is an explicit, reviewable contract between a proposed change and the apply that follows, and state is treated as sensitive data that deserves encryption and locking.

Production reference design

A common pattern on AWS, GCP or Azure for platform and application teams, with pull request review as the control point:

1. Install and pin versions. Install OpenTofu in CI and on engineer machines, and pin the required version and providers so runs are reproducible:

   terraform {
     required_version = "~> 1.12"
     required_providers {
       aws = { source = "hashicorp/aws", version = "~> 6.0" }
     }
   }

   OpenTofu reads the terraform block for compatibility. Check provider versions and sources against the registry for your setup.
2. Create a remote backend with locking. Keep state in an object store with versioning, and restrict access with IAM. An S3 example:

   terraform {
     backend "s3" {
       bucket       = "example-tofu-state"
       key          = "platform/network.tfstate"
       region       = "ap-south-1"
       use_lockfile = true
     }
   }

   Check the backend options for the version you run, since locking arguments have changed over time.
3. Encrypt state on the client. Configure a key provider, such as a cloud KMS key, so state and plan files are encrypted before storage:

   terraform {
     encryption {
       key_provider "aws_kms" "main" {
         kms_key_id = "alias/tofu-state"
         region     = "ap-south-1"
         key_spec   = "AES_256"
       }
       method "aes_gcm" "default" { keys = key_provider.aws_kms.main }
       state { method = method.aes_gcm.default }
       plan  { method = method.aes_gcm.default }
     }
   }

   Confirm the block names and arguments against the documentation for your version, and test decryption and key rotation before relying on it.
4. Structure the code as modules with one root configuration per environment or stack, so the blast radius of a change stays small.
5. Run the workflow in CI. On a pull request, run format, validate and plan, and post the plan for review. After merge, apply the saved plan from a pipeline identity that uses short-lived cloud credentials:

   tofu fmt -check
   tofu init
   tofu validate
   tofu plan -out=tfplan
   tofu apply tfplan

6. Keep secrets out of state where possible. Use ephemeral resources and write-only attributes, available from 1.11, to supply temporary credentials or one-time passwords without saving them.
7. Add policy and tests. Use tofu test for module behaviour and an external policy tool, such as OPA or Checkov, to block unsafe changes before apply. Detect drift with scheduled plans.

Typical production uses include landing zones and VPC networks, managed Kubernetes clusters, databases and queues, IAM and identity setup, DNS and certificates, and the cloud infrastructure that a platform such as Kubernetes then runs on.

Operational considerations

• Protect state. State maps your code to real resources and can contain secrets. Use a remote backend with locking and versioning, restrict access, and enable client-side encryption.
• Review plans, then apply the reviewed plan. Applying a saved plan avoids differences between what was reviewed and what runs. Treat destroy and replace actions in a plan as items that need explicit attention.
• Control the blast radius. Split state by environment and domain rather than one large configuration, and use targeted imports and moves for refactoring rather than editing state by hand.
• Manage compatibility. OpenTofu aims for compatibility with Terraform configurations and providers, but the tools are diverging in features. Check the migration guide before switching a team, and avoid switching tools back and forth on one state.
• Pin and update deliberately. Pin provider and OpenTofu versions, read release notes for each minor version, and update through the same plan and review process as any other change.
• Handle credentials safely. Prefer short-lived credentials from workload identity in CI, never commit secrets in variable files, and limit which pipelines can apply to production.

Adoption

• The project’s steering committee includes env zero, Gruntwork, Harness, Spacelift and Scalr, which also offer OpenTofu support in their commercial platforms.
• The Linux Foundation hosts the project, and the CNCF Governing Board approved its license exception when it joined the CNCF.
• As a Sandbox project, OpenTofu does not publish a list of named production adopters on its CNCF page. Teams that already use Terraform configurations form most of its user base, since the migration path is deliberately short.

Alternatives

Solution	Model	Best suited to
Terraform	The original tool, under the Business Source License	Teams on HashiCorp or IBM commercial products and support
Pulumi	Infrastructure as code in general-purpose languages	Teams that want TypeScript, Python or Go instead of HCL
Crossplane	Kubernetes-native control plane for cloud resources	Platform teams that want infrastructure managed as Kubernetes resources
AWS CloudFormation, Azure Bicep, Google Config Connector	Provider-native templates	Single-cloud estates that want first-party tooling
Ansible	Procedural automation and configuration management	Configuring machines and applications, often together with OpenTofu for provisioning

Strengths and limitations

Strengths	Limitations
Open governance and an open-source license, hosted by the Linux Foundation and the CNCF	Sandbox maturity, with less public adoption evidence than older CNCF projects
Large provider ecosystem and a short migration path from Terraform	Feature differences from Terraform will grow over time
Client-side state and plan encryption built in	State management, locking and drift remain the team’s responsibility
Declarative plans that can be reviewed before apply	HCL is less flexible than a general-purpose language for complex logic
Familiar workflow for engineers who know Terraform	Provider quality and coverage depend on third-party maintainers

Recommendation

Adopt OpenTofu for new infrastructure as code projects where an open-source license and open governance matter, and assess it for existing Terraform estates by migrating a low-risk stack first. Use a remote backend with locking, turn on state encryption, apply reviewed plans from CI with short-lived credentials, and pin versions. Pulumi or Crossplane are better fits when a team prefers general-purpose languages or wants infrastructure managed inside Kubernetes.

References: CNCF project page · The New Stack: OpenTofu joins the CNCF · OpenTofu 1.11.0 release post · OpenTofu documentation · OpenTofu on Wikipedia · OpenTofu on GitHub