Download and Installation​

Download the appropriate package for your platform:

We also provide packages for some other platforms on a best-effort basis. For more information, refer to the full set of release packages.

After downloading, extract the archive to find the tofu executable.

What's New in OpenTofu 1.12​

The following sections describe some highlights of this release. For the full set of changes in this release, refer to the OpenTofu v1.12 changelog.

prevent_destroy can now be set dynamically​

The prevent_destroy argument for managed resources can now refer to input variables and other dynamic symbols, so for example you can write a module that refuses deletion of an important object by default but allow the caller to override that in development environments:

variable "prevent_destroy_database" {
  type    = bool
  default = true
}

resource "example_database" "example" {
  # ...

  lifecycle {
    prevent_destroy = var.prevent_destroy_database
  }
}

A caller of the above module could explicitly set prevent_destroy_database = false to allow tofu destroy to work, but this would still cause an error by default to reduce the risk of mistakes.

Import using "Resource Identity"​

The latest versions of the provider plugin protocol introduce a new concept called "resource identity", which allows each resource type to have a schema for just a small amount of metadata that uniquely identifies an object in the remote system, as opposed to the main state data that includes all of the attributes you can normally interact with in OpenTofu modules.

OpenTofu v1.12 introduces our first major use of that new feature: import using resource identity. Traditionally the tofu import command and import blocks required identifying the object to import with just a single string assigned to the id argument, which is okay for simple cases where the remote object has a single string as its unique identifier but is challenging for resource types where the identifier is some sort of compound key, where previously each resource type needed its own special syntax for how to identify a remote object.

import blocks now support a new identity argument which module authors would use instead of id argument to describe what to import using an object that matches the resource type's resource identity schema.

For example, aws_ssm_maintenance_window_target from the hashicorp/aws provider has a resource identity schema that requires both id and window_id attributes to be specified, and so now you can write an import block like this:

import {
  to = aws_ssm_maintenence_window_target.example
  identity = {
    window_id = "mw-EXAMPLE"
    id        = "20591c06-c386-41ac-928c-5cc32dd43cd9"
  }
}

For the simpler resource types whose import id format was previously just a simple identifier, their identity schema usually just includes a single required attribute whose name describes what kind of identifier is required. For example, in the hashicorp/aws provider it's common to use an arn attribute whose value is the fully-qualified ARN for the object.

A provider decides what schema to use for each of its resource types. To find out whether a resource type has been updated to support import by resource identity, and which attributes to use if so, refer to the documentation for the resource type you are interested in using the OpenTofu Registry. Most resource types continue to support the original style of import with just a single id string too, but that is technically optional and so over time providers may stop offering that for new resource types.

Provider Installation Improvements​

OpenTofu Registry now returns a full set of checksums when you install a provider, so that the dependency lock file will immediately have enough information to verify packages on all of the platforms the provider supports.

Although previous versions of OpenTofu were able to produce a working dependency lock file when using the default provider installation settings, many of the available customizations of the installation process caused problems related to checksums:

• The checksums returned by the registry could not be used to verify packages in the optional global cache directory, so that cache was often ineffective at preventing OpenTofu from redownloading packages from the origin registry.

• The checksums returned by the registry could also not verify packages from local filesystem mirror directories or other alternative installation methods, which caused tofu init to fail when run on a platform other than the one that initially populated the lock file, unless teams remembered to explicitly run tofu providers lock to force adding additional checksums to the lock file.

• Even with the default settings, running tofu init on a different platform than where it was initially run would cause an additional checksum to be added to the lock file, which is confusing for anyone reviewing changes to the configuration and is particularly problematic for those who use tofu init -lockfile=readonly in their pipeline to ensure that only previously-reviewed providers can be selected.

To avoid these problems, the registry now returns checksums that are suitable for verifying both local and remote provider packages, and tofu init will add them all to the dependency lock file immediately if the downloaded package matches the reported checksums for the current platform.

In particular, most teams should no longer need to use tofu providers lock at all. We've retained it only for its originally-intended purpose: populating the lock file with correct checksums from the origin registry on a system where tofu init is configured to use an alternative installation source. As long as your CLI configuration allows tofu init to install packages directly from from OpenTofu Registry (which is the default), it will record the full set of checksums automatically.

The first time you run tofu init after upgrading, you are likely to find additional entries were added to the hashes argument in your dependency lock file, all of which should use the h1: prefix. This is the hashing scheme that previous versions of OpenTofu could only calculate locally, but OpenTofu v1.12 can now prepopulate all of these hashes at once on first install, in addition to the zh: hashes that were already included by previous versions of OpenTofu. If you already had a lock file entry for a provider that was populated from the registry by a previous version of OpenTofu then it should already have its full set of zh: checksums and so no new items should be added with that prefix.

Alongside the checksum-related changes, we've also made some performance improvements that should allow tofu init to complete faster for those who are installing many small providers.

Simultaneous Human-readable and Machine-readable Command Output​

Various OpenTofu commands allow specifying a -json option on the command line to select machine-readable output in JSON format, instead of the normal human-oriented output. However, in previous versions these two modes were mutually-exclusive: requesting machine-readable output disabled the human-oriented output.

OpenTofu v1.12 introduces the alternative -json-into=FILE option, which leaves the human-oriented output enabled on the "stdout" and "stderr" handles but also writes the machine-readable output to the specified file. We expect this would be useful for those running OpenTofu in pipelines where the human-facing output should appear in the main job output for operators to read, but the pipeline also needs access to some or all of that information for automation purposes. The specified path can either refer to a regular file or to a special object like a named pipe or "FIFO", in case your automation needs to react to streaming events concurrently while OpenTofu is still running.

We've also introduced the -json and -json-into=FILE options to many more commands in this release. For most of these the JSON output is currently just human-oriented messages wrapped up in JSON objects, but we're interested in extending these JSON objects with useful data based on your use-cases. If there's some specific automation or an alternative UI you'd like to build that would benefit from machine-readable information about what OpenTofu is working on, please open a feature request issue on GitHub and we'll consider it for a future release.

Join the Testing Effort​

Your testing and feedback are crucial to ensuring that these new capabilities work correctly across different environments and use cases.

If you have a non-production environment where you could test any of the new features or bugfixes then we'd appreciate your help. Even if everything works as you expected, please share your testing experiences or join the conversation in #opentofu in the CNCF Slack workspace.

Thank you for supporting the OpenTofu project!

Background​

Many of OpenTofu's long running commands support the -json flag. This flag switches the output mode from human readable colorized logs into a documented json format. The main downside of using the -json argument is that it completely disables the human readable output. Existing tooling on top of OpenTofu therefore had two options, both with their own drawbacks.

On one hand, you could attempt to parse the human readable output and work based on that fuzzy parsing. This would allow you to keep the exact output that the user is used to relying on and manipulating it as you see fit. The main downsides being an output that changes between versions and a complex and error prone text parser.

On the other hand, you could work exclusively with the machine readable output. This is a stable and versioned interface that can be relied upon and is easy to parse. The main downside is that users may miss or expect you to re-create portions of the human readable output (a non-trivial task).

With the new -json-into flag, stdout and stderr remain the same output that users have come to expect, while at the same time streaming the machine readable logs into whatever file or pipe you specify.

Examples​

Simple output capture​

To start off, let's capture the output from tofu plan using the new flag. We can then process the output (in this case with jq) to produce our own summary.

$ tofu plan -json-into=plan.json -out planfile
...

  # random_password.password[99] will be created
  + resource "random_password" "password" {
      + bcrypt_hash = (sensitive value)
      + id          = (known after apply)
      + length      = 16
      + lower       = true
      + min_lower   = 0
      + min_numeric = 0
      + min_special = 0
      + min_upper   = 0
      + number      = true
      + numeric     = true
      + result      = (sensitive value)
      + special     = true
      + upper       = true
    }

Plan: 200 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Saved the plan to: planfile

To perform exactly these actions, run the following command to apply:
    tofu apply "planfile"


$ cat plan.json  | jq -r 'select(.type=="planned_change") | "Planned Change: \(.change.action) \(.change.resource.addr)"'
...
Planned Change: create random_password.password[95]
Planned Change: create random_password.password[96]
Planned Change: create random_password.password[97]
Planned Change: create random_password.password[98]
Planned Change: create random_password.password[99]

As you can see, the user still sees the output that they are familiar with, while producing a machine readable artefact which can be further processed.

Streamed output capture​

For a slightly more fun example, we can use pipeform to demonstrate some of the more advanced capabilities that this new flag offers.

Downloading the nightly builds​

The nightly builds are available exclusively from the OpenTofu Nightly Repository. Please choose the select the appropriate file for your platform.

Ephemeral resources and write-only attributes​

Ephemeral values allow OpenTofu to work with data and resources that exist only in memory during a single OpenTofu phase, guaranteeing that those values will not be persisted in state snapshots or plan files:

• Use ephemeral resources to request temporary access to stored credentials or network tunnels for use in provider or provisioner configurations, without the resulting values being saved in OpenTofu plan files or state snapshots.

  For example, you could use an ephemeral resource to request time-limited AWS credentials from OpenBao and provide them to the hashicorp/aws provider, or to open a temporary SSH tunnel so that the cyrilgdn/postgresql provider can access a Postgres server on a remote network.

• Use write-only attributes to set resource arguments that OpenTofu needs access to only when they are changing, such as the initial administrator password for a database.

  For example, you could use an ephemeral resource to generate an SSH keypair and then save the private key in your secret store using a write-only attribute so that OpenTofu itself will not need to retain its own copy of the key material.

For more information on these and other related OpenTofu language features, refer to Ephemerality.

enabled for resources and modules​

OpenTofu has traditionally allowed a module to dynamically enable or disable a particular module by using the count meta-argument to choose between either zero or one instances of the object.

OpenTofu v1.11.0 introduces the enabled meta-argument, which we hope will make it easier for readers to understand that only zero or one instances of a resource are possible:

variable "subnet" {
  type = object({
    id = string
  })
  default = null
}

variable "enable_cluster" {
  type    = bool
  default = false
}

resource "aws_subnet" "example" {
  # ...

  lifecycle {
    enabled = var.subnet == null
  }
}

resource "aws_instance" "example" {
  # ...
  subnet_id = var.subnet != null ? var.subnet.id : aws_subnet.example.id
  # ...
}

module "servers" {
  source = "./app-cluster"
  servers = 5
  lifecycle {
    enabled = var.enable_cluster
  }
}

For more information, refer to The enabled meta-argument.

Various other improvements​

There are numerous other improvements in OpenTofu v1.11. For more information, refer to What's new in version v1.11, or to the OpenTofu v1.11.0 release notes.

Download and Install​

You can download OpenTofu v1.11.0 directly from our GitHub releases page, install it using your preferred package manager, or use our official Docker images.

View our installation guides

We're excited to announce the beta release of OpenTofu 1.11.0! This release brings two highly anticipated features to beta: Ephemeral Resources for handling confidential data without persisting it to state, and the enabled meta-argument for conditional resource provisioning.

If you've been following along, you may have seen our announcement about ephemeral support when these features became available in nightly builds. This beta release marks the first official preview of these capabilities, along with stabilized module deprecation features and important performance improvements.

