OpenTofu Release Notes

SECURITY ADVISORIES

This release contains fixes for some security advisories related to previous releases in this series.

• tofu init in OpenTofu v1.10.6 and earlier could potentially use unbounded memory if there is a direct or indirect dependency on a maliciously-crafted module package distributed as a "tar" archive.
  This would require the attacker to coerce a root module author to depend (directly or indirectly) on a module package they control, using the HTTP, Amazon S3, or Google Cloud Storage source types to refer to a tar archive.
  This release incorporates the upstream fixes for CVE-2025-58183.
• When making requests to HTTPS servers, OpenTofu v1.10.6 and earlier could potentially use unbounded memory or crash with a "panic" error if TLS verification involves an excessively-long certificate chain or a chain including DSA public keys.
  This affected all outgoing HTTPS requests made by OpenTofu itself, including requests to HTTPS-based state storage backends, module registries, and provider registries. For example, an attacker could coerce a root module author to depend (directly or indirectly) on a module they control which then refers to a module or provider from an attacker-controlled registry. That mode of attack would cause failures in tofu init , at module or provider installation time.
  Provider plugins contain their own HTTPS client code, which may have similar problems. OpenTofu v1.10.7 cannot address similar problems within provider plugins, and so we recommend checking for similar advisories and fixes in the provider plugins you use.
  This release incorporates upstream fixes for CVE-2025-58185, CVE-2025-58187, and CVE-2025-58188.

BUG FIXES

