OpenTofu Release Notes

We're proud to announce that OpenTofu 1.12.0 is now officially available! 🎉

Highlights

This release cycle introduces major new capabilities and integrations:

Dynamic prevent_destroy

OpenTofu v1.12.0 now allows prevent_destroy to be defined dynamically in terms of other values available elsewhere in the same module. For example:

variable "prevent_destroy_database" {
  type = bool
  default = true
}
resource "example_database" "example" {
  # ...
  lifecycle {
    prevent_destroy = var.prevent_destroy_database
  }
}

Provider Checksum Improvements

The default provider installation behavior in OpenTofu is designed to mostly "just work" by getting the needed providers installed and making the necessary changes to the dependency lock file, but in previous versions friction appeared for any teams using many of the non-default installation settings such as the shared provider plugin cache, or local mirrors of upstream providers.

For OpenTofu v1.12, OpenTofu Registry now provides a full set of official checksums in all of the checksum formats needed by other installation methods. This means that after running tofu init the dependency lock file will immediately have all of the information required to successfully use a global plugin cache directory and to verify matching packages served from a local mirror, without needing to run tofu providers lock separately.

Simultaneous Human-readable and Machine-readable Output

Many OpenTofu commands support both human-oriented UI output and machine-readable JSON output, but previously those commands could be run with only one or the other. This was bothersome for those implementing alternative UIs in terms of the machine-readable output because it meant they would need to implement all possible features of the UI before their tool could actually be used.

OpenTofu v1.12.0 introduces a new option -json-into=FILENAME, which produces the same output format that -json would have produced but sends that output to the given filename instead of to the standard output stream. The OpenTofu UI output then appears on the standard output stream as normal, so that software interpreting the JSON output can behave as just a supplement to the normal UI rather than a complete replacement.

New destroy lifecycle meta-argument

New destroy lifecycle meta-argument

The new destroy = false lifecycle option for managed resources allows removing an object from the state without first destroying the remote object.

Deprecation Notices

WinRM for Provisioners is Now Deprecated

Some of the Go libraries that OpenTofu uses for WinRM connection support in provisioners have become unmaintained over time, and so unfortunately we are phasing out support for WinRM in OpenTofu starting with deprecation warnings in this release.

If your configuration includes a connection block with type = "winrm" then OpenTofu v1.12 will warn that this connection type is deprecated, but provisioning should otherwise still work as it did before.

We intend to remove WinRM support completely in the forthcoming OpenTofu v1.13 series, and so if you are currently relying on WinRM support we recommend that you begin planning to migrate to using OpenSSH for Windows instead.

Phasing Out Support for 32-bit CPU Architectures

We are also planning to stop producing official releases for 32-bit CPU architectures (386 and arm) in a future version of OpenTofu. Support for 64-bit architectures (amd64 and arm64) is unaffected.

OpenTofu v1.12 does not include any changes to CPU support yet, but we expect that the official builds in the forthcoming v1.13 series will begin producing warnings when running on 32-bit CPU architectures, before we stop producing those packages altogether in a future release series.

Compatibility Notes

• macOS: Requires macOS 12 Monterey or later
• The OPENTOFU_USER_AGENT environment variable, which allowed fully overriding the default User-Agent header on all HTTP requests, has been removed.
• On Unix systems OpenTofu now considers the BROWSER environment variable as a possible override for the default behavior for launching a web browser. If you run OpenTofu in a context where an environment variable of that name is already set, it may cause OpenTofu to now open a web browser in a different way than previous versions would have. Unsetting that environment variable will restore the previous platform-specific behavior.

Reference

• Full Changelog
• Blog Post

Thank you for your continued support and testing of the OpenTofu project!

Original source

Today we've released OpenTofu v1.12.0, collecting together several months of work from the OpenTofu community, including several new features.

The following are highlights from the new release:

• Dynamic prevent_destroy: The prevent_destroy argument in a resource's lifecycle block can now refer to other symbols within the same module, such as input variables.
• Improved provider checksum handling: tofu init now automatically includes a full set of checksums for all platforms using both zh: and h1: hashes, reducing the need for manually running tofu providers lock.
• Simultaneous output formats: The new -json-into=FILENAME CLI option allows saving machine-readable output to a separate file while still producing human-readable output in the terminal.
• New destroy lifecycle meta-argument: The new destroy = false lifecycle option for managed resources allows removing an object from the state without first destroying the remote object.
• Provider installer performance: Provider installation now performs concurrent requests for faster tofu init completion when many providers are needed.

For full details on the changes in this release, refer to the OpenTofu v1.12.0 release notes.

There are also some deprecations that might be relevant to you:

• WinRM for provisioners is deprecated
• Phasing out official builds for 32-bit CPU architectures

prevent_destroy can now be set dynamically