Download and Installation​

The beta release is available from the GitHub Releases page. Select the appropriate file for your platform:

After downloading, unpack the archive to find your tofu binary. For verified downloads, you can also use the standalone installer with signature verification.

What's New in 1.11.0-beta1​

Ephemeral Resources / Write-Only Attributes - Beta Release​

Ephemeral resources allow you to work with confidential data, temporary credentials, and transient infrastructure without persisting them to your state.

A long-standing challenge with infrastructure-as-code has been the storage of confidential data within state. This includes passwords, API keys, certificates, and other secrets that could lead to security incidents if leaked. Ephemeral resources solve this problem by ensuring these values only exist during the execution of a single OpenTofu command.

Key Benefits​

• Enhanced Security: Confidential values never touch your state files
• Transient Resources: Create temporary network tunnels, SSH proxies, or time-limited credentials
• Cleaner State Management: Reduce the amount of confidential data requiring encryption and protection

How It Works​

Ephemeral resources are opened at the beginning of an OpenTofu operation, used during execution, and closed when no longer needed. No ephemeral values are ever stored in your state.

Here's a simple example that also uses write-only attributes; These allow you to pass ephemeral data into regular resources without storing that information in your state:

# Use AWS SecretsManager to generate a random password
ephemeral "aws_secretsmanager_random_password" "password" {

}

resource "kubernetes_secret_v1" "credentials" {
  metadata {
    name = "admin"
    namespace = "my-app"
  }
  data_wo = {
    username = "admin"
    password = ephemeral.aws_secretsmanager_random_password.password.random_password
  }

  data_wo_revision = 1
  type = "kubernetes.io/basic-auth"
}

In this case, we're using the aws_secretsmanager_random_password ephemeral resource to generate a random password and store it in a kubernetes secret.

The value of this password will never be stored in the plan or the state by OpenTofu. Because OpenTofu does not store the value in the state the resource will only update it's password value when the revision number is incremented.

You can find more in our documentation for Ephemerality and Write-Only Attributes

The enabled Meta-Argument​

The new enabled meta-argument provides a cleaner alternative to count and for_each for scenarios where you need to conditionally create a single resource or module instance. This addresses one of the most common patterns in infrastructure code: "create this resource only if a certain condition is true."

Why enabled?​

Previously, you'd use count = var.create_instance ? 1 : 0, which works but has downsides:

• Creates arrays even for single resources (requiring [0] indexing)
• Less readable and intuitive than a simple boolean flag
• Can be confusing for module consumers

The enabled meta-argument solves this elegantly:

resource "aws_instance" "web" {
  ami           = "ami-12345"
  instance_type = "t3.micro"

  lifecycle {
    enabled = var.create_instance  # Simple boolean condition
  }
}

Module Example​

This is especially useful in modules where you want to make resources optional:

variable "create_cluster" {
  type    = bool
  default = true
}

module "servers" {
  source = "./app-cluster"

  servers = 5

  lifecycle {
    enabled = var.create_cluster # Can make whole modules optional
  }
}

Nested in Lifecycle Block​

The enabled argument is nested inside the lifecycle block rather than at the resource level. This design choice prevents conflicts with existing input variables or resource arguments that might already be named enabled.

For more information, refer to the enabled meta-argument documentation here.

Additional Features and Improvements​

Module Variable and Output Deprecation - Now Stable​

The ability to mark module variables and outputs as deprecated, which was experimental in OpenTofu 1.10, is now stable! Module authors can guide users away from legacy interfaces while maintaining backward compatibility.

Mark variables as deprecated:

variable "legacy_input" {
  type       = string
  default    = "default-value"
  deprecated = "This variable is deprecated. Please use 'new_input' instead. This will be removed in v2.0 of this module."
}

Mark outputs as deprecated:

output "old_endpoint" {
  value      = aws_instance.main.public_ip
  deprecated = "This output is deprecated. Use 'instance_endpoint' instead. This will be removed in v2.0 of this module."
}

Users will see clear warnings when using deprecated variables or outputs, helping them prepare for future module updates.

For more information, see marking variable as deprecated and marking output as deprecated

Performance Improvements​

This release includes significant performance optimizations for large-scale deployments:

• Improved RAM and CPU efficiency for configurations that contain thousands of resource instances
• Improved handling of complex dependency graphs
• Optimized memory usage during plan and apply operations

Enhanced S3 Backend​

The S3 backend now supports object tagging your backend, allowing you to add custom tags to your state files for better organization and cost tracking:

terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "production/terraform.tfstate"
    region = "us-east-1"

    state_tags = {
      Environment = "production"
      Team        = "platform"
    }

    lock_tags = {
      Environment = "production"
      Team        = "platform"
    }
  }
}

Feedback Request: Experimental Encryption Features​

OpenTofu introduced experimental support for external encryption methods and key providers in previous releases. These features allow you to integrate with external key management systems and custom encryption workflows.

We need your feedback! We're planning to stabilize these features and would love to hear about your experiences:

• Are the external method and external key_provider meeting your needs?
• What use cases are you solving with these features?
• What improvements would make them more useful?
• Are there any issues or limitations you've encountered?

If you're using or considering using state encryption with external key management, please share your feedback through this GitHub Discussion

Your input will directly influence whether these features move to stable in OpenTofu 1.12 or need more development time.

Compatibility Notes​

Before upgrading, please note these important compatibility points and breaking changes:

System Requirements​

• macOS: OpenTofu on macOS now requires macOS 12 Monterey or later

Breaking Changes​

• Azure Backend (azurerm):

  • The endpoint and ARM_ENDPOINT configuration options are no longer supported
  • The msi_endpoint and ARM_MSI_ENDPOINT options are no longer supported
  • The environment and metadata_host arguments are now mutually exclusive

• issensitive() Function: Now correctly returns unknown results when evaluating unknown values. Code that previously relied on the incorrect behavior may need updates.

• Testing with Mocks: Mock values generated during testing now strictly adhere to provider schemas. Test configurations with invalid mock values will need to be corrected.

• S3 Module Installation: When installing module packages from Amazon S3 buckets using S3 source addresses OpenTofu will use the same credentials as the AWS CLI and SDK.

• TLS and SSH Security:

  • SHA-1 signatures are no longer accepted for TLS or SSH connections
  • SSH certificates must comply with the draft-miller-ssh-cert-03 specification

For complete details, review the full changelog.

Join the Testing Effort​

Your testing and feedback are crucial to ensuring that these new capabilities work flawlessly across different environments and use cases. We're especially interested in feedback on:

• Ephemeral resources: Does the security model work for your use cases? Are there providers or scenarios where you'd like to see support?
• The enabled meta-argument: Is this pattern more intuitive than count? Are there edge cases we should consider?
• Encryption features: Are the experimental external encryption features ready for stabilization?

If you have a non-production environment where you could test any of these capabilities, we'd appreciate your help. Even if everything works perfectly, please share your testing experiences through this GitHub Discussion or join the conversation in the #opentofu channel in the CNCF slack workspace.

Thank you for your continued support of the OpenTofu project!

One of the most common questions I get — whether on forums, in Slack, or at events — is: “How are large enterprises actually using OpenTofu?” At a recent OpenTofu Day, we had a concrete, candid answer.

David Jackson, VP of Cloud Automation and Tooling at Fidelity Investments, took the stage to share how one of the world’s largest financial services companies navigated a full-scale migration from Terraform to OpenTofu. The session sparked instant interest for its transparency, practicality, and relevance to real-world teams managing complex infrastructure.

I followed up with David to explore his OpenTofu experience in greater detail. If you're exploring OpenTofu for your organization, I hope you will find this conversation essential reading.

Q: David, let’s start with scale. How big is the footprint of Terraform and OpenTofu at Fidelity today?

A: It’s big. We’ve got over 2,000 applications using Terraform or OpenTofu, managing more than 50,000 state files and north of four million individual cloud resources. On any given day, we’re seeing upwards of 4,000 state file updates. That kind of volume shapes everything—how we evaluate tools, how we design pipelines, how we think about governance. When we started looking at OpenTofu, we knew we weren’t talking about a few isolated teams. This was going to impact hundreds, if not thousands, of engineers.

Q: What triggered the move from Terraform to OpenTofu?

A: Fidelity has been doubling down on open source for years, and when the licensing changes around Terraform came through, it prompted a broader conversation internally. We looked at OpenTofu and saw a project that was committed to open governance and community contribution. That was important to us. We don’t just consume open source—we contribute to it. OpenTofu aligns with our values and our platform engineering strategy. We also felt it was a technical drop-in, and that made it viable.

Q: What were the first steps in actually making that shift?

A: We started with a POC, obviously. You’ve got to prove to yourself that OpenTofu is truly a drop-in. And not just in terms of provisioning a resource or two. We pushed all the way through to production. We picked one of our own internal IaC platform applications and ran the entire pipeline—CI/CD, artifact storage, governance, everything—just as we would for any production deployment. That gave us confidence.

Q: You mentioned during the talk that you didn’t stop at proving it worked—you socialized it internally. Can you say more about that?

A: Socialization was key. In a company our size, nothing moves without consensus. We talked with the right governance groups—our DevOps council, the platform engineering guild, and other decision-making bodies. We laid out the pros and cons. We were honest. And we asked for input early. That helped build trust. Once we had alignment, we moved into enablement: building support tools, documentation, FAQs, internal support channels. We tested everything again with the lighthouse project and made it available for wider adoption.

Q: How did you go from a few early adopters to 70% adoption before making the CLI switch?

A: A few things worked really well for us. First, we targeted the biggest users of Terraform—teams with hundreds of state files and thousands of resources. We got them on board early, worked side-by-side on migrations, and once they saw success, that sent a strong signal to the rest of the organization. We also tracked adoption closely and shared that data transparently. It gave people confidence. No one wants to be the first to jump—but once they see momentum, they don’t want to be last either.

Q: Did you run into any real resistance along the way?

A: Honestly, not much. That surprised us a bit. There were some questions around compatibility and support, of course. But because we had done the homework and proved everything in production early on, we had answers ready. Also, we did an internal branding push. We packaged our tooling under a code name—Bento—and branded the migration effort that way. It gave it an identity and made it easier to talk about in internal forums.

Q: What role did shared infrastructure or tooling play in the migration?

A: A huge one. We’ve got a centralized catalog of reusable modules—hosted in Backstage—with maturity ratings and usage stats. Teams can see what’s battle-tested. That saves a ton of time and prevents drift. We also have shared CI/CD pipelines that we manage centrally. That meant when we updated those pipelines to use the OpenTofu CLI, every project using them automatically migrated. It’s a force multiplier. We’re really trying to make it easy for teams to do the right thing.

Q: Now that OpenTofu is the default, what’s next?

A: We’ve flipped the default, yes. All new deployments use OpenTofu unless teams explicitly opt out. That’s allowed us to consolidate usage. Now we’re starting to deprecate the older Terraform versions. We have governance checks in place during deployments, so we can enforce that gradually. Eventually, we’ll have a single-track system using just OpenTofu. That’s cleaner for support and security.

Q: Looking back, what are your top lessons learned?

