Written by Nelson Koning
on 

OpenTofu 1.10 for Terraform Users: What’s New, Why It Matters, and How to Get Started

If you’ve heard people say “OpenTofu is Terraform, but truly open,” you’re not far off. OpenTofu began as a community fork after Terraform moved to a non‑open‑source license; it’s now stewarded by the Linux Foundation and developed in the open. Think of it like swapping the needle on a record player: the music (your HCL, modules, and providers) still plays, but the ecosystem and upgrade path are now community‑governed and open. (opentofu.org)

The recent OpenTofu 1.10 release is a big deal for day‑one users and veteran Terraform hands alike. It adds practical capabilities like distributing providers/modules via OCI registries, native S3 state locking without DynamoDB, and opt‑in OpenTelemetry tracing—quality‑of‑life changes you’ll feel immediately in real pipelines. (opentofu.org)

Below is a concise, hands‑on intro to OpenTofu with enough context to confidently try it on a small project or start planning a migration.

The one‑minute backstory

What’s new in 1.10 that you’ll feel on day one

Here are the headline features through a newcomer’s lens:

Bonus from 1.9 you might have missed: provider for_each, which lets you dynamically spin up per‑region provider instances for multi‑region builds with less boilerplate. (opentofu.org)

Compatibility snapshot: “Will my code work?”

Quickstart: a tiny OpenTofu project that shows the new stuff

Below we’ll combine four ideas you’ll likely use early: S3 backend with native locking, state encryption, provider iteration across regions, and a minimal resource.

1) Backend with native S3 locking

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

This relies on S3’s conditional writes to lock state safely. Check your S3‑compatible provider supports this behavior. (opentofu.org)

2) Enable state encryption at rest (end‑to‑end)

variable "state_passphrase" {
  description = "Strong passphrase used to derive encryption keys"
  type        = string
  sensitive   = true
}

terraform {
  encryption {
    // Derive keys from a passphrase via PBKDF2
    key_provider "pbkdf2" "kdf" {
      passphrase = var.state_passphrase
    }

    // AES-GCM encryption method
    method "aes_gcm" "m1" {
      keys = key_provider.pbkdf2.kdf
    }

    // Apply to state; you can also configure plan {} similarly
    state {
      method   = method.aes_gcm.m1
      enforced = true
    }
  }
}

OpenTofu added end‑to‑end state encryption in 1.7 and documents usage and operational caveats (e.g., key rotation). If you’re migrating an existing unencrypted state, use a fallback path during the first apply to re‑write state securely. (opentofu.org)

3) Provider iteration for multiple regions

variable "aws_regions" {
  description = "Map of regions to region-specific settings"
  type = map(object({
    vpc_cidr_block = string
  }))
}

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 5.0"
    }
  }
}

provider "aws" {
  alias    = "by_region"
  for_each = var.aws_regions
  region   = each.key
}

resource "aws_vpc" "private" {
  for_each   = { for r, cfg in var.aws_regions : r => cfg if cfg != null }
  provider   = aws.by_region[each.key]
  cidr_block = each.value.vpc_cidr_block
}

The docs cover the rules: use alias with for_each; select the provider instance in your resources; keep provider instances around long enough to destroy resources cleanly. (opentofu.org)

4) Optional: set an OCI mirror for providers

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

From then on, tofu init pulls providers from your mirror. You can also reference modules via oci:// sources directly. (opentofu.org)

Migrating from Terraform: a safe, short path

If you’re currently on Terraform, OpenTofu’s migration docs recommend a stepped approach that reduces surprises:

A good pilot migration is a small workspace (or a dev environment) with a familiar provider. Once you’re happy, roll the approach across modules. If you’re adopting state encryption at the same time, follow the fallback steps to avoid lockouts and keep a clean rollback plan. (opentofu.org)

Working with providers and the Registry

Observability and CI hygiene

A few practical tips

Why teams are picking OpenTofu

Balanced take: Terraform remains a capable tool, and many shops will run both during a measured transition. But if “remain open” and “reduce operational friction” are north stars, OpenTofu’s current momentum and community governance make it easy to trial—no grand rewrites required.

Where to go next

With a low‑risk pilot, you can hear the music play in a few hours: same HCL melody, new capabilities that keep you in tune with modern CI, security, and distribution needs—without changing the songbook.