• Fix crash in tofu test when using deprecated outputs (#3249)
• Fix missing provider functions when parentheses are used (#3402)
• for_each inside dynamic blocks can now call provider-defined functions. (#3429)

Full Changelog: v1.10.6...v1.10.7

Original source Report a problem

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.

Warning
Do not test this release on production projects! This is not a stable release.

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

• Windows (64-bit): tofu_1.11.0-beta1_windows_amd64.zip
• macOS (Apple Silicon): tofu_1.11.0-beta1_darwin_arm64.tar.gz
• macOS (Intel): tofu_1.11.0-beta1_darwin_amd64.tar.gz
• Linux (AMD64): tofu_1.11.0-beta1_linux_amd64.tar.gz
• Linux (ARM64): tofu_1.11.0-beta1_linux_arm64.tar.gz

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 its 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 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 "enable_monitoring" {
  type    = bool
  default = true
}
resource "aws_cloudwatch_metric_alarm" "high_cpu" {
  alarm_name          = "high-cpu-usage"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 2
  metric_name         = "CPUUtilization"
  lifecycle {
    enabled = var.enable_monitoring
  }
}

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

Original source Report a problem

OpenTofu 1.10 brings major improvements to how you distribute and manage your infrastructure code, with OCI registry support, native S3 state locking, and enhanced observability through OpenTelemetry tracing.
This page will run you through the most important changes in OpenTofu 1.10:

• OCI Registry Support
• Native S3 State Locking
• OpenTelemetry Tracing (Experimental)
• Target and Exclude Files
• Global Provider Cache Lock
• Deprecation Support (Experimental)
• Enhanced moved and removed blocks
• External Key Providers
• Breaking Changes
• Smaller improvements
• Bugfixes

OCI Registry Support

OpenTofu can now use OCI (Open Container Initiative) registries to distribute both providers and modules, enabling you to use your existing container registry infrastructure for infrastructure-as-code components.

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/*/*"]
  }
}

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

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

This feature is particularly valuable for air-gapped environments and organizations that want to use their existing container registry infrastructure.

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

Native S3 State Locking

The S3 backend now supports native state locking without requiring DynamoDB, simplifying your infrastructure and reducing costs.

terraform {
  backend "s3" {
    bucket = "my-opentofu-state"
    key    = "prod/opentofu.tfstate"
    region = "us-east-1"
    use_lockfile = true # Enable native S3 locking
  }
}

This feature leverages S3's conditional writes to provide reliable state locking using only your S3 bucket. Migration from DynamoDB-based locking is straightforward, with support for dual locking during the transition period. See the S3 backend documentation for details.

OpenTelemetry Tracing (Experimental)

Debug and optimize your OpenTofu operations with built-in OpenTelemetry support. Tracing is disabled by default to ensure privacy.

Enable tracing by setting environment variables:

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

OpenTofu will then send traces to your configured collector (such as Jaeger or Grafana Tempo), helping you identify performance bottlenecks and debug complex operations. Learn more in the tracing documentation.

Please note that no telemetry data is sent to OpenTofu or any external service unless you explicitly configure it.

Target and Exclude Files

New -target-file and -exclude-file options allow you to manage resource targeting through version-controlled files:

tofu plan -target-file=targets/production.txt
tofu apply -exclude-file=excludes/experimental.txt

The file format is simple - one resource address per line with support for comments:

# Critical infrastructure components
module.networking.aws_vpc.main
module.networking.aws_subnet.public[*]

# Database infrastructure
module.database.aws_db_instance.primary

This feature is perfect for CI/CD pipelines, phased deployments, and team collaboration.

Global Provider Cache Lock

Concurrent OpenTofu operations can now safely share the provider cache, preventing corruption and conflicts in CI/CD environments and when using tools like Terragrunt.

Enable the global cache with:

export TF_PLUGIN_CACHE_DIR=/path/to/shared/cache

The filesystem-level locking ensures only one process can modify a provider at a time, while others wait gracefully. This makes the provider cache ready for large-scale parallel operations. You can find more information about using the global provider cache in the provider cache documentation.

Deprecation Support (Experimental)

Module authors can now mark variables and outputs as deprecated, helping users migrate to newer APIs gracefully:

variable "instance_type" {
  type       = string
  deprecated = "Use var.compute_type instead"
}
output "instance_ip" {
  value      = aws_instance.main.public_ip
  deprecated = "Use output.instance_details for more information"
}

Users will see clear warnings when using deprecated features, making module evolution more manageable.

Enhanced Moved and Removed Blocks

The moved block now supports migrating resources between different types, including built-in support for migrating from null_resource to terraform_data:

moved {
  from = null_resource.example
  to   = terraform_data.example
}

The removed block now supports lifecycle rules and provisioners:

removed {
  from = aws_instance.legacy
  lifecycle {
    destroy = false
  }
}

These enhancements make infrastructure refactoring more powerful and flexible. See the refactoring documentation for more details.

External Key Providers

State encryption now fully supports external key providers, allowing integration with your preferred secret management tools:

terraform {
  encryption {
    key_provider "external" "password_manager" {
      command = ["op", "read", "op://opentofu/stateencryption"]
    }
    method "aes_gcm" "state" {
      keys = key_provider.external.password_manager
    }
  }
}

You can also chain key providers for enhanced security. Learn more in the state encryption documentation.

Breaking Changes

Platform Requirements

• Linux: Now requires kernel 3.2 or later
• macOS: Now requires macOS 11 (Big Sur) or later
• Windows: More conservative symlink handling

Docker Image
The ghcr.io/opentofu/opentofu image is no longer supported as a base image. See building your own image for alternatives.

PostgreSQL Backend
The locking mechanism has changed. You should not use OpenTofu 1.10 in parallel with earlier versions when sharing the same PostgreSQL database because the locking implementation has changed. Mixing versions can lead to conflicting writes and could cause data loss.

Smaller improvements

• The element function now supports negative indices: element(list, -1) returns the last element
• New -concise flag for cleaner automation output
• PostgreSQL backend supports custom table names for multi-project setups
• HTTP backend now supports force-unlock
• Provider installation performance improvements
• Improved error messages for type conversion failures
• New built-in provider functions:
  • provider::terraform::decode_tfvars - Decode a TFVars file content into an object
  • provider::terraform::encode_tfvars - Encode an object into a string with TFVars format
  • provider::terraform::encode_expr - Encode an expression into valid OpenTofu syntax
• OpenTofu now recommends -exclude instead of -target in error messages about unknown values in count and for_each

Bugfixes

• Fixed provider name validation crash in provider_meta block
• PostgreSQL backend no longer fails on workspace creation for parallel returns
• Fixed null value handling in element, slice, and values functions
• Resolved state encryption issues with backend interactions
• Fixed import block generation improvements
• Better handling of provider installation errors
• Fixed dependency graph issues with import blocks

For a complete list of changes, see the full changelog.

Original source Report a problem

We are excited to announce the availability of Ephemeral and Write-Only features in the latest nightly builds of OpenTofu!
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.

Warning

Do not test this release on a production project! It is not a stable 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.

Original source Report a problem

UPGRADE NOTES

• Upgrade go from 1.24.4 to 1.24.6 to fix GO-2025-3849 (3127)
• Upgrade github.com/openbao/openbao/api/v2 from 2.1.0 to 2.3.0 to fix GO-2025-3783 (3134)
  • The upgrade is necessary to silence the security scanner and does not affect the actual state encryption provided by OpenBao.

BUG FIXES

• Variables with validation no longer interfere with the destroy process (#3131)
• Fixed crash when processing multiple deprecated marks on a complex object (#3105)
• When OpenTelemetry encounters errors, log it at the warning level instead of panic (#3235)

Full Changelog

v1.10.5...v1.10.6

Original source Report a problem