A: One, the code itself isn’t the hard part. Changing the CLI in a pipeline is trivial. The complexity lives in the surrounding ecosystem—versioning, CI/CD, governance, artifact management. That’s where you need maturity. Two, if you’ve got shared pipelines and modules, you’re going to have a smoother path. And three, data matters. If you can track adoption and share that data internally, it builds trust and drives momentum. That’s how we got the bulk of the org moved over before the cutover date.

Q: Anything you’d say to orgs still hesitating about OpenTofu?

A: I’d say don’t overthink it. Do a real POC, push it to prod, and see for yourself. OpenTofu really is a drop-in. But also, don’t just flip the switch. Build support. Talk to people. Make it feel like a team effort. That’s how you get adoption that sticks.

At the scale Fidelity operates, migrations like this don’t happen without intention. What stands out most in David’s approach is not just the technical execution, but the trust-building, the clear-eyed assessment of what really matters, and the willingness to go deep with both tooling and teams. For those navigating similar decisions, it’s a reminder that success often comes less from the tooling itself and more from the way it’s introduced, supported, and led.

Disclaimer: OpenTofu and Fidelity Investments are separate companies. Unless otherwise noted, the opinions provided are those of the speakers, not necessarily those of Fidelity Investments or its affiliates.

This is a highly requested feature that we have been hard at work on for a while now. All the necessary components have now been merged and are available in the nightly builds of OpenTofu and will be available in the upcoming 1.11 release.

Downloading the nightly builds​

The nightly builds are available exclusively from the OpenTofu Nightly Repository. Please choose the select the appropriate file for your platform.

Ephemeral Overview​

A long-standing issue with OpenTofu and its predecessor has been the storage of sensitive data within the state. Prior to Ephemeral, this data contained everything that OpenTofu knows about the resources it manages. This includes sensitive values, keys, and other secrets that could lead to security incidents if leaked. The introduction of Ephemeral and Write-Only allows for careful configuration to prevent storing this secret data, ensuring that these values only exist within the duration of a single execution of the tofu binary. It also allows for transient resources, such as network tunnels, to be made available during specific portions of the OpenTofu Plan/Apply flow.

Prior Solutions​

As many seasoned OpenTofu and Terraform authors know, values and attributes can be marked as Sensitive to prevent them from being displayed in the CLI. This helps prevent accidental exposure of secrets through CI/CD logs and other mechanisms. It still however stores the plain text data in the state.

To remedy this, OpenTofu introduced State and Plan Encryption. This feature allows you to carefully protect your plan and state data, as well as ensuring that they have not been tampered with in transport. Although the values are still stored within the state and plan, this adds an additional level of security to make it much more difficult for attackers to gain access. It protects the entire state and plan, regardless of how individual resources are configured or marked. Therefore it is still recommended to use state and plan encryption, even after adopting Ephemeral concepts into your workflow.

Ephemeral Resources​

Ephemeral Resources are entities that only exist during the execution of a single command. They are opened at the beginning of an OpenTofu operation to get their ephemeral value and closed at the end of the operation. These resources can represent anything from keys in a Key Management System to a SSH proxy that is established when the resource is opened.

The attributes of Ephemeral Resources are marked as ephemeral and as such can only be used in very specific contexts.

Write-Only Attributes​

Write-Only attributes are a special case that has been added to Managed Resources to allow passing ephemeral data into non-ephemeral resources. These attributes can be set in configuration, but their values will never be stored in state or even available as an attribute to be accessed in other portions of the configuration.

This is geared toward sending ephemeral data, such as passwords and keys, into resources which use and/or manage this data outside of OpenTofu.

Further Reading​

This blog post barely scratches the surface of what is now possible with Ephemeral and Write-Only. Peruse our latest docs for a more complete overview and in-depth examples!

Providing feedback​

Thank you for taking the time to test this preview release. If you have any feedback, please use a GitHub issue or chat with us on the OpenTofu Slack.

From OCI registry support that revolutionizes provider and module distribution, to adding support for deprecation attributes that helps module authors gracefully evolve their APIs, OpenTofu 1.10.0 is packed with enhancements that address real-world challenges faced by teams at scale. We're incredibly grateful to everyone who tested our alpha and beta releases, provided feedback, and contributed code – your input has been invaluable in shaping this release.

The Perfect 10: Celebrating 10 Million Downloads​

As we release OpenTofu 1.10.0, we're thrilled to announce that we're about to cross an incredible milestone: 10 million downloads from GitHub releases alone! Currently at 9.8 million downloads, we're on track to hit this landmark within days. This doesn't even include installations from Homebrew, package managers, Docker Hub, or corporate mirrors – the true number is likely already well past 20 million.

Perhaps most impressively, our community's trust is evident in adoption velocity. If we look at the GitHub release downloads, when we released v1.9.1, it overtook v1.9.0 in just 7 days – the fastest patch adoption we've ever seen. Currently, 63% of the total downloads daily are for the latest v1.9.x series.

Major Features Overview​

OpenTofu 1.10.0 is packed with powerful new capabilities that address real-world infrastructure challenges. Here are the highlights:

• OCI Registry Support - Distribute providers and modules through container registries, perfect for air-gapped environments
• Native S3 State Locking - Simplified state management without requiring DynamoDB
• Deprecation Support - Module authors can now mark variables and outputs as deprecated
• Enhanced Planning - New -target-file and -exclude-file options for better resource management
• Global Provider Cache Lock - Safe concurrent operations in CI/CD environments
• OpenTelemetry Tracing - Local-only observability for debugging and performance analysis
• External Key Providers - Flexible state encryption with your preferred secret management tools
• Enhanced moved and removed blocks - More powerful infrastructure refactoring capabilities

You can find detailed information about all these features and more on our comprehensive What's new in OpenTofu 1.10? page.

Ecosystem Maturity​

Official VS Code Extension​

The OpenTofu ecosystem continues to flourish with professional tooling. Our official VS Code extension (currently in preview) provides a first-class development experience with syntax highlighting, IntelliSense autocompletion, real-time validation, and integrated documentation. Whether you're writing modules or managing complex infrastructure, the extension helps catch errors early and speeds up development with smart suggestions for resources, data sources, and built-in functions.

Available on VS Code Marketplace and Open VSX Registry

Language Server Protocol Support​

Not a VS Code user? You can get the same powerful features in your preferred editor with tofu-ls, our Language Server Protocol implementation. This brings OpenTofu intelligence to any LSP-compatible editor including Neovim, Emacs, Sublime Text, and more. Get autocompletion, diagnostics, and documentation lookup wherever you write your infrastructure code.

OpenTofu Registry MCP Server​

For those using AI assistants like Claude, Cursor, or other MCP-compatible tools, the OpenTofu Registry MCP server provides direct access to provider and module documentation. This enables your AI coding assistant to read the latest OpenTofu registry docs and generate accurate, up-to-date infrastructure code with proper resource configurations and best practices. You can use our hosted service at https://mcp.opentofu.org/mcp or run it locally for complete control.

Learn more about the MCP server

Get Started Today​

Download and Install​

Getting started with OpenTofu 1.10.0 is easy. You can download it directly from our GitHub releases page, install it via your favorite package manager, or use our official Docker images. We support all major platforms including Linux, macOS, and Windows.

View our installation guides

Join the Community​

OpenTofu's success is built on our vibrant community. Join thousands of practitioners sharing knowledge, contributing code, and shaping the future of open-source infrastructure as code. Whether you have questions, want to contribute, or just want to stay updated, there's a place for you.

Join us on Slack

We're excited to announce the beta release of OpenTofu 1.10.0! Thanks to your valuable feedback on our alpha releases, we've refined the features and fixed numerous bugs to bring you this more stable beta version.

This post focuses primarily on what's new and improved since the 1.10.0-alpha2 release. If you're new to the 1.10.0 release cycle, we recommend checking out our previous posts about alpha1 and alpha2 to learn about major features like OCI Registry integration, native S3 locking, and OpenTelemetry tracing.

Download and Installation​

The beta release is available from the GitHub Releases page. Select the appropriate file for your platform:

After downloading, unpack the archive to find your tofu binary. For verified downloads, you can also use the standalone installer with signature verification.

What's New in 1.10.0-beta1​

OCI Registry Enhancements​

Since alpha2, we've refined our OCI registry support with important improvements:

• Added support for OCI registries that don't report artifactType on layers
• Improved e2e test verification for provider installation from OCI mirrors
• Enhanced documentation for OCI registry-based provider mirrors
• Fixed issues with OCI providers in air-gapped environments

If you're using OCI registries for private provider distribution or in air-gapped environments, we'd especially appreciate your testing of these features.

Global Provider Cache Lock Improvements​

The shared provider cache (set via the TF_PLUGIN_CACHE_DIR environment variable) now includes filesystem-level locking, making it safe to use with concurrent OpenTofu operations. This is particularly valuable for:

• CI/CD systems that run multiple tofu init operations in parallel
• Orchestration tools that manage multiple OpenTofu pipelines simultaneously
• Large-scale Terragrunt setups with many projects

Since the alpha releases, we've fixed several edge cases and improved the reliability of this locking mechanism.

Bug Fixes and Quality-of-Life Improvements​

The beta release includes numerous bug fixes and quality-of-life improvements:

• Better error messages when using null in invalid positions in the transpose function
• Fixed loading of encryption key providers to better support terraform_remote_state
• Fixed handling of complex variable default values with incorrect types
• Fixed module downloads from GitHub branches containing slashes in the name
• Improved generation of OpenTofu configuration from import blocks with nested attributes
• Added warning when provider references are missing required_providers entries
• Fixed an issue where syntax errors in required_providers blocks could cause panics
• Improved the PostgreSQL backend to prevent state corruption with parallel runs

Key Features Overview for New Testers​

If this is your first look at OpenTofu 1.10.0, here's a concise overview of the major features in this release:

OCI Registry Support​

Full integration with OCI registries for both provider and module distribution, valuable for organizations with private infrastructure-as-code components, air-gapped environments, or enhanced security requirements.

Use module packages from OCI registries directly as a new module source type:

module "vpc" {
  source = "oci://example.com/modules/vpc/aws"
}

Configure OCI registry provider mirrors in your CLI configuration:

provider_installation {
  oci_mirror {
    repository_template = "example.com/opentofu-providers/${namespace}/${type}"
    include             = ["registry.opentofu.org/*/*"]
  }
}

You can find more information on OpenTofu's OCI artifact formats, and instructions for building your own artifacts, in OCI Registry Integrations.

Native S3 Locking​

Simplify your infrastructure by using S3's conditional writes capability for state locking, eliminating the need for a separate DynamoDB table.

terraform {
  backend "s3" {
    bucket       = "tofu-state-backend"
    key          = "statefile"
    region       = "us-east-1"
    use_lockfile = true  # Enable native S3 locking
  }
}

OpenTelemetry Tracing​

Gain insights into OpenTofu operations with experimental OpenTelemetry tracing, completely local and under your control.

# Launch a tracing backend like Jaeger
docker run -d --name jaeger \
  -p 16686:16686 -p 4317:4317 \
  jaegertracing/jaeger:2.5.0

# Configure OpenTofu to use OpenTelemetry
export OTEL_TRACES_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317
export OTEL_EXPORTER_OTLP_INSECURE=true

