# Terraform 1.16 adds module imports and machine-readable state commands > Terraform 1.16 supports import blocks inside modules, JSON output for state and workspace inspection, richer action triggers, and lifecycle destroy controls. Canonical URL: https://www.devobs.io/news/news-terraform-1-16-release/ By: Theo Morgan Published: 2026-09-06T11:58:54.647Z Updated: 2026-09-06T11:58:54.647Z Event date: 2026-08-26 Section: Developer tools HashiCorp released Terraform 1.16.0 on August 26 with additions across imports, state inspection, lifecycle handling, tests, and actions. The [official release notes](https://github.com/hashicorp/terraform/releases/tag/v1.16.0) also carry an upgrade warning for teams using provisioner bastion host keys. ## More configuration patterns move into the core CLI Import blocks can now appear inside modules, allowing reusable modules to describe how existing resource instances enter state. `terraform state show` and `terraform workspace list` add JSON output, making inspection less dependent on parsing terminal text. The graph command can emit Mermaid, while the console can evaluate expressions in the scope of a selected module or module instance. Lifecycle blocks gain `destroy = false`, which can detach a remote object from Terraform management without deleting it. Action triggers add failure modes to halt, taint, or continue, plus hooks before and after destroy. These controls are powerful because they affect destructive transitions; module authors should expose them with clear defaults and test each branch. ## Plans need comparison before adoption Terraform now preserves provider-specific private data between plan and apply, and a `terraform_data` store block can carry ephemeral and sensitive values across those phases. That may help provider workflows, but it makes saved-plan handling and version consistency important. An upgrade test should initialize a copy of a real workspace, compare 1.15 and 1.16 plans, exercise module imports against disposable resources, and verify JSON consumers. The release notes warn that `bastion_host_key` is now correctly applied by provisioners, so affected configurations should confirm the configured key before upgrading. `destroy = false` also needs an ownership handoff process: removing state does not remove cost, data, or responsibility for the live object. ## Source references -