Review the workflow and the operating responsibilities
Terraform gives infrastructure teams a proposed change to review before applying it. The README describes configuration that can be versioned and reused, an execution plan showing proposed actions, and a resource graph that permits independent changes to run in parallel. Those are documented capabilities; our recorded run did not exercise them against infrastructure.
The decision also includes licensing, provider selection, and state ownership. Existing users should evaluate those requirements against their actual configurations. New adopters should settle them before treating a successful core setup step as evidence that their deployment workflow works.
What our recorded run establishes
Our stored run began on October 2, 2026, at 03:51:42.721 UTC, using commit 0abcc9a9abb9519da53fb47422efec6f88dcf502. This is an existing sandbox record, not a new execution or a test of release v1.16.5.
The step labeled install exited 0 after 121 seconds. The dependency summary recorded 570 packages. Its retained output was go: downloading go1.26.8 (linux/amd64). Completing that step does not establish that Terraform was installed or that its binary ran.
The harness marked the build step successful after 370 seconds, with exit 0 and retained output vet-exit:0. The supplied record does not include the exact command, a binary path, or an executable check. Reported build-step success therefore has a narrower meaning than a verified usable CLI.
The test step, identified as go test, exited 1 after 487 seconds. The parser recorded 182 successful package results and 2 failed package results, with a reported total of 184 for those two categories. It separately recorded 56 package results without tests. None of these figures is an individual-test count. Unique, exhaustive package coverage was not verified through complete-log reconciliation.
The retained tail contains successful package results, including internal/terraform, internal/tfdiags, tools/defect-detector, and version, followed by FAIL. It omits the failed package names and diagnostics. We cannot identify the cause, connect it to a reported upstream issue, or infer that Terraform itself is broken.
The configured environment had 3 CPUs, 8 GB of memory, and image golang:1.24-bookworm. The image name is not a runtime-version measurement. The download line records Go 1.26.8 being downloaded; it does not establish which toolchain every later command used. The checkout summary recorded 5,539 files, approximately 706,034 source lines, 26.8 MB, 11 CI workflow files, and a Dockerfile. The detector found no top-level tests directory, which says nothing about tests inside Go packages.
There is no recorded installed-binary check, provider-backed plan or apply, cloud deployment, security audit, or workload benchmark. These timings describe this sandbox's command steps, not infrastructure provisioning speed.
Core and providers need separate evaluation
The README says this repository contains the CLI and main graph engine. Providers are plugins, and Terraform can download those published on the Registry. The contribution guide also excludes HCP Terraform, Terraform Enterprise, and the Registry source from this repository.
A core result cannot establish whether a particular provider supports your resources or behaves correctly with your configuration. Identify the providers you need and evaluate a representative configuration in a disposable environment. For AWS-specific evaluation, the existing Terraform AWS Provider review addresses the provider rather than core. For pull-request execution, the existing Atlantis review addresses that separate workflow layer.
State needs an owner
HashiCorp's state documentation says Terraform stores bindings between remote objects and configured resource instances, then uses state to determine infrastructure changes. Local state needs no extra configuration, but the documentation warns that losing the file risks losing workspace state and that local storage limits collaboration.
For shared use, HashiCorp recommends HCP Terraform or a remote backend. It warns against storage without state locking and secure access control because of possible data loss or exposure of secrets in state. Decide who controls access, how state is backed up, and how recovery will work before applying shared infrastructure changes. These are operating recommendations, not controls verified by our run.
Read the license before choosing
The supplied license identifies Terraform Version 1.6.0 or later as the licensed work under Business Source License 1.1. Its additional use grant permits production use subject to restrictions on hosted or embedded competitive offerings. The definition covers paid offerings, including paid support arrangements, that significantly overlap IBM's paid versions. Internal organizational use, including affiliates under common control, is excluded from the competitive-offering definition.
The license lists a change date four years after publication of the licensed work and a change license of MPL 2.0. It applies separately to each version. Product vendors should check their intended offering against the actual terms rather than treating all commercial use as prohibited or all hosted use as permitted.
OpenTofu's supplied README lists MPL 2.0 and describes configuration, execution plans, and a resource graph. That makes it a relevant licensing and workflow comparison. The extract does not establish drop-in compatibility for an existing Terraform estate. Pulumi is relevant when language choice drives the decision: its README describes infrastructure programs using familiar language features. Neither alternative was run in this evaluation.
Release evidence is separate from the sandbox result
The supplied v1.16.5 release page shows a September 30, 2026 changelog heading and an October 2 publication entry. It lists two fixes: a crash involving tainted instance state without a valid status, and resource identity being nil during deletion. Those release notes do not diagnose the failures in our earlier October 2 sandbox run, and the recorded commit is not the release commit shown on that page.
The next useful step is to evaluate the exact Terraform version and providers you intend to deploy, using a representative configuration and an explicit state-recovery plan. Contributors should also capture complete baseline test output before attributing a failure to their changes.
How the ratings work
These are editorial evidence ratings, not benchmarks or adoption rankings. Each category uses a five-point scale: 1 means evidence is absent or shows a major unresolved obstacle; 2 means limited relevant evidence; 3 means useful evidence with substantial evaluation still needed; 4 means broad evidence with bounded gaps; 5 requires comprehensive evidence for the category. Missing evidence lowers confidence and the rating; it does not prove poor product quality.
Setup receives 2 because setup and build steps completed but CLI installation and an infrastructure workflow were not verified. Documentation receives 3 because the supplied README, contribution guide, and state page explain useful workflows and limitations, without establishing comprehensive documentation quality. Community receives 2 because contribution and support routes are documented, but adoption and response performance were not measured. Maturity receives 3 because the supplied sources document state handling, contribution practices, and a patch release, while operational reliability remains outside this run's scope.