OpenTofu 1.12: Why Infrastructure as Code Just Got More Practical

When the OpenTofu project launched in 2023 as a community-driven fork of Terraform, it was essentially a drop-in replacement with a different license. Two and a half years later, the picture looks very different. With OpenTofu 1.12.0 released earlier this month — alongside a mature 1.10 and 1.11 series — the project has accumulated enough unique features and quality-of-life improvements that it’s worth looking at what you’re missing if you haven’t switched yet.

Let’s walk through the most impactful changes from the last three major releases and see how they change day-to-day infrastructure work.

Dynamic `prevent_destroy`: Environment-Aware Safety Nets

The prevent_destroy lifecycle argument has always been a blunt instrument. You could protect a resource from accidental deletion, but you had to hardcode the decision into your configuration. That’s fine for a single environment, but painful for shared modules that serve production, staging, and development simultaneously.

OpenTofu 1.12.0 changes this: prevent_destroy can now reference variables and other symbols within the same module.

variable "environment" {
  type = string
}

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

resource "aws_rds_cluster" "main" {
  cluster_identifier = "app-${var.environment}"
  engine             = "aurora-postgresql"
  # ... other config ...

  lifecycle {
    prevent_destroy = var.prevent_destroy_database
  }
}

# In a dev workspace, pass prevent_destroy_database = false
# In production, leave the default (true) and sleep easy

This is the kind of improvement that doesn’t make headlines but removes real friction. Previously, teams worked around this limitation with wrapper scripts, terragrunt hooks, or simply living with the risk of accidentally destroying a dev database when the real concern was production. Now the configuration itself can express the intent cleanly.

The `destroy = false` Lifecycle: Clean State Removal

Also new in 1.12.0: a destroy lifecycle meta-argument. When set to false, OpenTofu will remove the resource from state without actually destroying the remote object. This is similar to terraform state rm, but declarative and plan-safe.

resource "aws_s3_bucket" "migration_artifacts" {
  bucket = "legacy-migration-artifacts"

  lifecycle {
    # We're decommissioning this bucket from IaC management,
    # but the data needs to remain in S3 for compliance reasons.
    destroy = false
  }
}

The next tofu plan will show the resource being removed from state, but the S3 bucket itself stays intact. This is particularly useful during migrations, decommissioning workflows, or when handing off a resource to another team’s state file.

Lock File Friction Is (Mostly) Gone

If you’ve ever managed dependency lock files in a cross-platform team — developers on macOS, CI on Linux, maybe some ARM build agents — you’ve probably run the tofu providers lock command more times than you’d like. The lock file would only contain checksums for the platform that last ran tofu init, forcing the next person on a different OS to re-lock.

OpenTofu 1.12.0 fixes this at the registry level. The OpenTofu Registry now serves both zh: and h1: hash formats for all platforms. When you run tofu init, the lock file is populated with checksums for every supported platform in one shot.

# .terraform.lock.hcl after tofu init on v1.12.0
# Note the full set of h1: hashes — no more per-platform re-locking

provider "registry.opentofu.org/hashicorp/aws" {
  version     = "5.92.0"
  constraints = "~> 5.0"
  hashes = [
    "h1:abc123...",   # amd64 linux
    "h1:def456...",   # arm64 linux
    "h1:ghi789...",   # amd64 darwin
    "h1:jkl012...",   # arm64 darwin
    "zh:abc123...",   # and the zh: equivalents
    # ... full platform coverage
  ]
}

For most teams, this eliminates the need for tofu providers lock entirely. The command still exists for air-gapped environments using local mirrors, but standard registry users get cross-platform lock files for free.

Simultaneous JSON and Human-Readable Output

The new -json-into=FILENAME flag in 1.12.0 solves a long-standing problem for CI/CD integrations and custom tooling. Previously, you had to choose: run tofu plan with -json for machine-readable output, or without it for human-readable output. You couldn’t have both.

# CI pipeline: humans see the plan, machines parse the JSON
tofu plan -json-into=/tmp/plan-output.json

# The terminal shows the normal colorized plan
# /tmp/plan-output.json contains the full machine-readable stream

For streaming outputs (like tofu apply), you can also pipe to a named pipe or /dev/fd/N for real-time consumption by a monitoring dashboard. This is a small but significant enabler for teams building internal developer platforms on top of OpenTofu.

Faster Provider Installation

Provider installation in 1.12.0 now uses concurrent HTTP requests. If your configuration pulls in a dozen providers (AWS, GCP, Azure, Kubernetes, Helm, random, TLS, local, null, etc.), tofu init downloads them in parallel rather than sequentially. Combined with optimized checksum verification and schema loading — the tool no longer verifies checksums for cached providers that aren’t needed by the current command — cold start times drop noticeably.

Features From Earlier Releases Worth Knowing

While 1.12.0 is the newest, a few features from the 1.10 and 1.11 series deserve attention if you’re catching up:

Ephemeral values and write-only attributes (1.11): Mark sensitive data like API keys and database passwords as ephemeral so they’re never persisted in state or plan files. Write-only attributes let you pass secrets to resources without them ever appearing in the state.
The enabled meta-argument (1.11): A cleaner alternative to count = var.feature_enabled ? 1 : 0. Write enabled = var.feature_enabled directly on resources and modules.
State encryption (1.7+): OpenTofu supports encrypting state files at rest using multiple key providers including AWS KMS, GCP KMS, Azure Key Vault, and OpenBao. This was available before Terraform added similar functionality.
Pretty-printed JSON state (1.12): The local backend now writes human-readable, pretty-printed JSON state files, making diffs readable when state is tracked in version control.

Should You Switch?

If you’re still on Terraform, migration is straightforward. OpenTofu is command-compatible — swap terraform for tofu in your scripts and you’re running. The state file format is identical. The provider ecosystem is the same (OpenTofu Registry mirrors the Terraform Registry, and you can configure fallback to the HashiCorp registry if needed).

The meaningful differences at this point are in the quality-of-life features. Dynamic prevent_destroy, the destroy lifecycle argument, ephemeral values, the enabled meta-argument, state encryption, and improved lock file handling are all OpenTofu-first innovations. They’re the kind of improvements that compound over time — each one small on its own, but together they make the daily workflow noticeably smoother.

The project has nearly 29K GitHub stars, an active community, and a predictable release cadence. Fidelity Investments shared their migration story publicly. The Linux Foundation governance provides long-term stability guarantees that individual corporate licensing decisions can’t match.

If nothing else, install OpenTofu alongside your existing Terraform setup and run your next tofu plan. The output will look familiar. The improvements will add up.

Dynamic prevent_destroy: Environment-Aware Safety Nets

The destroy = false Lifecycle: Clean State Removal