Terraform Stacks Is HashiCorp's Answer to the Wrapper Script Problem

For years, platform teams have been building the same thing over and over: bespoke Python or Bash wrappers around Terraform to handle multi-region rollouts, cross-workspace dependencies, and Kubernetes provisioning quirks. HashiCorp just made most of that glue code obsolete. Terraform Stacks, now generally available for HCP Terraform and Terraform Enterprise 2.0, ships a native configuration layer that sits above modules — and it directly targets the operational tax that every serious Terraform shop has been paying.

Why the Wrapper Script Era Had to End

HashiCorp is explicit about the problem: once you split infrastructure across multiple Terraform configurations, state isolation forces you to stitch dependencies together yourself, and there was no built-in way to provision the same infrastructure across multiple accounts, environments, regions, or landing zones as a single unit. The company’s own framing is telling — they call the wrapper-script pattern “heavy lifting” that is “error-prone and risky to set up and manage.”

This matters because the wrapper tax compounds. Every team that grows past a handful of workspaces ends up rebuilding some version of Terragrunt, Atlantis logic, or a homegrown orchestration layer. That’s engineering time spent on plumbing rather than platform capabilities. Stacks brings the orchestration primitive into Terraform itself, which means the graph of dependencies HashiCorp is famous for now extends across configurations, not just resources inside one.

If you’re a platform team currently maintaining a deploy.sh that loops over 12 workspace directories and pipes terraform output into JSON files for the next run, Stacks collapses that pattern into a .tfdeploy.hcl file. The take: expect a wave of internal RFCs proposing migration off Terragrunt over the next 12 months, and expect HashiCorp to sharpen the migration tooling accordingly.

How Components and Deployments Split the Problem

Stacks introduces two new configuration file types: .tfcomponent.hcl describes what infrastructure to deploy (composed from existing modules), and .tfdeploy.hcl describes where and how many times to deploy it. A component block references a source module, its inputs, and its providers — no rewrites required. A deployment block sets per-instance inputs like aws_region = "us-west-1" or instance_count = 2.

That separation is the key design choice. Historically, teams conflated “what does this system look like” with “where does it run,” which is why copy-pasted environments/prod, environments/staging, and environments/dev folders became the norm. Stacks formalizes the distinction, so a single change to the component definition can be planned against every deployment simultaneously and rolled out to all, some, or none of them.

Imagine a fintech running a payments service across three AWS regions and two accounts. Today that’s six workspaces, six state files, and a runbook. With Stacks, it’s one component definition and six deployment blocks, with a single plan operation showing the diff across all of them. The take: the copy-paste env/ folder pattern will look as dated in 2027 as unversioned modules do today.

Deployment Groups and Deferred Changes Fix Day-2 Pain

Two Stacks features address the operational realities that break naive orchestration. Deployment groups (which replace the public beta’s orchestration rules) let teams cluster deployments by environment, team, or application and attach auto-approve checks — for example, a no_deletes check that auto-approves a plan only when context.plan.changes.remove == 0. Deferred changes let Terraform produce a partial plan when it hits too many unknown values instead of halting entirely, which HashiCorp calls out as the enabler for Kubernetes workloads.

Both features target problems that don’t show up in demos but destroy real deployments. Kubernetes has always been Terraform’s awkward roommate because so much of its state depends on values that only exist after the cluster is up. Deferred changes acknowledges that reality instead of pretending it away. Deployment groups, meanwhile, is HashiCorp finally admitting that a human clicking “approve” 40 times per rollout is not automation — it’s ceremony.

A concrete scenario: a team pushing a new namespace to three Kubernetes clusters can apply it to US first, validate, then approve Europe, and shelve Asia for later — all without blocking the plan. Combined with a canary deployment group that auto-approves only destruction-free plans, you get a progressive delivery pattern that used to require Spinnaker or Argo Rollouts glue. Prediction: within a year, most Stacks users will define at least one custom deployment group with a no_deletes or similar guardrail, and it will become table stakes for production Terraform. That guardrail work overlaps with custom AI agent development for change review pipelines.