The prevent_destroy lifecycle argument for managed resources tells OpenTofu that it should return an error if the plan for a particular object involves destroying it. Authors tend to use this feature for infrastructure objects that whose deletion would cause large disruption, or when faithfully recreating that object would require manual action outside of OpenTofu such as restoring a backup.

Unfortunately this setting previously required making a static decision that's hard-coded into the configuration, which is annoying for shared modules that might be used in multiple different environments that have different needs. For example, it's common to want to make it very hard to destroy a production database while still allowing the equivalent database in a development environment to be easily replaced when necessary.

OpenTofu v1.12.0 now allows prevent_destroy to be defined dynamically in terms of other values available elsewhere in the same module. For example:

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

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

  lifecycle {
    prevent_destroy = var.prevent_destroy_database
  }
}

A module containing the above would prevent deletion of the database by default, but when used in a development environment you could set prevent_destroy_database = false in the module block to disable that constraint.

This is the first of several other lifecycle-related settings we're hoping to make more dynamic in future versions of OpenTofu. We started with this one because the design questions for it had relatively straightforward answers. The others each have their own design challenges we need to overcome, and if you're interested you can find out more in the umbrella issue #1329.

Provider Checksum Improvements

The default provider installation behavior in OpenTofu is designed to mostly "just work" by getting the needed providers installed and making the necessary changes to the dependency lock file, but in previous versions friction appeared for any teams using many of the non-default installation settings such as the shared provider plugin cache, or local mirrors of upstream providers.

For OpenTofu v1.12, OpenTofu Registry now provides a full set of official checksums in all of the checksum formats needed by other installation methods. This means that after running tofu init the dependency lock file will immediately have all of the information required to successfully use a global plugin cache directory and to verify matching packages served from a local mirror, without needing to run tofu providers lock separately.

The tofu providers lock command is now needed only in the situation for which it was originally intended: populating the dependency lock file with the official checksums from origin registries on systems where tofu init has been reconfigured to use an alternative installation source. As long as your CLI configuration allows tofu init to install providers directly 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 will 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.

Simultaneous Human-readable and Machine-readable Output

Many OpenTofu commands support both human-oriented UI output and machine-readable JSON output, but previously those commands could be run with only one or the other. This was bothersome for those implementing alternative UIs in terms of the machine-readable output because it meant they would need to implement all possible features of the UI before their tool could actually be used.

OpenTofu v1.12.0 introduces a new option -json-into=FILENAME, which produces the same output format that -json would have produced but sends that output to the given filename instead of to the standard output stream. The OpenTofu UI output then appears on the standard output stream as normal, so that software interpreting the JSON output can behave as just a supplement to the normal UI rather than a complete replacement.

For commands that produce streaming JSON output describing a series of ongoing events, you can optionally specify the path to an operating system IPC object such as a named pipe or a /dev/fd/N special device node so that your software can consume that JSON output concurrently with OpenTofu's execution, such as if you want to update a web UI or terminal UI responsively to report ongoing progress.

Download and Install

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

For more information, refer to our installation guides.

Deprecation Notices

WinRM for Provisioners is Now Deprecated

Some of the Go libraries that OpenTofu uses for WinRM connection support in provisioners have become unmaintained over time, and so unfortunately we are phasing out support for WinRM in OpenTofu starting with deprecation warnings in this release.

If your configuration includes a connection block with type = "winrm" then OpenTofu v1.12 will warn that this connection type is deprecated, but provisioning should otherwise still work as it did before.

We intend to remove WinRM support completely in the forthcoming OpenTofu v1.13 series, and so if you are currently relying on WinRM support we recommend that you begin planning to migrate to using OpenSSH for Windows instead.

Phasing Out Support for 32-bit CPU Architectures

We are also planning to stop producing official releases for 32-bit CPU architectures (386 and arm) in a future version of OpenTofu. Support for 64-bit architectures (amd64 and arm64) is unaffected.

OpenTofu v1.12 does not include any changes to CPU support yet, but we expect that the official builds in the forthcoming v1.13 series will begin producing warnings when running on 32-bit CPU architectures, before we stop producing those packages altogether in a future release series.

If you are currently running OpenTofu on a 32-bit CPU architecture we recommend beginning to plan migration to a 64-bit architecture instead. If you don't expect to be able to complete that migration at some point in the next year, please tell us about your situation in issue #3912.

Original source

BUG FIXES