# Run your operations and view traces at http://localhost:16686
tofu init

Resource Management with Target Files​

Manage complex deployments more easily with the new -target-file and -exclude-file options, allowing version-controlled resource targeting patterns.

# Create a targets.txt file
# Critical infrastructure components
module.networking.aws_vpc.main
module.networking.aws_subnet.public[*]

# Apply only those resources
tofu apply -target-file=targets.txt

# Similarly, create an excludes.txt file to skip certain resources
tofu plan -exclude-file=excludes.txt

Support for marking variables and outputs as deprecated​

Module authors can now mark variables and outputs as deprecated which will raise a warning to the users of the module.

This can be easily done by applying the newly supported deprecated attribute to the variable and output blocks.

A variable block marked as deprecated:

variable "input" {
  type       = string
  default    = "input value"
  deprecated = "This variable is deprecated. This will be removed entirely in a future version of the module."
}

will generate a warning like the following:

│ Warning: Variable marked as deprecated by the module author
│ 
│   on main.tf line 14, in module "call":
│   14:   input = "input value from call"
│ 
│ Variable "input" is marked as deprecated with the following message:
│ This variable is deprecated. This will be removed entirely in a future version of the module.
│ 
│ (and one more similar warning elsewhere)

An output block marked as deprecated:

output "out" {
  value      = "out value"
  deprecated = "This output is deprecated and will be removed in a future version"
}

will generate a warning like the following:

│ Warning: Value derived from a deprecated source
│
│   on main.tf line 32, in locals:
│   32:   string = module.call.out
│
│ This value is derived from module.call.out, which is deprecated with the following message:
│
│ This output is deprecated and will be removed in a future version
│
│ (and one more similar warning elsewhere)

For more details regarding this feature, check the official docs on this topic:

• variables
• outputs
• module calls

Other Major Features​

External Key Providers for State Encryption​

Configure external commands to retrieve encryption keys, enabling flexible state encryption with your preferred tools:

terraform {
  encryption {
    key_provider "external" "password_manager" {
      command = ["./state_encryption_key.sh", "some_parameter"]
    }
  }
}

# You can also chain key providers together:
terraform {
  encryption {
    key_provider "external" "password_manager" {
      command = ["./get_password.sh", "some_parameter"]
    }
    key_provider "pbkdf2" "passphrase" {
      chain = key_provider.external.password_manager
    }
  }
}

Enhanced PostgreSQL Backend​

The PostgreSQL backend now supports custom table and index names for multi-project state management:

terraform {
  backend "pg" {
    conn_str    = "postgres://user:pass@db.example.com/database"
    schema_name = "opentofu"
    table_name  = "project_a_state"
    index_name  = "project_a_index"
  }
}

Resource Type Migration​

The moved block now supports migration between different resource types:

moved {
  from = gpg_key.this
  to   = gpg_key_pair.this
}

Fine-Grained Resource Removal​

The removed block now supports lifecycle and provisioner configurations:

removed {
  from = aws_instance.legacy_server

  lifecycle {
    destroy = true  # Destroys the resource (default is false which just forgets it)
  }

  provisioner "local-exec" {
    when    = destroy
    command = "echo 'Cleaning up before destroying resource'"
  }
}

For more details, see our alpha1 and alpha2 blog posts.

Compatibility Notes​

Before upgrading, please note these key compatibility points:

• Linux: Requires kernel version 3.2 or later
• macOS: Requires macOS 11 Big Sur or later
• The ghcr.io/opentofu/opentofu image is no longer supported as a base image
• Windows: Symbolic links and junctions are now handled differently
• The PostgreSQL backend in OpenTofu 1.10 should not be used alongside older versions

For complete details, review the full changelog.

Join the Testing Effort​

Your testing and feedback are crucial to ensuring that all these new capabilities work flawlessly across different environments and use cases. If you have a non-production environment where you could test any of these capabilities, we'd appreciate your help.

Even if everything works perfectly, please share your testing experiences through GitHub issues or join the conversation in the OpenTofu Slack.

Thank you for your continued support of the OpenTofu project!

Your involvement is crucial as we refine these features. If you have a non-production environment where you could test any of these new capabilities, we'd be grateful for your help. Even if everything works perfectly (which we hope it does!), your feedback via GitHub issues is invaluable to ensuring 1.10.0 becomes the rock-solid release our community deserves.

Downloading the alpha release​

The alpha release is available exclusively from the GitHub Releases page. Please select the appropriate file for your platform. Here are some quick links:

After downloading one of the releases above, unpack the archive to find your tofu binary. For those who prefer verified downloads, you can also use the standalone installer with signature verification.

The Building Blocks of 1.10.0​

If you're just joining us for alpha 2, OpenTofu 1.10.0 is bringing several groundbreaking features to the table:

OCI Registry Integration​

OpenTofu now seamlessly integrates with OCI registries for both provider distribution and module installation (new for alpha 2). This is a game-changer for private, air-gapped environments and teams looking for more flexible ways to distribute their infrastructure components.

Configure provider installation from OCI Registries with a oci_mirror block:

provider_installation {
  oci_mirror {
    repository_template = "example.com/opentofu-providers/${namespace}/${type}"
    include             = ["registry.opentofu.org/*/*"]
  }
}

Or install modules directly using the new oci: source scheme:

module "vpc" {
  source = "oci://example.com/modules/vpc/aws"
}

For more information, see our alpha 1 blog post for provider instructions and our latest docs for module instructions.

Simplified State Management with Native S3 Locking​

Why use two services when one will do? The s3 backend now supports native locking without requiring DynamoDB, streamlining your state management in AWS environments with the simple addition of use_lockfile:

terraform {
  backend "s3" {
    bucket = "tofu-state-backend"
    key = "statefile"
    region = "us-east-1"
    use_lockfile = true
  }
}

Peek Behind the Curtain with OpenTelemetry Tracing​

Ever wondered what's happening under the hood during those long provider installations? Alpha 2 introduces experimental OpenTelemetry (OTel) tracing that gives you unprecedented visibility into OpenTofu's operations.

Getting started with tracing takes two steps. First, launch a tracing backend like Jaeger:

docker run -d --rm --name jaeger \
  -p 16686:16686 \
  -p 4317:4317 \
  -p 4318:4318 \
  -p 5778:5778 \
  -p 9411:9411 \
  jaegertracing/jaeger:2.5.0

Then tell OpenTofu to use it with these environment variables:

# Required variables
export OTEL_TRACES_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317
export OTEL_EXPORTER_OTLP_INSECURE=true

Now you can watch your OpenTofu operations unfold in real-time through the Jaeger UI at http://localhost:16686. Currently, tracing describes:

• Provider installation and downloads
• Lock file operations

This is just the beginning – future releases will expand tracing to cover even more of your OpenTofu workflow. Let us know what areas you want more insight into!

Deprecation for module variables and outputs​

It is now possible to communicate variable and output deprecation via the deprecated attribute! Module authors are able to mark variables and outputs as deprecated by including a suggestion on how to migrate. Module callers will receive a warning if their configuration is affected. Here is an example of configuration:

variable "examle" {
  type       = string
  deprecated = "'examle' variable must no longer be used due to a typo, use 'example' instead"
}

output "examle" {
  value      = "someval"
  deprecated = "'examle' output must no longer be used due to a typo, use 'example' instead"
}

For more information, see marking variable as deprecated and marking output as deprecated

Global Provider Cache Locking​

The Global Provider Plugin Cache allows OpenTofu to download providers into a shared cache directory. Prior to this release, it was not safe to use this with multiple instances of OpenTofu running in parallel as they could clobber each other. We now have added support for filesystem level locking to this cache!

export TF_PLUGIN_CACHE_DIR=/storage/tofu/cache

This now means the global provider plugin cache is safe for tofu to use concurrently:

• With your CI system that runs dozens of tofu inits in parallel
• With your orchestration tool that runs multiple pipelines at the same time
• With all of your Terragrunt projects and stacks

Multi-Project PostgreSQL State Management​

The pg backend gets a significant upgrade with the ability to specify custom table and index names, unlocking multi-project state management within a single database schema:

terraform {
  backend "pg" {
    conn_str    = "postgres://user:pass@db.example.com/database"
    schema_name = "opentofu"
    table_name  = "project_a_state"  # Default is "terraform_state"
    index_name  = "project_a_index"  # Default is "terraform_state_idx"
  }
}

We've also solved an issue that could cause state corruption when sharing a database between different OpenTofu versions, making your state storage more robust than ever.

Resource Migration with moved​

The moved block now supports migration between entirely different resource types:

moved {
    from=gpg_key.this
    to=gpg_key_pair.this
}

Fine-Grained Resource Removal with removed​

The removed block now supports lifecycle and provisioner configurations:

removed {
  from = aws_instance.example

  lifecycle {
    destroy = true  # Destroys the resource (default is false which just forgets it)
  }

  # Provisioners will run before destruction when destroy = true
  provisioner "local-exec" {
    when    = destroy
    command = "echo 'Cleaning up before destroying resource'"
  }
}

Streamlined Resource Planning​

The new -target-file and -exclude-file options transform how you manage complex deployments, allowing you to maintain consistent target and exclusion patterns across your team:

# Target specific resources listed in targets.txt
tofu plan -target-file=targets.txt

# Exclude specific resources listed in excludes.txt
tofu apply -exclude-file=excludes.txt

No more copy-pasting long resource addresses – just reference your carefully maintained resource lists.

Flexible State Encryption with External Key Providers​

Security-conscious teams will appreciate the new external key providers for state encryption, bringing unprecedented flexibility to your secret management approach:

terraform {
  encryption {
    key_provider "external" "password_manager" {
      command = ["./state_encryption_key.sh", "some_parameter"]
    }
  }
}

The PBKDF2 key provider now supports chaining, allowing you to compose multiple key providers:

terraform {
  encryption {
    key_provider "external" "password_manager" {
      command = ["./get_password.sh", "some_parameter"]
    }
    key_provider "pbkdf2" "passphrase" {
      chain = key_provider.external.password_manager
    }
  }
}

And That's Not All​

Alpha 2 packs numerous other quality-of-life improvements:

• The element function now accepts negative indices, with -1 selecting the last element
• Test run outputs can now be referenced in test provider blocks
• Force-unlock capability now extends to the HTTP backend
• Plan outputs now show forgotten resources count, improving visibility into state changes

Before You Upgrade​

As with any significant release, there are some key compatibility points to consider:

• On Linux, OpenTofu now requires kernel version 3.2 or later
• On macOS, OpenTofu now requires macOS 11 Big Sur or later
• OpenTofu 1.10 with the pg backend should not be used alongside older versions
• The ghcr.io/opentofu/opentofu image is no longer supported as a base image
• On Windows, symbolic links and junctions are now handled differently

For complete details, please review the full changelog.

Join the Testing Effort​

OpenTofu 1.10.0 is shaping up to be a landmark release, and your input can help make it truly exceptional. Whether you're intrigued by the OCI registry integration, excited about native S3 locking, or curious about OpenTelemetry tracing, we'd love your feedback.

Share your testing experiences through GitHub issues or join the conversation in the OpenTofu Slack. Every bit of feedback brings us closer to a rock-solid 1.10.0 release.

