Terraform Stacks
Terraform Stacks is HashiCorp's construct for deploying the same configuration across many environments and regions from a single definition. The problem it targets is one every growing team hits: you have a set of components — a network, a cluster, a database tier — and you need them in dev, staging, and prod, in three regions each, without copying the configuration nine times or wrapping it in a tool that orchestrates the copies.
Stacks reached general availability at HashiConf in September 2025, and the honest framing matters: it is HashiCorp's native answer to a problem teams have solved for years with directories, workspaces, and Terragrunt. Where those are mature and battle-tested over a decade, Stacks is GA but far younger and tied to the HCP platform. This topic is an overview of what it offers and how to weigh it.
The Multi-Environment Problem
A single configuration deploys one copy of its resources. To run the same components in three environments and three regions, teams reach for one of a few workarounds: a directory per environment with duplicated code, a workspace per environment sharing one backend, or Terragrunt generating the repetition from a DRY definition. Each works, and each has a known tax — duplication, weak isolation, or an extra wrapper tool to learn and maintain. Stacks aims to handle the multiplication natively, inside Terraform's own model.
Components and Deployments
A Stack splits the definition in two. You define components once — the modules that make up the system and how they wire together — and then declare deployments, each an instantiation of those components with its own inputs. One deployment is us-east-1 prod, another is eu-west-1 staging, and so on. The component definition is written once; the deployments vary only by their input values. That separation is the core idea: describe the system a single time, then stamp it out per environment from one source of truth.
Orchestration Across Deployments
Stacks also handles the dependencies between and across deployments — a shared networking component that other deployments build on, or a rollout that should reach staging before prod. Rather than running each environment's apply by hand and sequencing them yourself, the Stack definition expresses the ordering and HCP Terraform orchestrates the rollout. This is the part directories-plus-scripts handle worst: getting many related deployments to roll out in a safe, coordinated order.
Where Stacks Fits
Against the established options, Stacks is the native, integrated choice for the components-and-deployments shape. Directories-per-environment remain the simplest thing that works and stay fully under your control. Terragrunt is the mature community answer with years of production use and a large body of shared knowledge. Stacks trades that maturity for a model purpose-built for the problem and wired into HCP Terraform's runs and state — a real advantage if you are already on that platform and the fit is clean.
Maturity and Availability
Stacks reached general availability in late 2025, but it is far younger than the rest of Terraform, and newer constructs move and change faster than the decade-old core. It depends on HCP Terraform, so it is not a thing you bolt onto a plain CLI-plus-S3 setup. Before building production on it, confirm your providers and workflow are supported, and account for the platform dependency. The established patterns have not gone away — adopt Stacks where its native model is a clear win, and keep using directories or Terragrunt where they already serve you well.
Directories per environment / Terragrunt — mature, widely used, fully under your control, with years of production experience and a large body of shared knowledge. Choose them when proven patterns already serve you, or when you are not on HCP Terraform.
Terraform Stacks — HashiCorp's native components-and-deployments model with built-in cross-deployment orchestration — GA since late 2025 but far younger, less battle-tested, and tied to HCP Terraform. Choose it when its native model is a clear fit, you're on HCP Terraform, and its maturity is acceptable for the workload.
- Putting critical production on a newer feature before evaluating its maturity and confirming your providers and workflow are supported.
- Assuming Stacks fully replaces directories and Terragrunt everywhere, rather than fitting the specific multi-deployment cases its model is built for.
- Confusing Terraform Stacks (the deployment construct) with the unrelated meaning of "stack" in CloudFormation or Pulumi, and reasoning about the wrong thing.
- Building on Stacks without accounting for its HCP Terraform dependency, then discovering it can't be bolted onto a plain CLI-plus-S3 setup.
- Migrating proven directory or Terragrunt setups to Stacks purely for novelty, taking on churn for patterns that already worked.
- Evaluate Stacks for genuine multi-environment and multi-region deployment of the same components, not for single-environment configs.
- Weigh its maturity and HCP Terraform dependency against the established directory and Terragrunt patterns before committing production to it.
- Keep using proven patterns where they already work, and adopt Stacks where its components-and-deployments model is a clear fit.
- Track the feature's evolution, since newer constructs change faster than Terraform's stable core.
- Confirm your providers and workflow are supported on Stacks before designing a production rollout around it.
Knowledge Check
What problem does Terraform Stacks target?
- Deploying the same components across many environments and regions from a single definition, without duplicating config or wrapping it in another tool
- Encrypting the state file at rest with a managed key so you no longer need a remote backend to keep secrets safe on disk
- Writing brand-new custom providers for in-house systems that have no existing Terraform support yet
- Generating the entire Terraform configuration from a general-purpose programming language so you can author resources in code instead of writing any HCL by hand
In a Stack, what is the relationship between components and deployments?
- Components are defined once; deployments are instantiations of those components, each with its own inputs
- Deployments are the reusable definition written once, and components are the per-region copies instantiated from them
- They are simply two different names for the same underlying object at different stages of a single run
- Components hold the state file and deployments hold the lock, with no other difference between them
How does Stacks compare to directories-per-environment and Terragrunt?
- It's HashiCorp's native, integrated answer but newer and tied to HCP Terraform, while directories and Terragrunt are mature and battle-tested
- It's strictly older and far more battle-tested than both of them, so it should always replace directories-per-environment and Terragrunt outright
- It removes the need for any state file or remote backend entirely across every environment
- It is exactly the same construct as a Terraform workspace, only renamed for marketing
What should you account for before building production on Stacks?
- Its relative immaturity, its HCP Terraform dependency, and whether your providers and workflow are supported
- That it only runs against the local on-disk backend and cannot store its state in S3 at all
- That it cannot be used with modules of any kind
- That it requires rewriting all of your existing HCL configuration into CDKTF first before any component will deploy
You got correct