Should I upgrade to Terraform Stacks GA Language Change now?

Plan the syntax updates required after Terraform Stacks GA deprecated beta orchestration blocks and changed deployment group and auto-approval configuration.

Simplify to default groups and manual approval unless auto-approval is a real policy requirement; rewrite to explicit groups/rules only when you need Premium orchestration parity.

Blockers

Who this is for

Candidates

Rewrite beta orchestration to explicit deployment groups and deployment_auto_approve rules

As of 2026-04-04, Terraform Stacks GA has already deprecated the beta `auto_approve`, `orchestrate`, and `replan` orchestration blocks. HashiCorp's GA migration guidance replaces the old auto-approval syntax with `deployment_auto_approve` rule blocks attached through `auto_approve_checks` on a `deployment_group`, and deployments must opt into that group with the `deployment_group` argument. GA also moved Stack commands into the main Terraform CLI under `terraform stacks` and deprecated the separate `terraform-stacks-cli`. Billing also changed at GA: Stack Resources Under Management are now aggregated with workspace RUM for HCP Terraform billing.

When to choose

Use this when you previously relied on beta auto-approval logic and need equivalent behavior to continue after GA. This is the right path if auto-approval policy is still required, especially in HCP Terraform Premium Edition where deployment-group orchestration rules are available.

Tradeoffs

Preserves automated approvals and makes rules explicit, but requires touching deployment files, creating named groups, and wiring each deployment to a group.

Cautions

Deployment groups currently support only one deployment per group. If you do not assign a deployment to a custom group, Terraform creates a default group automatically and you cannot define custom rules on that default group. Existing beta configurations and state history were not carried forward after GA, so this is not an in-place syntax-only upgrade.

Sources

Simplify to default groups and manual approval except built-in empty-plan behavior

As of 2026-04-04, Terraform Stacks still provides a default `deployment_auto_approve` rule named `empty_plan`, which automatically approves plans with no changes. If a deployment is not assigned to a custom `deployment_group`, Terraform creates a default group for it automatically, but HashiCorp documents that custom rules cannot be defined on that default group. This makes a manual-approval-first migration viable for teams that want the smallest GA rewrite and can remove beta orchestration logic instead of recreating it. This path still requires adopting GA file and CLI changes such as `terraform stacks` and renaming Stack component files to `.tfcomponent.hcl`.

When to choose

Use this when the old beta orchestration rules were convenience features rather than hard policy, or when you want the fastest unblock after GA. It is the better choice if you do not need Premium-only orchestration behavior or want to avoid per-deployment custom group management.

Tradeoffs

Smallest migration surface and fewer moving parts, but you lose custom automatic approvals and accept more manual intervention on non-empty plans.

Cautions

Do not assume beta orchestration will continue to work: the old blocks are deprecated and GA expects the new model. Also account for the GA billing change where Stack RUM now counts together with workspace RUM; check official pricing docs for current plan details.

Sources

Facts updated: 2026-04-04
Published: 2026-04-05

Related questions

Try with your AI agent

$ npm install -g pocketlantern
$ pocketlantern init
# Restart Claude Code, Cursor, or your MCP client, then ask:
# "Should I upgrade to Terraform Stacks GA Language Change now?"
Missing something? Request coverage