Thank you!

We have done everything we could to make sure that the new alpha release doesn't break anything, and we need your help to get this release tested. If you have a non-production setup that you would be willing to test any of the new features on, please give it a try and give us feedback using a GitHub issue, even if it's just telling us that everything went well.

This blog post will go over how to download the new preview release and detail how each of the new features works.

Downloading the alpha release​

The alpha release is available exclusively from the GitHub Releases page. Please select the appropriate file for your platform. Here are some quick links:

For the releases above, please unpack the archive and you should find the tofu binary inside. You can also use the standalone installer to download the release with signature verification.

Provider distribution through OCI registries​

One of OpenTofu's top-voted issues is to support distribution of providers and modules through OCI registries. This release brings the first part of it - now you can use OCI registries to install a copy of a provider through a special "provider mirror" location.

Creating a local mirror of some or all of the providers you use can reduce data transfer costs and can help with running OpenTofu in "air-gapped" environments that cannot access any services over the public internet.

Alternative provider installation methods are configured as part of the OpenTofu CLI Configuration. You can configure installation from OCI Registries using an oci_mirror block as part of your Explicit Installation Method Configuration:

provider_installation {
  oci_mirror {
    repository_template = "example.com/opentofu-providers/${namespace}/${type}"
    include             = ["registry.opentofu.org/*/*"]
  }
}

The above example specifies that any provider that belongs to the primary OpenTofu Registry should instead be installed from a repository in an OCI registry, constructing the repository address dynamically using the components of the provider source address.

We also prepared a full-featured guide on how to test OCI Registry Provider Mirrors.

For more information, please refer to the documentation. Also, you can check out our progress via the Provider and module packages from OCI registries RFC Tracker.

Native locking support for s3 backend​

Now, OpenTofu can leverage native s3 conditional writes to eliminate the need of DynamoDB to handle locks. This allows you to rely on a single cloud service to handle both storage and locking of the state file. Please, keep in mind, not all of the s3-compatible storage support this feature yet.

We introduced a new use_lockfile field, which makes OpenTofu create a separate lock file in the same bucket:

terraform {
  backend "s3" {
    bucket = "tofu-state-backend"
    key = "statefile"
    region = "us-east-1"
    use_lockfile = true
  }
}

For more information, please refer to the documentation of the s3 backend.

What else?​

This release brings a lot more other enhancements such as:

• External programs as key providers for state encryption;
• The element function now accepts negative indices;
• moved now supports moving between different types;
• Multiple enhancements for tofu test;
• Count of forgotten resources in plan and apply outputs;
• and much more!

You can find the detailed changelog here.

Providing feedback​

Thank you for taking the time to test this preview release. If you have any feedback, please use a GitHub issue or chat with us on the OpenTofu Slack.

• Provider iteration (for_each)
• The -exclude flag
• Improvements to early evaluation, encryption, AzureRM and HTTP backends
• Several new CLI options
• Significant performance improvements

You can find the full list of improvements and changes on the What's new in OpenTofu 1.9? page.

In line with our support policy, this release also means that OpenTofu 1.6 is no longer supported and we will not release security updates for it anymore. If you are still using 1.6, please upgrade to at least 1.7.

Massive growth: ~300% increase in registry traffic, rising download numbers​

Yes, you read that right. While our previous release showed an increase of roughly 30% over a period of 4 months, in the current release the amount of registry requests have tripled to over 6 million requests per day, peaking at a data transfer of over 140 GB per day.

Similarly, the number of GitHub downloads has risen significantly by about 30% in the 1.8 release to almost 1.5 million downloads. Interestingly, we had over 5000 downloads on the 1.9 prerelease versions.

Apart from users, we also have a very active community helping out with reporting issues, fixing bugs, and helping newcomers with questions. The number of GitHub stars grew to over 23.000, we have received over 150 new issues and the community has been actively voting on them. For this release, our community has contributed over 200 pull requests with features and bugfixes from 49 contributors on the main repository alone.

OpenTofu Search (beta)​

Since our last release, we have indexed the documentation of over 4.000 providers and over 20.000 modules in the OpenTofu Search interface. This was a monumental effort producing over 146 GB of raw data and the project updates the documentation for new provider and module versions every 15-30 minutes. Thanks to the generous sponsorship by Cloudflare, our costs for maintaining this infrastructure are minimal. It took over 12.000 lines of combined Go and Typescript code to accomplish.

JetBrains support​

In their 2024.3 release, JetBrains has announced support for OpenTofu. The integration switches to OpenTofu when it detects a .tofu file in a project and provides OpenTofu-specific code completion, such as state encryption.

Visual Studio Code integration​

In parallel, the OpenTofu core team started working with the community on a possible port of the Visual Studio Code extension for OpenTofu.

Future plans​

With provider iteration now implemented, we are turning our attention to the other much-requested features. Most importantly, we already have a working prototype for the OCI provider registry and we are also looking for your input on the related RFCs. For more details on upcoming features take a look at the 1.10.0 planning milestone on GitHub.

If you have a non-production setup that you would be willing to test any of the new features on, please give it a try and give us feedback using a GitHub issue, even if it's just telling us that everything went well.

This blog post will go over how to download the new preview release and expand on the features presented in the 1.9.0-alpha2 blog post.

Downloading the beta release​

The beta release is available exclusively from the GitHub Releases page. Please select the appropriate file for your platform. Here are some quick links:

For the releases above, please unpack the archive and you should find the tofu binary inside. You can also use the standalone installer to download the release with signature verification.

Provider iteration (for_each)​

One of the biggest challenges keeping the code clean in a multi-region or multi-zone deployment is the sheer number of providers and related configurations you have to juggle. Essentially, you will have to create duplicated code for each region or zone.

With provider iteration, you can now get rid of your code duplications by iterating over a set of providers instead of the duplicated code. If you have a small-scale setup with one of the cloud providers offering multiple zones, start by adding two variables:

variable "regions" {
  description = "A list of regions that should have a deployment."
  type        = set(string)
}

variable "disabled_regions" {
  description = "A list of regions that should be disabled and all resources removed."
  type        = set(string)
  default     = []
}

The regions variable serves as a list of regions you will want to deploy to. The disabled_regions variable will allow you to remove a region later without removing the provider. This feature is extremely important because if you remove the provider without removing its resources, OpenTofu will be unable to remove the resources in that region.

As a next step, you can create your provider declarations. As you can see, this is only a single declaration. The only restriction worth mentioning here is the alias. Due to technical limitations, in this version you can only use for_each in conjunction with alias.

provider "aws" {
  alias    = "by_region"
  region   = each.value
  for_each = var.regions
}

Finally, you can use the provider set to call a submodule. Note that in contrast to the provider block above, the for_each iterates only over the providers that are not disabled. This lets you deprovision a region properly and later completely remove the provider.

module "deploy" {
  source    = "./deploy"
  providers = {
    aws = aws.by_region[each.key]
  }
  for_each = setsubtract(var.regions, var.disabled_regions)
}

As this feature is very new, there are a few limitations in place you may want to observe:

1. You can only use for_each on variables and locals that can be obtained statically. Expressions that rely on data sources or resources are currently not usable.
2. If you have an already-deployed infrastructure, don't simply remove a provider from the list as this will make it impossible for OpenTofu to destroy the infrastructure in this region. Instead, you will need to implement removing that infrastructure first and then remove the provider from the list. See the disabled_regions variable for an example above.
3. Currently, each provider used in a for_each must have an alias. Providers without aliases are not supported for now due to internal technical reasons.
4. There is currently no way to pass a set of providers to a module, you can only pass individual providers.

The -exclude flag​

OpenTofu already has a -target option to only plan or apply certain resources. Why not apply everything except a certain resource? This was the thought behind the -exclude flag and, in fact, this was one of the highest upvoted feature requests for this release.

You can test it by creating the following simple configuration:

resource "local_file" "a" {
    filename = "a.txt"
    content  = "a"
}

resource "local_file" "b" {
    filename = "b.txt"
    content  = "b"
}

resource "local_file" "c" {
    filename = "c.txt"
    content  = "c"
}

If you run tofu apply -exclude local_file.b, you will see that OpenTofu creates a.txt and c.txt, but not b.txt.

Bugfixes and improvements​

Early evaluation improvements​

When using early evaluation introduced in OpenTofu 1.8, OpenTofu will now prompt you for the variables needed for evaluation.

The new encrypted_metadata_alias option for state encryption​

One of the tricky parts when using state encryption in previous versions is that OpenTofu needs to store the name of the key provider into the encrypted data alongside some metadata needed for decryption. This meant that changing the key provider name would involve using a fallback block and key provider naming for remote state data sources would have to be synchronized. With OpenTofu 1.9, we are introducing a new encrypted_metadata_alias option you can use to explicitly set the ID stored with the encrypted data:

terraform {
  encryption {
    key_provider "pbkdf2" "mykey" {
      passphrase               = "OpenTofu has encryption"
      # Note the fixed encrypted_metadata_alias here:
      encrypted_metadata_alias = "certificates"
    }
    method "aes_gcm" "mymethod" {
      keys = key_provider.pbkdf2.mykey
    }
    state {
      method = method.aes_gcm.mymethod
    }
  }
}

Logging and other improvements​

• You can now use the -consolidate-warnings and -consolidate-errors options to consolidate similar warnings and errors together.
• The HTTP backend now supports extended trace logging, including request and response bodies.
• OpenTofu will now prompt for values for input variables needed for early evaluation.
• tofu console now accepts expressions split over multiple lines, when the newline characters appear inside bracketing pairs or when they are escaped using a backslash.
• tofu test now throws errors instead of warnings for invalid override and mock fields.
• Several performance improvements for large graphs and large amounts of submodules.

Providing feedback​

Thank you for taking the time to test this preview release. If you have any feedback, please use a GitHub issue or chat with us on the OpenTofu Slack.

We have done everything we could to make sure that the new alpha release doesn't break anything, and we need your help to get this release tested. If you have a non-production setup that you would be willing to test any of the new features on, please give it a try and give us feedback using a GitHub issue, even if it's just telling us that everything went well.

This blog post will go over how to download the new preview release and detail how each of the new features works.

Downloading the alpha release​

The alpha release is available exclusively from the GitHub Releases page. Please select the appropriate file for your platform. Here are some quick links:

For the releases above, please unpack the archive and you should find the tofu binary inside. You can also use the standalone installer to download the release with signature verification.

Provider for_each​

Imagine you have to deploy an infrastructure that involves multiple regions using your cloud provider. In order to minimize code duplication, you created a module that you can use for each region. However, your main module still looks like this:

provider "aws" {
  alias  = "useast"
  region = "us-east-1"
}

provider "aws" {
  alias  = "uswest"
  region = "us-west-1"
}

provider "aws" {
  alias  = "eucentral"
  region = "eu-central-1"
}

module "deploy-useast" {
  source    = "./deploy"
  providers = {
    aws = aws.useast
  }
}

module "deploy-uswest" {
  source    = "./deploy"
  providers = {
    aws = aws.uswest
  }
}

module "deploy-eucentral" {
  source    = "./deploy"
  providers = {
    aws = aws.eucentral
  }
}

