Terraform 1.17 explained: provider variables, minimal refresh and Policy GA

Terraform 1.17.0 came out on October 21, 2026. Read on if you run large states (there's a new -minimal-refresh option with a catch), keep providers in more than one private registry (required_providers now takes constant variables and locals), or write policy (Terraform Policy no longer needs an experimental build). Otherwise it's a quiet 1.x minor eight weeks after 1.16.0.

• You describe infrastructure in HCL, HashiCorp's configuration language.
• Providers are plugins that call each API: AWS, Azure, Snowflake, Okta.
• A state file records what Terraform already manages.
• terraform plan previews a change, and terraform apply makes it.
• IBM owns HashiCorp (Feb 2025); Terraform is under the BSL (Aug 2023).

Not much to read this time: three new features, three enhancements, seven bug fixes and two notes. Tags are HashiCorp's, except the notes, which we marked changed.

Provider requirements can now use variables, within limits. This builds on 1.15 (April 29, 2026), where module source and version started reading variables marked const = true and locals built from them. Now required_providers can too. Don't be thrown by HashiCorp's reference page for the terraform block, which still says it won't take input variables. The pull request's example uses an organization variable inside a private registry address and keeps the version in a local. Set the values with -var, a var file or environment variables.

This is useful if one codebase runs against more than one private registry or organization. Until now, teams in that position kept near-identical copies of the terraform block, or rewrote it with scripts before init. One limit doesn't move. The value has to be known before planning starts, so it can't come from a resource or a data source. Terraform 1.15 rejects that case at init for module sources with an "Invalid module source" error, and provider sources follow the same constraints.

A faster plan for big states, if you accept the trade-off. Normally a plan refreshes every resource it manages before doing anything else, which costs at least one read call each. On a state with thousands of resources, that's the slow part, and it's also when providers start rate limiting. Issue 35290 asked for a fix back in 2024, from someone who found -refresh=false too risky. -minimal-refresh has Terraform compare configuration with the prior state first. Instances with no planned change skip the refreshdefinitionBefore planning, Terraform asks each API what really exists and updates state to match. That's the refresh, and on big states it's the slow part., and the ones with changes are refreshed and planned again. Each one decides for itself, so refreshing one resource doesn't pull in the ones that depend on it.

The documentation is frank about the cost. Like -refresh=false, it ignores changes made outside Terraform to anything you didn't touch, so the plan can be incomplete or wrong. You can't combine it with refresh-only mode or with -refresh=false. HashiCorp also says to avoid it when you upgrade provider versions, so Terraform can write schema changes into state. We'd use it for fast feedback on pull requests and keep a full-refresh plan in front of every production apply.

Terraform Policy is out of experimental status in the CLI. For anyone who hasn't tried it, it's HashiCorp's HCL-based policy as code: .policy.hcl files with provider, resource and module blocks. HCP Terraform can evaluate them at setup time, before providers or modules download, at plan time and after apply, when IDs and ARNs exist. Enforcement is Advisory, Mandatory_overridable or Mandatory. Sentinel and Open Policy Agent haven't gone away.

From 1.17, -policies works on plan, apply and query in a normal build. Query policies check what your list blocks find and report as text or JSON. Before you call it production-ready, though, look at the docs too. HashiCorp's Terraform PolicydefinitionHashiCorp's HCL-based policy as code, kept in .policy.hcl files. docs (v0.5.x) still said "this functionality is in beta" when we checked on October 22, 2026. Easy to miss: the pull request the GA entry links to changes how policies see a replacement. It now arrives as a separate create and delete, each with its own attribute values. It used to be one update.

Smaller changes that can still show up in your pipeline. Two fixes could change output you're used to. Diagnostics from renewing ephemeral resources now appear, and HashiCorp doesn't expect that to break anything. log and pow now fail instead of returning infinity. If a wrapper parses terraform version -json, check that it tolerates the new format_version field. And if anything in your build trusts certificates through the compromised eMudhra intermediates, the Go 1.26.10 change in 1.17.0 and 1.16.7 will make those connections fail.

A quick sense of pace: a minor release every few months, a patch to the current one most weeks. Here's 1.17 next to the two before it, headline items only. The changelogs have everything else.

How long will 1.16 be supported? Nobody has published a date we can point you to. What we can see is that 1.16 is still getting patches: 1.16.7 arrived the day after 1.17.0. The support-period article now redirects to IBM's support portal, which didn't load for us without a sign-in, and the public 1.x compatibility promise only says the series gets at least 18 months of maintenance after 1.0. If you need a date for an audit or a contract, ask HashiCorp support.

And two advisories from this summer. Neither is in the Terraform CLI. If you run self-managed Terraform Enterprise, read HCSEC-2026-17: a user who can publish a registry module from a VCS repository could pull files from outside it into the module and download them. It hits v202506-1, v202507-1 and 1.0.0 through 2.0.3, with fixes in 2.0.4 and 1.2.4. If you run terraform-mcp-server, HashiCorp's MCP server for AI tools, read HCSEC-2026-23. Versions 0.2.1 through 1.0.0 had three HTTP transport flaws, one of which could send the server's bearer token to an attacker's endpoint. 1.1.0 fixes them; stdio-only setups were safe.

Nothing about Terraform's overall shape changes in 1.17: configuration, the CLI or a remote runner, providers, state, and the APIs at the end. A few decisions move. Init can work out a provider's address from variables, a plan can skip refreshing what you didn't touch, and you don't need an experimental build to run policy from the Terraform CLI. We've used HashiCorp's own component names in the diagrams and simplified the rest.

Don't expect much from the upgrade guide. For 1.17 it says the release honors the v1.0 compatibility promises and points you at the changelog. That's normal inside 1.x. If something breaks, look at providers first, then at scripts that parse CLI output, then at the edge cases in the bug fixes. This is the order we'd go in.

Most of what's in 1.17 helps platform teams that run Terraform for other teams. If you write a few modules for one account, you can take this release at your own pace.

• Platform teams with one codebase and several private registries or organizations: set the provider source per environment and stop copying terraform blocks or patching them with scripts.
• Teams whose large states run into provider rate limits get a supported halfway house between a full refresh and -refresh=false when they just want a quick plan.
• If you write guardrails, you can run HCL policies from the Terraform CLI in CI now. Policies see a replacement as a create and a delete.
• Anyone wrapping the CLI in scripts gets versioned JSON from terraform version, which makes it easier to notice when the format changes later.
• Teams staying on 1.16 for now still get the Go 1.26.10 certificate change through 1.16.7.

If you run self-managed Terraform Enterprise or a shared terraform-mcp-server, check the two bulletins above first. They matter more than anything in the 1.17 changelog.

Cohash writes and maintains Terraform for clients: module design, state clean-up, version upgrades. Our Terraform platform page has the detail. If you'd rather staff it yourself, hire Terraform engineers through us, or ask for a free assessment of your code, state and pipelines first. The DevSecOps practice handles pipelines and policy.