Linked Stacks, Private Registry, and the Platform Engineering Play

Stacks isn’t just orchestration — it’s a platform engineering primitive. Linked Stacks let one Stack consume outputs from another, so a networking Stack can feed identity and workload Stacks without manual data plumbing. The private registry now hosts versioned Stack component configurations, not just modules, so a platform team can publish a compliant “web app” or “data pipeline” Stack pattern and let product teams source it with minimal Terraform expertise. Self-hosted agents run inside private networks for regulated environments, and there’s expanded VCS support for GitHub, GitLab, Azure DevOps Services, and Bitbucket with IP allowlisting.

This is the golden-path story every platform team pitches to their leadership. The registry becomes a catalog of blessed patterns, linked Stacks enforce separation of concerns without sacrificing consistency, and self-hosted agents keep compliance teams off your back. It’s a direct shot at Backstage-style internal developer platforms — except the substrate is already the infrastructure-as-code tool your team uses.

If you’re a regulated shop — say a healthcare SaaS running multi-tenant B2B portals that need FedRAMP boundaries — you can now publish a component config for “HIPAA-compliant tenant environment” once, and every application team gets a repeatable, auditable deployment path. The take: platform teams that were about to greenlight a Backstage rollout will pause and evaluate whether Stacks plus the private registry can do 70% of the same job with less operational surface.

The Migration Question Everyone Will Ask

HashiCorp acknowledges the elephant in the room: there was never a supported path from workspaces to Stacks, and manual re-import was the only option. The new guided CLI migration workflow is step-by-step rather than a black-box conversion, with a manifest-driven approach for coordinating multiple workspaces. It’s designed for incremental adoption — you can run Stacks alongside existing workspaces, not instead of them.

This is the right call. A big-bang migration tool would have been a footgun; a step-by-step CLI that lets you validate state at each stage is what enterprise teams actually need. The RUM (resources under management) pricing visibility means Stacks resources show up in the same billable-resources view as workspace resources, so finance won’t be blindsided either.

For a team with 200 workspaces spread across three business units, the realistic play is to migrate one non-critical service first, validate the deployment group logic, then define a migration wave per quarter. Prediction: the vendors selling Terraform migration consulting are about to have a very good 2026.

FAQ

Q: What is a Terraform Stack? A: A Terraform Stack is a new configuration layer that sits on top of Terraform modules, composed of components (defined in .tfcomponent.hcl files) that describe the infrastructure and deployments (defined in .tfdeploy.hcl files) that describe where and how many times to deploy it. It gives Terraform a native way to orchestrate multiple related configurations as a single unit.

Q: How is Stacks different from Terragrunt or wrapper scripts? A: Stacks is a first-party HashiCorp feature integrated into the Terraform CLI and HCP Terraform, with native support for cross-configuration dependencies, deployment groups with auto-approve checks, deferred changes for Kubernetes-style unknown values, and linked Stacks for cross-stack data passing. Wrapper tools solve similar problems but sit outside Terraform’s execution model and require their own maintenance.

Q: Where can I use Terraform Stacks today? A: According to HashiCorp, Stacks are generally available on HCP Terraform and Terraform Enterprise 2.0 or later on plans with resources under management (RUM) pricing. Custom deployment groups specifically require HCP Terraform Premium or Terraform Enterprise 2.0 or later; default deployment groups are available in all plans.

Key Takeaways

• Platform teams still maintaining bespoke wrapper scripts around Terraform should evaluate Stacks before their next major refactor — the wrapper-tax justification is weakening fast.
• Adopt custom deployment groups with auto-approve checks (like no_deletes) early; they turn Stacks from an orchestration tool into a progressive delivery platform.
• Use the private registry to publish versioned Stack component configurations as golden paths — this is the fastest way to reduce Terraform expertise as a bottleneck for product teams.
• Plan migrations incrementally using the new CLI workflow; a big-bang workspace-to-Stacks cutover is not the intended pattern and will burn state.
• Watch for third-party tooling around Stacks — expect CI/CD platforms, policy engines, and drift detection tools to ship Stacks-native integrations through 2026, and factor that into vendor selection now.