Which strategy should I use for Terraform Stacks CLI?
Determine how to move Stack workflows from the deprecated standalone terraform-stacks-cli into the main Terraform CLI without breaking automation.
Blockers
- The main Terraform CLI under terraform stacks supersedes the standalone Stacks CLI.
- The .tfcomponent.hcl extension replaces .tfstack.hcl for component files.
- Deployment groups plus auto_approve_checks supersede the deprecated orchestration blocks.
- capability/terraform-stacks incompatible with capability/local-stack-deployment
- capability/terraform-stacks incompatible with capability/agent-hooks
- If you use Terraform Enterprise, the Stacks CLI docs require setting TF_STACKS_HOSTNAME for CLI usage.
Who this is for
- enterprise
- monorepo
Candidates
Migrate automation to the main Terraform CLI with terraform stacks
As of 2026-04-04, HashiCorp documents the standalone "terraform-stacks-cli" as deprecated and says all Stacks commands now live in the main Terraform CLI under "terraform stacks". The current Stacks CLI reference is published under Terraform v1.14.x docs and includes commands such as "init", "validate", "create", "list", "providers-lock", "fmt", and subcommands for configuration, deployment groups, and deployment runs. GA also introduced backward-incompatible language changes: component files must use the ".tfcomponent.hcl" extension instead of ".tfstack.hcl", and the old "auto_approve", "orchestrate", and "replan" orchestration blocks are deprecated in favor of deployment groups plus "auto_approve_checks". Billing changed at GA too: Stack Resources Under Management are now aggregated with workspace RUM for HCP Terraform billing.
When to choose
Use this when you already adopted Stacks and need the supported post-GA path for CI/CD. It is the default choice when your main risk is breaking existing scripts, because the blocking work is known and documented: swap CLI invocations, update file extensions and syntax, then trigger a configuration fetch or deployment to reinitialize each Stack.
Tradeoffs
Keeps you on the supported CLI surface and aligns with current docs, but it is not a drop-in rename because GA changed both command location and Stack language syntax. Billing visibility also changes because Stack RUM now counts together with workspace RUM.
Cautions
As of 2026-04-04, HashiCorp states that existing beta Stack configurations and state history are no longer available after GA. You also can no longer destroy Stack deployments from the HCP Terraform UI; destruction must be modeled with the "destroy" argument in a deployment block and applied through a new deployment run. If you use Terraform Enterprise, the Stacks CLI docs require setting "TF_STACKS_HOSTNAME" for CLI usage.
Shift automation to HCP Terraform configuration-version workflows with VCS or API triggers
As of 2026-04-04, HashiCorp documents that Stacks can create configuration versions from VCS-linked repository changes, manual VCS fetches, CLI uploads, or API uploads, and that each configuration version creates deployment runs for every deployment in the Stack. HashiCorp also documents that operators can review and approve deployment runs in HCP Terraform, while the Terraform CLI can still be used selectively for actions such as uploading configurations or managing deployment runs. This makes VCS- or API-driven configuration-version automation a valid post-deprecation replacement path when you want less local CLI orchestration and more remote, platform-centered execution.
When to choose
Use this when your goal is not to preserve old local wrapper scripts exactly, but to move Stack automation onto HCP Terraform's native remote workflow. It fits teams that already rely on VCS-driven delivery, want auditability in the platform, or need an API-first control plane around configuration uploads and deployment approvals.
Tradeoffs
Reduces dependence on local CLI wrappers and aligns with HCP Terraform's native execution model, but it changes where automation lives and may require pipeline redesign around configuration versions, approvals, and deployment-run monitoring. It is less familiar if your current process assumes imperative local commands for every step.
Cautions
As of 2026-04-04, HashiCorp documents that Stack deployments run remotely in HCP Terraform or on custom HCP Terraform agents; you cannot deploy a Stack locally. The Stacks runs docs also note that agent hooks do not support Stack workflows, which can matter if your existing automation depends on them.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Which strategy should I use for Terraform Stacks CLI?"