Starting OpenTofu 1.9, you can now use a for_each instead:

variable "regions" {
  description = "A list of regions that should have a deployment."
  type        = set(string)
}

variable "disabled_regions" {
  description = "A list of regions that should be disabled and all resources removed."
  type        = set(string)
  default     = []
}

provider "aws" {
  alias    = "by_region"
  region   = each.value
  for_each = var.regions
}

module "deploy" {
  source    = "./deploy"
  providers = {
    aws = aws.by_region[each.key]
  }
  // Here we make sure that all resources from a region are removed
  // if the region is disabled. This must be done before removing
  // a region entirely.
  for_each = setsubtract(var.regions, var.disabled_regions)
}

As you can see, you can pass in the set of regions using a variable and then call the module as many times as you need it.

However, there are some important considerations to remember when using for_each in this manner:

1. You can only use for_each on variables and locals that can be obtained statically. Expressions that rely on data sources or resources are currently not usable.
2. If you have an already-deployed infrastructure, don't simply remove a provider from the list as this will make it impossible for OpenTofu to destroy the infrastructure in this region. Instead, you will need to implement removing that infrastructure first and then remove the provider from the list. See the disabled_regions variable for an example above.
3. Currently, each provider used in a for_each must have an alias. Providers without aliases are not supported for now due to internal technical reasons.
4. There is currently no way to pass a set of providers to a module, you can only pass individual providers.

We are actively working on resolving these limitations and future OpenTofu versions will see this capability improved.

Exclude on plan and apply​

This flag is small but powerful: similar to -target, you can now tell OpenTofu to ignore a certain resource when applying your configuration.

For example:

tofu plan -exclude=kubernetes_manifest.crds

In this case, OpenTofu will ignore kubernetes_manifest.crds during planning.

Providing feedback​

Thank you for taking the time to test this preview release. If you have any feedback, please use a GitHub issue or chat with us on the OpenTofu Slack.

The Registry API​

OpenTofu and its predecessor Terraform rely on provider binaries created by the community to interact with various APIs. There are currently over 4,000 such providers in the OpenTofu Registry, enabling a wide range of integrations from cloud providers to managing your GitHub account. Anything that has an API to create some kind of resource can be integrated with OpenTofu.

Aside from providers, the community has also created well over 20,000 reusable modules that implement higher level functionality, such as provisioning an entire infrastructure with a cloud provider with only a few configuration options.

Since these providers and modules are created by the community, OpenTofu needs to know where to download them and what versions are available. This is where the Registry comes into play: it holds the information about available providers and modules, download URLs, checksums, and GPG keys for integrity verification.

Step 1: Service Discovery​

For both providers and modules, OpenTofu first requests the https://registry.opentofu.org/.well-known/terraform.json file, which has the following content:

{
  "modules.v1": "/v1/modules/",
  "providers.v1": "/v1/providers/"
}

This file lists the endpoints OpenTofu should query for information about modules and providers. For private registries there is also a third endpoint named login.v1, providing information about an OAuth endpoint to use for authentication. If you are interested in the details, you can read more about this protocol in the OpenTofu documentation.

Step 2: Version Listing​

With the endpoint information, OpenTofu can query the version listing endpoint for the desired provider or module.

• For providers this endpoint would be /v1/providers/NAMESPACE/NAME/versions (example).
• For modules it would be /v1/modules/NAMESPACE/NAME/SYSTEM/versions (example).

Step 3: Download Info​

Based on the information received, OpenTofu can request the information about the specific version, operating system and architecture.

• For providers, it would be located at /v1/providers/NAMESPACE/NAME/VERSION/download/OS/ARCH (example).
• For modules, it would be located at /v1/modules/NAMESPACE/NAME/SYSTEM/VERSION/download (example).

OpenTofu then downloads the provider from the supplied GitHub releases URL and verifies the checksum and signature, or clones the returned Git repository for modules.

Hosting the Registry (for free)​

As an open source project with a small core team working on developing OpenTofu itself, it was paramount that we kept the costs of running the Registry as low as possible both in terms of bandwidth and also in human cost. However, we also needed to make sure that the Registry had an uptime close to 100% since thousands upon thousands of developers would be left without a means to update their infrastructure if it went down.

Here we owe a big thanks to Cloudflare. Their very competitive pricing for R2 with no egress fees and their sponsorship of OpenTofu meant that we would be able to run the Registry essentially for free with no servers and scaling issues to worry about. The Registry codebase (written in Go) pre-generates all possible answers of the API above and uploads the static files to an R2 bucket.

Populating the Registry​

Alongside the Terraform license change, HashiCorp closed the Terraform Registry for software that isn't Terraform, so using it as a source of data for the OpenTofu Registry was out of the question. However, since the Terraform Registry was coupled exclusively to GitHub, it was relatively straight forward for us to use the GitHub search API to populate the Registry, if a little slow.

Updating the Registry, however, was a much harder problem. GitHub limits the API to ~5,000 requests per hour, which is not enough to update roughly 30,000 providers and modules in a speedy fashion, especially since some updates required multiple requests.

We could have requested provider authors to log in with their GitHub account, granting us an access token we could use for a higher rate limit, but that would have been impractical when we launched the Registry since we would have had to ask thousands of developers to log in at a time when OpenTofu wasn't even released yet.

The solution came by the way of the GitHub RSS feeds, which are not rate limited. The releases RSS located at http://github.com/USERNAME/REPO/releases.atom always contains the last 5 releases, which is sufficient if we only need to add the latest versions as it is unlikely that a provider or module would have more than 5 releases within an hour. For modules, we needed to query the tags instead of the releases, which was even easier because the git ls-remote command gave us all this information and was also not rate limited. (You are going to keep it that way, right, GitHub?)

The submission process​

Since we didn't need to ask provider and module authors for their credentials using OAuth, we were able to create a simple submission process that anyone with a GitHub account could use.

While anyone could submit a provider or a module, we still needed provider authors to submit their GPG keys so their binaries could be verified. Instead of asking for OAuth logins, we again decided to use the GitHub API in a creative way. In order to submit a GPG key for a provider, the author needed to set their organization membership to public for the repository of the provider and then submit a GitHub issue. We would verify their membership in the provider organization and process their GPG keys.

Having the submission process being as simple as opening a GitHub issue turned out to be quite popular. To date, the community has opened almost 1,000 pull requests and issues on the Registry repository. It also meant that provider and module authors working for larger organizations did not need to expend any organizational capacity to sign up for an OpenTofu account, resulting in quite a few high profile providers adding their GPG key.

Building a user interface​

After working on the Registry and taking a few months pause for some much-needed work on OpenTofu itself, we returned to building a search and documentation reading interface. As we would soon learn, this was a larger task and resulted in three times the amount of code needing to be written.

As before, we chose an architecture that would generate static files. Early on we had to make a decision between simply generating static HTML files or using a Single Page Application and load the data from an API. We chose the latter because we were concerned that a layout change would require a complete regeneration of all files, which would be cost-prohibitive to upload again and again.

Having made this decision we set out to build a backend and a frontend component, the former being responsible for producing the data the latter would consume. We built libregistry, a standardized Go library that would make it easier to access the metadata stored in the Registry repository and provide a useful abstraction layer on top of GitHub and the various creative API integrations we built to fetch the data.

Pre-processing the documentation​

While the Registry always regenerates all API responses from the raw metadata, this approach was not feasible for the documentation due to the sheer volume of data we needed to process. Not only would we have to produce documentation responses for tens of thousands of providers and modules, some of them also had several hundred versions, each of which needed their own copy of the documentation stored.

We decided that we would process the data from the source repositories directly into an R2 bucket without storing any intermediate data. This approach came with its own problems. While the Registry could make use of git to track changes in the intermediate data, we needed to make sure that our uploads to the R2 bucket were as close to atomic as possible so no partial uploads are left behind. While we have implemented a partial solution that can continue an upload, this still remains one of the unsolved issues with the Registry.

In order to simplify the necessary frontend logic for displaying the documentation, the backend's main job is to rename and move each of the documentation files into their standardized place. There is no formalized description on how providers can store their documentation, so the logic for extracting this information is only empirically known. We needed several iterations to work around various bugs as we expanded the number of repositories we ingested and discovered newer and newer edge cases.

Module schemas​

While providers typically have their own, explicit documentation, often generated by tools like terraform-docs, modules don't have such information readily available. This makes it difficult to generate information about their inputs, outputs and dependencies.

HashiCorp published terraform-schema for extracting this information, duplicating some of the module parsing logic from Terraform. However, we decided that maintaining duplicated codebases would likely cause a maintenance issue down the line and implemented this functionality directly into OpenTofu. This patch currently lives on a branch, but will be integrated into the main branch as an experimental feature at a later date.

Licenses​

During the ingestion process we also needed to concern ourselves with licenses: as we were unsure under what legal standard such a documentation dataset would fall, we deliberately chose a restricted set of licenses that we would accept into the Registry documentation. We performed automatic license detection on each provider and module repository to avoid ingesting content under potentially problematic licenses.

The OpenTofu Docs API (and how you can use it)​

Doing all this work on the backend and splitting the display logic from the data also had an unintended but very welcomed side effect: we were able to offer an API for provider and module documentation, which would come in handy as just a few weeks later Jetbrains requested just such an API for their OpenTofu integration.

The backend produces the dataset in this format and is easily runnable locally from the registry-ui repository, while the public API is available for anyone to build integrations with. We even made sure to include the correct CORS headers if you would like to build a browser-only integration. If you build something cool with it, let us know!

Search​

As we were building the backend, one issue was constantly on our minds: how do we make such a vast data set searchable? We hoped that it would be possible to simply generate a search index and let the client JavaScript deal with the entire search problem. As we were looking at lunr.js, a robust and mature library for search, it quickly became apparent that this path would be entirely unfeasible. Even with a limited data set, the download size of the search index quickly ballooned to several hundred megabytes, which is not exactly ideal for a snappy search functionality not to mention really upsetting to people with data caps.

Not wanting to run our own database server or involve any more service dependencies, we looked at Cloudflare's D1, a SQLite database service and a worker to handle search queries. While it initially looked promising, we discovered that we would have to submit all updates in a single HTTP request in order to run them in a transaction.

It would have been possible to work around it and still perform atomic search index updates, but we ended up using Neon, a database-as-a-service offering, instead. They don't explicitly sponsor OpenTofu, but their free tier was comfortably enough for our search index and the next tier was also quite affordable. Their tight integration with Cloudflare was also a very welcome addition.

To query the database hosted at Neon, we created a Cloudflare worker. This worker ended up handling all requests to api.opentofu.org, forwarding the static requests to R2 and handling the search queries itself.

The backend would prepare a line-delimited JSON (ndjson) file with a data feed at https://api.opentofu.org/registry/docs/search.ndjson, containing all recent updates to the search index that the worker could ingest and fill into the database.

Where do we go from here?​

The OpenTofu Registry Search is currently in beta, indicating that not everything is working yet. As we are expanding the amount of providers and modules indexed, we will certainly discover more edge cases that need to be fixed.

The libregistry library also duplicates a lot of the functionality present in the registry codebase as well. We want to deduplicate this functionality, both for long-term maintenance and because libregistry would make it easier for people to run their own mirror or even independent copy of the Registry.