• Running tofu apply -refresh-only with a configuration that contains ephemeral resources does not fail anymore because the refresh produced changes (#3776)
• Fixed tofu init crashing when a module version uses a variable and the module is referenced from a test file. (#3686)
• Fixed provider-defined functions in import block id expressions causing "BUG: Uninitialized function provider" error. (#3803)
• tofu test no longer fails during cleanup when using a mocked version of a resource type with write-only attributes. (#3964)
• A malicious remote TLS server can no longer deadlock OpenTofu by sending multiple key update messages in a single record. (#3966)
• When installing module packages from "tar" archives, OpenTofu now accepts only a limited number of sparse file entries to avoid unbounded memory usage from maliciously-crafted archives containing many sparse regions. (#3966)

Full Changelog: v1.11.5...v1.11.6

Original source

We've now published the first beta release of OpenTofu 1.12.0. For this cycle we intentionally worked mainly on smaller enhancements and fixes, since it's otherwise easy for those to get left behind when we prioritize larger features. Nonetheless, there are some commonly-requested improvements here that we hope you'll enjoy.

Warning

Do not use OpenTofu prereleases in production environments!

Download and Installation

Download the appropriate package for your platform:

Platform Release Package macOS (Apple Silicon) tofu_1.12.0-beta1_darwin_arm64.zip Linux (AMD64) tofu_1.12.0-beta1_linux_amd64.zip Linux (ARM64) tofu_1.12.0-beta1_linux_arm64.zip Windows (AMD64) tofu_1.12.0-beta1_windows_amd64.zip

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 strong 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!

Original source

SECURITY ADVISORIES

• No limit on number of query string arguments in net/url's ParseQuery

This release incorporates the upstream fixes for GO-2026-4341.

• crypto/tls handling of multiple messages that span across encryption level boundaries

This release incorporates the upstream fixes for GO-2026-4340.

BUG FIXES

• Using a network mirror for the providers source does not print debug logs without being asked for (#3736)

Full Changelog: https://github.com/opentofu/opentofu/blob/0de30e8050bc32dfada2c4c978e736239e0ab265/CHANGELOG.md

Original source

SECURITY ADVISORIES:

• Previous releases in the v1.11 series could potentially take an excessive amount of time processing a maliciously-crafted .zip archive during either provider or module installation during tofu init. (#3689)

BREAKING CHANGES:

• Modules containing local provider configurations now also reject the enabled argument, matching existing behavior for count, for_each, and depends_on. (#3680)

BUG FIXES:

• In JSON syntax, the state encryption method configuration now allows specifying keys using both normal expression syntax and using template interpolation syntax. Previously only the template interpolation syntax was allowed, which was inconsistent with other parts of the encryption configuration. (#3654)
• Providers are not configured anymore with DeferralAllowed capability of OpenTofu since having that created unwanted behaviour from some providers. (#3676)
• Resources containing write-only attributes now are rendered consistently during planning. (#3667)

Full Changelog: v1.11.3...v1.11.4

Original source

Background

With the latest nightly build of OpenTofu, we have included support for producing both the human readable and machine readable outputs simultaneously.

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

Warning

Do not test this release on a production project! It is not a stable release!

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

Original source

UPGRADE NOTES

• The change from #2643, that was announced previously in v1.11.0, has been reverted in this release. OpenTofu will no longer directly recommend using the -exclude= option to work around problems caused by unknown values in provider configurations.

• Unfortunately there are existing providers that spuriously report that they cannot plan due to unknown values even when planning would have been successful, and so we cannot rely on providers to accurately signal when unknown values are the cause of an error. Using -exclude is still a valid workaround for these problems even though OpenTofu cannot accurately detect when it's useful to make that suggestion.

BUG FIXES

• Fix crash in plan -generate-config-out with read-only nested attributes (#3553)
• It's now possible again to plan changes with the hashicorp/helm and hashicorp/kubernetes providers when the provider configuration contains unknown values, as long as the configuration is carefully written to avoid the plan phase actually depending on those values. (#3592)
• When running tofu init on Windows with an azurerm backend, the subscription_id is quoted correctly allowing successful authentication. (#3602)
• Fix serialization error in apply when using cloud backend (#3611)

Full Changelog: v1.11.1...v1.11.2

Original source

What's new in OpenTofu 1.11?

New features

Ephemeral Resources / 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.
You can now declare input variables and output values as being ephemeral, and you can use provider plugins that have been updated to include ephemeral resource types (e.g. for fetching a secret) or managed resource types with write-only attributes (e.g. for setting a password without saving it in OpenTofu state).
For more information, refer to Ephemerality.

Enabled meta-argument

The new enabled meta-argument offers an alternative to the existing count and for_each meta-arguments for situations where a particular resource instance or module instance has either zero or one instances.
The initial form of this argument is nested inside a lifecycle block, rather than directly inside a resource or module declaration, to avoid conflicting with existing input variables or resource type arguments named enabled.
For more information, refer to the enabled meta-argument.

Improvements to existing features

• Tag support added to 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.

Deprecations

• 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

Full Changelog

You can find the full changelog at https://github.com/opentofu/opentofu/blob/v1.11/CHANGELOG.md

Original source