The plan is still Terraform's best idea
Terraform describes desired infrastructure in HCL, asks provider plugins to read remote systems, builds a dependency graph, and produces a plan of proposed changes. An operator can inspect that plan before applying it. Configuration belongs in version control, so a resource change can move through the same review process as application code.
That workflow remains easy to explain and hard to replace in a large organization. A database, network, DNS record, repository setting, and monitoring resource can live in one graph even though different APIs own them. Terraform creates independent resources in parallel and orders dependent ones. Modules let a platform team package approved patterns for other teams.
The plan is only as trustworthy as its inputs. Provider behavior, configuration values, current state, and the remote API all affect what Terraform proposes. A saved plan can make review and apply refer to the same calculation, but teams still need access controls, state locking, drift policy, version pins, and a recovery process.
Core and providers are separate systems
This repository contains the CLI and graph engine. AWS, Azure, Google Cloud, GitHub, Kubernetes, and thousands of other integrations are provider plugins distributed elsewhere. terraform init resolves and downloads the providers declared by a configuration, while the lock file records selected versions.
That separation keeps core from becoming a collection of vendor clients. It also means Terraform health does not guarantee provider quality. Each provider has its own releases, maintainers, schema changes, bugs, and upgrade notes. A team should evaluate the providers it will depend on, pin acceptable ranges, commit the dependency lock file, and test module upgrades in a non-production account.
State is the other half of operation. Terraform uses it to associate declared resource addresses with remote objects and stored attributes. Local state is convenient for learning. Shared work needs a backend with access policy, locking where supported, backup, and recovery. State and plans may contain operationally sensitive values, so they belong in controlled storage rather than casual build artifacts.
What happened when we ran it
We cloned commit 883c722 into an unprivileged Debian container with 3 CPUs, 8 GB of RAM, no secrets, and Go 1.24. The checkout had 5,447 files, about 695,694 lines of source, and occupied 26.5 MB. It contained 11 CI workflow files and a Dockerfile. There was no top-level tests directory, which is normal for a Go project whose tests sit beside packages.
Installation succeeded in 162 seconds and downloaded 562 packages. The build succeeded in 217 seconds. These results confirm that core compiled in the clean lab environment without provider credentials or cloud accounts.
The test command failed with exit code 1 after 482 seconds. The go test summary reported 101 passed and 1 failed out of 102. Its final lines showed successful results for packages such as internal/terminal, internal/terraform, internal/tfdiags, tools/defect-detector, and version, then the overall FAIL. The failed package and error were outside the supplied tail, so we cannot say what broke.
Licensing changes the shortlist
Terraform core version 1.6.0 and later uses the Business Source License 1.1. The additional use grant permits production use unless the software is offered to third parties on a paid hosted or embedded basis as a competitive offering that significantly overlaps IBM's paid versions. Internal organizational use is explicitly outside that definition. Each version changes to MPL 2.0 after four years under the stated license parameters.
Most infrastructure teams using Terraform internally can operate within that grant. Vendors, managed-service builders, and products embedding Terraform need a careful license review. This is a concrete reason to walk away, not a philosophical footnote. OpenTofu preserves a closely related workflow under MPL 2.0 and has become the first comparison for organizations that require an open-source core.
Pulumi offers a different authoring choice, using familiar programming languages. Crossplane moves infrastructure into Kubernetes reconciliation. Ansible is better matched to procedural host configuration. None is a drop-in answer for every Terraform estate, but greenfield teams should choose the operating model and license before their module library becomes expensive to move.
Maintenance is current and conservative
Terraform was pushed on August 26, 2026, and release v1.16.0 arrived that day. It added import blocks inside modules, JSON output for state show and workspace list, and a Linux s390x binary. GitHub showed 1,917 open issues and pull requests combined, with current work on imports, state migration, plans, policy, and module installation.
Issue 39047 reports terraform init hanging when it reuses a cached Git module without a manifest version, including reproduction on the latest release. Issue 39026 tracks a flaky JSON plan test whose expected elapsed duration can change. These reports are specific, active, and surrounded by related fixes, which is healthier than a quiet tracker. They also support the usual advice: pin versions, test upgrades, and keep an escape path for initialization or state problems.
Terraform is still a strong tool when a team wants declarative provisioning, broad providers, reviewable plans, and a mature module culture. The correct default for an existing estate may be to stay. For a new platform, compare OpenTofu and Pulumi first, then choose with licensing, state operations, and team skills in view rather than repository popularity.