During this process your feedback is invaluable for prioritization. If you find a bug or have a use case we haven't considered, please use GitHub issues to let us know.

• You can now use variables and locals in places that were not previously available, such as module sources, backend configuration and state encryption. Being able to assign variables more dynamically will eliminate code duplication and boilerplate code, making projects easier to maintain. However, we are not stopping there: future releases will see dynamic provider configuration assignments and more.
• Since Terraform doesn't support these new language features, OpenTofu now supports the .tofu file extension. When a file with the .tofu extension is present, OpenTofu will ignore the identically named .tf file. Using this new file extension, module authors can use the new features of OpenTofu and still keep older code around for compatibility.
• You can now use provider mocking as well as resource overrides with tofu test. This allows for more flexible testing similar to traditional software testing methods.

You can find the full list of improvements and changes on the What's new in OpenTofu 1.8? page.

Growth continues: ~30% increase in registry traffic​

While we don't believe in tracking our users and OpenTofu does not have phone-home telemetry, we can observe a trajectory based on registry usage. In our last release post 3 months ago we recorded a peak of roughly 1.4 million daily requests to the registry. We are happy to report that this number has increased by roughly 30% to almost 1.8 million peak daily requests.

As before, the OpenTofu community is very active in reporting and voting on issues, fixing bugs, and helping out with testing. The number of GitHub stars grew by ~10% to almost 22.000, the top-voted issues received hundreds of votes and quite a few comments in the discussions. This release has also seen significant contributions from outside the core team, ranging from small fixes to large performance overhaul PRs. In total, over 100 issues and over 150 pull requests were opened since the last release. 26 people contributed to this release on the main repository alone, with several significant contributions added to other repositories as well.

Finally, we'd like to direct your attention to Awesome OpenTofu, a community page containing a host of tools, platforms, registry implementations and learning material for OpenTofu.

Better documentation for the future: the new RFC process​

As the community kept working hand-in-hand with the core team it became clear that our previous RFC process based on GitHub Issues wasn't detailed enough. The linear nature of issue comments didn't encourage discussing specific parts of an RFC and the RFCs themselves did not contain enough context for someone in a few months or years to fully understand why the change was necessary.

Our new pull request-based RFC process fills this gap by using PR reviews to discuss parts of a document and the document itself encourages creating a historical record. We have trialled this process during the development of the early (static) evaluation feature and also the upcoming dynamic provider assignment functionality. We hope that these documents will provide a better view into the new features coming to OpenTofu and also help create a historical record on why engineering decision were made the way they were.

Coming soon: the OpenTofu Registry UI​

In parallel to this release, we have been hard at work on a web-based user interface for the OpenTofu Registry. This user interface will allow you to browse and search for providers, resources and modules and read their documentation in a convenient format. We are aiming to release this user interface in the next few weeks.

Fulfilling promises: our first Go libraries​

OpenTofu was founded on the principle of openness and modularity. While it is not always easy to modularize a codebase with a long history, we have released our first Go libraries for interoperability.

TofuDL encodes the process of fetching the latest version of OpenTofu, verifying the signature and extracting the binary for local use into an easy-to-use Go library. Tool authors can use this library to cut down on the complexity of downloading the Tofu binary when needed. Furthermore, this library contains a full release mirroring tool, allowing you to build a release server with OpenTofu releases for air-gapped infrastructure that TofuDL-based tools can use to obtain the mirrored binaries.

The currently experimental libregistry provides structured access to the data stored in the OpenTofu registry using the metadata API. In the future, we will transition the processes currently written for GitHub Actions into this library, allowing you to execute all registry processes independently of GitHub. You can use this library as a basis for writing your own registry, although the batteries are definitely not included.

Please give these libraries a go (pun totally intended) and let us know what functionality you would like to see in them.

The future: more dynamic functionality, even more community-focussed development​

Ever since we created our top-ranking issues list, new votes from the community started pouring in, giving us a strong signal on where you want us to take OpenTofu. By a large margin, the top-requested issue was one we partly solved in this release by introducing early evaluation for variables and locals. However, this is only the first step. As you helped us test the early alpha and beta of this release, one of the most commonly asked questions was: “When can I use early evaluation to dynamically configure providers?”

The top-voted enhancement reflects a similar sentiment. In 1.9 and beyond, we aim to bring you dynamic provider assignments and more early-evaluation features, which let you cut down on the unnecessary code repetition even further. If you are interested in this topic, give the corresponding RFC a read.

An ask for help: GPG keys for providers​

Finally, we have a favor to ask. The OpenTofu registry currently contains GPG signing keys only for a small number of providers as these keys are not publicly available on GitHub. If you are a provider author, please submit your signing key here. It takes only a few minutes and does not require you to sign any legal documents or grant us access to your GitHub organization. If you are an OpenTofu user and you see that your providers are not signed, please let your provider author know that they can submit their keys and help secure the OpenTofu ecosystem.

You can identify a missing signing key by running tofu init and keeping an eye out for the following message:

Signature validation was skipped due to the registry not containing GPG keys for this provider

Thank you for your help!

If you have a non-production setup that you would be willing to test any of the new features on, please give it a try and give us feedback using a GitHub issue, even if it's just telling us that everything went well.

This blog post will go over how to download the new preview release and expand on the features presented in the 1.8.0-alpha1 blog post.

Downloading the beta release​

The beta release is available exclusively from the GitHub Releases page. Please select the appropriate file for your platform. Here are some quick links:

For the releases above, please unpack the archive and you should find the tofu binary inside. You can also use the standalone installer to download the release with signature verification.

Provider mocking in tofu test​

Building on the existing ability to override specific data sources, resources, and module calls, tofu test now supports mocking entire provider definitions. This new feature allows you to automatically generate mock values for resources and data sources on a per-provider basis. As an example, consider the following code that spins up an m6i.2xlarge instance on AWS:

provider "aws" {
    region = "us-east-1"
}

data "aws_ami" "ubuntu" {
    most_recent = true
    filter {
      name   = "name"
      values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-24.04-amd64-server-*"]
    }
    owners = ["099720109477"]
}

resource "aws_instance" "web" {
    ami           = data.aws_ami.ubuntu.id
    instance_type = "m6i.2xlarge"
}

Instead of querying the AMI ID and spinning up the instance, we can write test code as follows:

// This block will prevent OpenTofu from configuring aws provider.
// All provider's resources and data sources will be mocked.
mock_provider "aws" {
  mock_data "aws_ami" {
    defaults = {
      id = "ami-12345"
    }
  }
}

run "test" {
  assert {
    condition     = aws_instance.web.ami == "ami-12345"
    error_message = "Incorrect AMI ID passed to aws_instance.web: ${aws_instance.web.ami}"
  }
}

While this will not fully test the entire provisioning, it will highlight errors that may be caused by incorrectly connecting resources together without the need for an actual AWS account.

Resource overrides in tofu test​

First introduced in OpenTofu 1.8.0-alpha1, you can now override resources, data sources and entire modules from your tests, allowing you to create similar behavior to mocks in traditional software testing. As an example, consider the following code that spins up an m6i.2xlarge instance on AWS:

provider "aws" {
    region = "us-east-1"
}

data "aws_ami" "ubuntu" {
    most_recent = true
    filter {
      name   = "name"
      values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-24.04-amd64-server-*"]
    }
    owners = ["099720109477"]
}

resource "aws_instance" "web" {
    ami           = data.aws_ami.ubuntu.id
    instance_type = "m6i.2xlarge"
}

Instead of querying the AMI ID and spinning up the instance, we can write test code as follows:

provider "aws" {
  access_key = "foo"
  secret_key = "bar"

  skip_credentials_validation = true
  skip_region_validation      = true
  skip_metadata_api_check     = true
  skip_requesting_account_id  = true
}

# This block disables refreshing the aws_ami.ubuntu data source
# and lets you manually specify the values:
override_data {
  target = data.aws_ami.ubuntu
  values = {
    id = "ami-12345"
  }
}

run "test" {
  # This block disables provisioning the aws_instance.web resource:
  override_resource {
    target = aws_instance.web
    values = {
      # You can add values here.
    }
  }

  assert {
    condition     = aws_instance.web.ami == "ami-12345"
    error_message = "Incorrect AMI ID passed to aws_instance.web: ${aws_instance.web.ami}"
  }
}

While this will not fully test the entire provisioning, it will highlight errors that may be caused by incorrectly connecting resources together without the need for an actual AWS account. Similarly, you can use override_module to override an entire module.

Early variable/locals evaluation​

Introduced in OpenTofu 1.8.0-alpha1, this feature lets you use variables and locals for backends, module sources and encryption configuration as long as they are not dependent on resources, data sources or module outputs. This works even if a local is referencing a variable, for example. This is only the first in a series of improvements that will make the .tf code more flexible with more improvements coming in future releases.

The tofu init command will now consume your .tfvars file and let you specify variables using the -var and -var-file options. Please note that this alpha release will not prompt you for missing variables, which is a feature we will add later. Note, that tofu init will fail if it is missing variables needed for static evaluation.

For example, if you wanted to use the same configuration for your S3 backend and your AWS provider, you can now do this:

variable "aws_region" {
  default = "us-east-1"
}

terraform {
  backend "s3" {
    region = var.aws_region
  }
}

provider "aws" {
  region = var.aws_region
}

You can also use this to manage module versions with both registry references and git URLs.

locals {
  aws_module_version = "5.6.1"
}

module "webserver" {
  source  = "terraform-aws-modules/ec2-instance/aws"
  version = local.aws_module_version

  // Other ec2_instance options
}

module "db" {
  source  = "https://github.com/terraform-aws-modules/terraform-aws-ec2-instance?ref=v${local.aws_module_version}"

  // Other ec2_instance options
}

Finally, here's how you can set up encryption with a passphrase using a variable:

variable "passphrase" {
  type = string
}

terraform {
  encryption {
    key_provider "pbkdf2" "my_passphrase" {
      passphrase = var.passphrase
    }

    method "aes_gcm" "my_method" {
      keys = key_provider.pbkdf2.my_passphrase
    }

    state {
      method = method.aes_gcm.my_method
    }
  }
}

Override files for OpenTofu: keeping compatibility​

Since we are now adding features to OpenTofu that are not present in Terraform, we want to give module authors the ability to write code for both OpenTofu and Terraform without needing to maintain two copies of their modules. You can now create files named .tofu that are exclusive to OpenTofu. If you create a file named foo.tofu, OpenTofu will ignore the similarly-named foo.tf file. You can use this functionality to put your Terraform-specific code in the .tf file and then override it for OpenTofu in the .tofu file.

Bugfixes and improvements​

Static Variable Planing​

Static variables are now handled correctly when embedded in plan files. This was reported as a bug found in 1.8.0-alpha1.

tofu plan -out=tofu.tfstate -var="param=value"
# Variables are correctly read from the given plan and should not be specified via CLI
tofu show tofu.tfstate
tofu apply tofu.tfstate

Improved provider error messages​

Also included in the beta is improvements in error messages produced by misconfigured providers. Some defaulted providers which require configuration blocks were able to generate error messages like:

╷
│ Error: Insufficient features blocks
│
│   on <empty> line 0:
│   (source code not available)
│
│ At least 1 "features" blocks are required.
╵

This error message will now include information about which provider is encountering the specific missing-block validation issue to help the user track it down.

Providing feedback​

Thank you for taking the time to test this preview release. If you have any feedback, please use a GitHub issue or chat with us on the OpenTofu Slack.

Additionally, we are bringing you a feature that lets you use new OpenTofu features while still keeping compatibility with Terraform as well as the ability to override resources and data sources in tofu test. The release also includes a host of smaller improvements and bugfixes to various parts of OpenTofu listed in the changelog.

Now we'd like to ask you for help: we have done everything we could to make sure that the new alpha release doesn't break anything, and we need your help to get this release tested. If you have a non-production setup that you would be willing to test any of the new features on, please give it a try and give us feedback using a GitHub issue, even if it's just telling us that everything went well.

This blog post will go over how to download the new preview release and detail how each of the new features works.

Downloading the alpha release​

The alpha release is available exclusively from the GitHub Releases page. Please select the appropriate file for your platform. Here are some quick links:

For the releases above, please unpack the archive and you should find the tofu binary inside. You can also use the standalone installer to download the release with signature verification.

Early variable/locals evaluation​

This feature lets you use variables and locals for backends, module sources and encryption configuration as long as they are not dependent on resources, data sources or module outputs. This works even if a local is referencing a variable, for example. This is only the first in a series of improvements that will make the .tf code more flexible with more improvements coming in future releases.

The tofu init command will now consume your .tfvars file and let you specify variables using the -var and -var-file options. Please note that this alpha release will not prompt you for missing variables, which is a feature we will add later. Note, that tofu init will fail if it is missing variables needed for static evaluation.

For example, if you wanted to use the same configuration for your S3 backend and your AWS provider, you can now do this:

variable "aws_region" {
  default = "us-east-1"
}

terraform {
  backend "s3" {
    region = var.aws_region
  }
}

provider "aws" {
  region = var.aws_region
}

You can also use this to manage module versions with both registry references and git URLs.

locals {
  aws_module_version = "5.6.1"
}

module "webserver" {
  source  = "terraform-aws-modules/ec2-instance/aws"
  version = local.aws_module_version

  // Other ec2_instance options
}

module "db" {
  source  = "https://github.com/terraform-aws-modules/terraform-aws-ec2-instance?ref=v${local.aws_module_version}"

  // Other ec2_instance options
}

Finally, here's how you can set up encryption with a passphrase using a variable:

variable "passphrase" {
  type = string
}

terraform {
  encryption {
    key_provider "pbkdf2" "my_passphrase" {
      passphrase = var.passphrase
    }

    method "aes_gcm" "my_method" {
      keys = key_provider.pbkdf2.my_passphrase
    }

    state {
      method = method.aes_gcm.my_method
    }
  }
}

Override files for OpenTofu: keeping compatibility​

Since we are now adding features to OpenTofu that are not present in Terraform, we want to give module authors the ability to write code for both OpenTofu and Terraform without needing to maintain two copies of their modules. You can now create files named .tofu that are exclusive to OpenTofu. If you create a file named foo.tofu, OpenTofu will ignore the similarly-named foo.tf file. You can use this functionality to put your Terraform-specific code in the .tf file and then override it for OpenTofu in the .tofu file.

Resource overrides in tofu test​

This version also brings an improvement for the tofu test command. You can now override resources, data sources and entire modules from your tests, allowing you to create similar behavior to mocks in traditional software testing. As an example, consider the following code that spins up an m6i.2xlarge instance on AWS:

provider "aws" {
    region = "us-east-1"
}

data "aws_ami" "ubuntu" {
    most_recent = true
    filter {
      name   = "name"
      values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-24.04-amd64-server-*"]
    }
    owners = ["099720109477"]
}

resource "aws_instance" "web" {
    ami           = data.aws_ami.ubuntu.id
    instance_type = "m6i.2xlarge"
}

Instead of querying the AMI ID and spinning up the instance, we can write test code as follows:

provider "aws" {
  access_key = "foo"
  secret_key = "bar"

  skip_credentials_validation = true
  skip_region_validation      = true
  skip_metadata_api_check     = true
  skip_requesting_account_id  = true
}

# This block disables refreshing the aws_ami.ubuntu data source
# and lets you manually specify the values:
override_data {
  target = data.aws_ami.ubuntu
  values = {
    id = "ami-12345"
  }
}

run "test" {
  # This block disables provisioning the aws_instance.web resource:
  override_resource {
    target = aws_instance.web
    values = {
      # You can add values here.
    }
  }

  assert {
    condition     = aws_instance.web.ami == "ami-12345"
    error_message = "Incorrect AMI ID passed to aws_instance.web: ${aws_instance.web.ami}"
  }
}

While this will not fully test the entire provisioning, it will highlight errors that may be caused by incorrectly connecting resources together without the need for an actual AWS account. Similarly, you can use override_module to override an entire module.

Providing feedback​

Thank you for taking the time to test this preview release. If you have any feedback, please use a GitHub issue or chat with us on the OpenTofu Slack.

• End-to-end state encryption protects your state file from prying eyes, no matter what storage backend you use. You can provide your encryption passphrase securely using environment variables, or use a key management system such as AWS KMS, GCP KMS, or OpenBao. This feature has been developed in collaboration with Stephan Bartels (Interhyp) and Alex Scheel from the OpenTofu community, whom we would like to thank for their work on this feature.
• Dynamic provider-defined functions let a provider not only provide resources, but also native functions you can use in your OpenTofu code. What's more, we added an OpenTofu-only feature to let providers dynamically define custom functions based on your configuration. This enhancement allows you to fully integrate other programming languages as shown in our live stream. You can try out this functionality with our experimental Lua and Go providers.
• The removed block lets you mark OpenTofu-created resources for removal from the state file, but still keep the infrastructure you created.
• Loopable import blocks let you bulk-import resources declaratively in your OpenTofu code, helping with large-scale migrations.

As with the previous version, OpenTofu remains a drop-in replacement for its predecessor Terraform™ 1.5 and has easy migration paths from later versions. Check out the overhauled migration guides for detailed migration instructions. You can find the full list of changes and comprehensive examples in the documentation.

The OpenTofu community grew significantly​

Since the first release, the OpenTofu community and adoption have been growing significantly. While we don't believe in tracking our users and don't have accurate numbers, we have seen a constant month-over-month growth in our registry usage since our launch only 4 months ago. Over just the last month our registry usage has more than doubled to well over a million requests per day.

Additionally, we had 65 unique contributors for this release alone and have recently reached 20,000 stars on GitHub. Since January, we have seen our community spread the word about OpenTofu, open over 200 new issues and file even more pull requests.

What is OpenTofu anyway?​

If you are new to OpenTofu, welcome! We started as a fork of HashiCorp's Terraform™ after its license was changed to the restrictive BUSL alongside a frequently changing licensing FAQ. OpenTofu is an infrastructure-as-code tool that lets you declaratively create cloud infrastructure with thousands of APIs by writing your own code or using one of the tens of thousands of community-provided modules.

For example, you could create an EC2 instance on AWS like this:

resource "aws_instance" "web" {
  ami           = "add AMI ID here"
  instance_type = "t3.micro"
}

OpenTofu's main advantage is that it records any changes to your cloud infrastructure in a state file, which allows it to later modify the same infrastructure, or tear it down if you created it as a test.

The future and beyond: OpenTofu 1.8 is waiting​

OpenTofu is first and foremost a community-driven project. We are looking forward to the continued tradition of working on issues the community deems important. For transparency and to encourage everyone to vote, we have created a list of the most upvoted issues.

While much of OpenTofu 1.8 is still in planning, we are currently finalizing a proposal for a feature that lets you use variables as module sources, backend configuration, and more. Early evaluation of variables has been requested in over 30 issues so far and is one of the most-requested features in OpenTofu.

If you have a feature you would like to see in OpenTofu, please don't hesitate to open an issue or reach out to us on Slack.

As with the alpha version, we did everything we could to test this version and would like to ask for the help of the community to help us test this version on non-production workloads. Grab your copy on GitHub and let us know what you think using a GitHub issue.

Downloading the beta release​

The beta release is available exclusively from the GitHub Releases page. Please select the appropriate file for your platform. Here are some quick links:

For the releases above, please unpack the archive and you should find the tofu binary inside. You can also use the standalone installer to download the release with signature verification.

Provider-defined functions​

The new Terraform Plugin SDK added support for provider-defined functions that you can use directly in OpenTofu. This is a significant improvement over using data sources as provider-defined functions don't increase the size of your state file and require less code to write.

If you want to test provider-defined functions, you can use the corefunc provider by Ryan Parman:

terraform {
  required_providers {
    corefunc = {
      source = "northwood-labs/corefunc"
      version = "1.4.0"
    }
  }
}

provider "corefunc" {
}

output "test" {
  value = provider::corefunc::str_snake("Hello world!")
  # Prints: hello_world
}

Loopable import blocks​

We made several improvements to the declarative import blocks, most prominently you can now use the for_each instruction on the block. We have prepared a full documentation for this feature.

In previous OpenTofu versions, you could already use the import block to declaratively import resources, for example:

resource "random_id" "test_id" {
  byte_length = 8
}

import {
  to = random_id.test_id
  id = "Y2FpOGV1Mkk"
}

output "id" {
  value = random_id.test_id.b64_url
}

In this new version you can now also declaratively import resources in a loop:

variable "server_ids" {
  type = list(string)
}

resource "random_id" "test_id" {
  byte_length = 8
  count = 2
}

import {
  to = random_id.test_id[tonumber(each.key)]
  id = each.value
  for_each = {
    for idx, item in var.server_ids: idx => item
  }
}

output "id" {
  value = random_id.test_id.*.b64_url
}

The example above will let you specify some random IDs from a variable, and let others be automatically generated.

State encryption​

State encryption is one of the flagship features of this release. We have prepared a full documentation for this feature. Since the alpha release we overhauled the migration process from unencrypted to encrypted state files and the rollback mechanism to make the syntax more explicit.

Before you test this feature, please make a backup of your state file. You can then add the following block to enable state encryption:

terraform {
  encryption {
    key_provider "pbkdf2" "my_passphrase" {
      ## Enter a passphrase here:
      passphrase = ""
    }

    method "aes_gcm" "my_method" {
      keys = key_provider.pbkdf2.my_passphrase
    }

    ## Remove this after the migration:
    method "unencrypted" "migration" {
    }

    state {
      method = method.aes_gcm.my_method

      ## Remove the fallback block after migration:
      fallback{
        method = method.unencrypted.migration
      }
      ## Enable this after migration:
      #enforced = true
    }
  }
}

You can migrate back using the following syntax:

terraform {
  encryption {
    key_provider "pbkdf2" "my_passphrase" {
      ## Enter a passphrase here:
      passphrase = ""
    }

    method "aes_gcm" "my_method" {
      keys = key_provider.pbkdf2.my_passphrase
    }

    method "unencrypted" "migration" {
    }

    state {
      method  = method.unencrypted.migration
      enforced = false
      fallback{
        method = method.aes_gcm.my_method
      }
    }
  }
}