Terraform 1.6, released in October 2023, was the first version shipped under the new Business Source Licence. That change triggered, within days, the announcement of OpenTofu as a community fork backed by the Linux Foundation, branching from Terraform 1.5. Over a year later, with Terraform 1.9 in production and OpenTofu 1.8 stable, it is worth a calm review of what HashiCorp has been delivering, what the fork offers, and which additions actually matter in the daily life of a team writing declarative infrastructure.
What 1.6 actually changed
The headline feature of Terraform 1.6 was import blocks. Until then, importing an existing resource into state meant running terraform import from the CLI, remembering the exact provider ID, and then writing the corresponding resource block by hand. With declarative import, the plan shows what is going to be imported before any apply, the code is versioned in Git, and dozens of resources can be imported in a single review cycle. For teams inheriting infrastructure created in a console or with another tool, it is the difference between an afternoon of CLI commands and a reviewable pull request.
The other structural novelty in 1.6 was the native testing framework. Until that point, testing Terraform modules meant Terratest (Go), kitchen-terraform, or other external options. The native framework introduces .tftest.hcl files that describe run blocks with commands (plan or apply), test-specific variables, and assertions against outputs. It does not replace Terratest for real integration tests against a cloud provider, but it fills a huge gap: validating module logic without leaving HCL or learning Go. A typical test runs a plan against the VPC module and verifies that the generated CIDR matches what was expected, that the subnet count is correct, or that an optional flag changes the NAT type. Since 1.7 these tests run in parallel, which makes a broad suite viable in CI.
run "validate_vpc_cidr" {
command = plan
variables {
cidr_block = "10.0.0.0/16"
}
assert {
condition = module.vpc.cidr_block == "10.0.0.0/16"
error_message = "VPC CIDR does not match the supplied parameter"
}
}The useful bits of 1.7 and 1.8
Terraform 1.7 added the removed block, the conceptual counterpart of moved. It removes a resource from state declaratively, without destroying it, by writing a block that states the retired address. It is essential when migrating resources between modules, removing resources managed outside Terraform, or cleaning up state after large refactors. Previously that meant reaching for terraform state rm, an imperative command that leaves no trace in the code. Now the operation is reviewed in the plan and audited in the repository.
Version 1.8 brought provider-defined functions. Providers can export custom functions accessible via the syntax provider::<name>::function(...). The AWS provider, for example, publishes functions for parsing ARNs without brittle regular expressions. It is a useful step, but less transformative than import blocks: in practice, most teams still get by with built-in functions and local blocks.
1.8 also polished moved behaviour for refactoring resources without destroy-and-recreate, something that already existed but has gained better error messages when addresses do not match.
Ephemeral values and module validation in 1.9
The most interesting addition in Terraform 1.9, released in July 2024, is ephemeral values: values that materialise during plan or apply but are never written to the state file. The obvious use case is secrets: dynamically generated passwords, tokens pulled from Vault or AWS Secrets Manager, temporary credentials. Until now, even with sensitive = true, those values ended up encrypted inside state, with the risk that entails if the backend is compromised. With ephemeral, the value is consumed during the cycle and disappears. It does not solve every problem with secrets in IaC, but it reduces the exposure surface in a way that many have been asking for for years.
1.9 also tightened module input validation. Variables can refer to other variables in the same module inside validation rules, which allows cross-rule checks along the lines of “if parameter A is prod, parameter B must be set”. Not a flashy feature, but it removes an ugly pattern that used to force precondition blocks in outputs or external assertions.
Stacks: the feature that can shift patterns
As of late 2024, stacks is still in private preview on HCP Terraform. The promise is ambitious: a single module deployed across multiple environments with explicit cross-stack dependencies, coordinated orchestration, and a state model that understands the relationship between instances. If it delivers on that promise, it dramatically reduces the need for Terragrunt for the classic “deploy this module across three regions and twenty accounts” use case. GA and pricing remain to be seen, since the orchestration component lives inside HCP, and that conditions adoption in environments that prefer everything self-hosted.
OpenTofu: the fork is real
By December 2024, OpenTofu has a clear track record. It is drop-in compatible for most configurations, state is interchangeable, and providers work identically. The visible divergence lies in features such as native state file encryption (available in OpenTofu, absent in Terraform), provider-defined functions with a slightly different adoption curve, and the absence in OpenTofu of stacks and ephemeral values. The fork remains under MPL 2.0, which guarantees free software permanently.
For the vast majority of users, the BSL restricts nothing: it only affects anyone trying to build a commercial product competing with HashiCorp. The real impact has been psychological and political, not technical. Existing Terraform users have no urgent reason to migrate; new projects with licence sensitivity can pick OpenTofu without friction. The bigger medium-term concern is feature divergence: if stacks lands and only exists in Terraform, OpenTofu teams will need equivalent solutions, most likely leaning on Terragrunt or external orchestration.
What to watch and what to ignore
Of all the additions, the ones that genuinely change a team’s daily work are import blocks, the testing framework, the removed block, and ephemeral values. They are concrete improvements that solve real pain. The rest, including the HCP Terraform rename or the long tail of minor provider updates, affects little for anyone with a stable flow.
Stacks deserves monitoring because it may consolidate existing tooling, but it is still too early to make architectural decisions around it. And the Terraform vs OpenTofu choice boils down to three questions: do you have a contract with HashiCorp or HCP? do you need stacks or native state encryption? what does internal policy say about BSL? Those answers make the decision write itself, and both tools are going to stay usable for a long time.
