OpenTofu Release Notes

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

OpenTofu v1.11.0 release notes

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

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:

[Code Block with example variables, resources, and modules using the enabled meta-argument]

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

Original source

OpenTofu 1.11.0

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

Highlights

This release cycle introduces major new capabilities and integrations:

Ephemeral Values and Write Only Attributes

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

The enabled Meta-Argument

If you want to conditionally deploy a resource, you no longer have to use count = var.create_my_resource ? 1 : 0, you can now add the new enabled meta-argument to your resource to conditionally deploy it.

Compatibility Notes

• macOS: Requires macOS 12 Monterey or later
• 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
• -var / -var-file during tofu apply :
  • Since ephemeral variables values cannot be saved into the plan, now we allow using -var / -var-file during tofu apply to pass again the values for ephemeral variables during apply
  • This new functionality allows -var / -var-file to be used with non-ephemeral variables too, but it will error if the values given for this type of variables is different from the ones given during the plan creation
  • TF_VAR values should stay consistent between plan and apply to avoid the errors mentioned above

Reference

• Full Changelog
• Blog Post

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

Original source