Terraform Stacks: What’s for Infra at Scale

Last Updated on November 20, 2025 by Arnav Sharma

Managing Terraform at scale has consistently presented operational challenges. The typical patterns include workspaces that proliferate uncontrollably, duplicated configuration across environments, fragile orchestration scripts, and the persistent risk that a single misapplied change will propagate through production infrastructure.

At HashiConf 2025, HashiCorp released Terraform Stacks to General Availability in HCP Terraform across all RUM-based plans. This represents a fundamental shift in configuration architecture, enabling teams to manage collections of modules and deployments as unified, orchestrated units across environments, regions, accounts, and cloud providers.

The Infrastructure Management Problem

Current Terraform scaling patterns typically fall into several categories:

• Monolithic root modules create state files that become unmanageable. Plan operations slow to a crawl, and the blast radius of any change encompasses the entire infrastructure footprint.

• Workspace-based architectures require external orchestration through Terragrunt, Terramate, or custom scripts. These solutions function adequately but introduce maintenance overhead for an entire orchestration layer that exists outside the Terraform ecosystem.

• Data source dependencies between workspaces create brittle coupling. Remote state references require manual ordering, and changes don’t propagate automatically. This pattern has caused production incidents when dependent workspaces weren’t updated in the correct sequence.

Platform teams spend disproportionate time maintaining orchestration infrastructure rather than building reusable components.

Stacks inverts this model. Infrastructure is defined once as components (reusable modules), then deployment targets specify where and how many times to instantiate it. Terraform manages orchestration, dependency resolution, and change propagation automatically.

Core Architecture Concepts

The Stacks model introduces specific terminology:

• Components represent reusable infrastructure modules instantiated within a stack. These function similarly to child modules in traditional Terraform.

• Deployments are individual instances of the complete stack configuration. A deployment might represent an environment (production, staging, development) or a geographic region (us-east-1, eu-west-1). Each deployment uses identical component definitions with variations driven exclusively by input variables.

• Stacks encompass the complete set of components and deployments, managed as a unified entity within HCP Terraform.

• Linked Stacks enable cross-stack dependencies where one stack consumes outputs from another (networking stack outputs consumed by application stacks).

Critical architectural principle: all deployments within a stack share identical component configurations. Environmental differences derive solely from input variables, enforcing consistency across the infrastructure.

Configuration Structure

Stacks introduce two file types:

*.tfcomponent.hcl files define components (infrastructure resources and their relationships).

*.tfdeployment.hcl files define deployment targets (where infrastructure gets provisioned).

Example: Multi-Region Three-Tier Application

# components.tfcomponent.hcl

component "vpc" {
  source = "../../modules/vpc"
  inputs = {
    cidr = var.vpc_cidr
  }
}

component "eks" {
  source = "../../modules/eks"
  inputs = {
    vpc_id       = component.vpc.vpc_id
    subnet_ids   = component.vpc.private_subnet_ids
    cluster_name = "${deployment.name}-eks"
  }
}

component "rds" {
  source = "../../modules/rds"
  inputs = {
    subnet_ids     = component.vpc.private_subnet_ids
    instance_class = var.db_instance_class
  }
}

output "kubeconfig" {
  value = component.eks.kubeconfig
}

# deployments.tfdeployment.hcl

deployment "prod-use1" {
  inputs = {
    name              = "prod-use1"
    vpc_cidr          = "10.10.0.0/16"
    db_instance_class = "db.m6g.large"
  }
}

deployment "prod-euw1" {
  inputs = {
    name              = "prod-euw1"
    vpc_cidr          = "10.20.0.0/16"
    db_instance_class = "db.m6g.large"
  }
}

deployment "dev-use1" {
  inputs = {
    name              = "dev-use1"
    vpc_cidr          = "10.99.0.0/16"
    db_instance_class = "db.t4g.medium"
  }
}

This configuration defines three independent deployments managed as a single stack in HCP Terraform. Module updates automatically trigger plan operations across all affected deployments.

General Availability Features

Automatic Dependency Resolution

HCP Terraform constructs dependency graphs across components and linked stacks, eliminating custom orchestration scripts.

Deployment Groups (Premium)

Deployments can be logically grouped (canaries, geographic regions, business units) with defined orchestration rules: sequential application, parallel execution, conditional auto-approval based on change scope.

Partial Planning and Deferred Changes

Multi-region deployments frequently encounter scenarios where downstream components require values unavailable until upstream resources complete provisioning. Stacks support partial planning, applying known configurations while deferring dependent resources.

Cross-Stack Output Consumption

Linked stacks enable direct output references:

inputs = {
  vpc_id = stack.networking.vpc_id
}

Changes propagate automatically through the dependency chain.

CLI Integration

The standalone terraform-stacks-cli has been deprecated. Functionality is now integrated into the standard Terraform CLI:

terraform stacks init
terraform stacks plan
terraform stacks apply

Self-Hosted Agent Support

Stacks can execute on self-hosted infrastructure for air-gapped environments or regulatory compliance requirements.

Billing Model

Stack resources count toward standard RUM (Resources Under Management) metrics with no additional licensing components.

Migration Strategy

Stacks and traditional workspaces coexist within projects. Migration can proceed incrementally:

1. Extract shared modules as stack components
2. Migrate applications individually
3. Maintain hybrid architectures during transition

Organizations using Terragrunt or Terramate will find most orchestration capabilities available natively through Stacks. Several enterprises have initiated migration roadmaps based on reduced operational overhead from eliminating wrapper tooling.

The GA migration documentation provides detailed transition procedures.

OpenTofu Compatibility

Terraform Stacks require HCP Terraform (cloud or Enterprise platform). The functionality is not available in open-source Terraform CLI or OpenTofu.

OpenTofu has discussed similar orchestration concepts (GitHub issue #931) but has not released equivalent functionality. Organizations requiring fully open-source toolchains will continue using Terragrunt, Terramate, or similar orchestration solutions.

For teams on HCP Terraform, Stacks provide significant productivity improvements over external orchestration tools.

Implementation Steps

1. Enable Stacks in organization settings (Settings → General → Stacks)
2. Create or select a target project
3. Review the official tutorial: https://developer.hashicorp.com/terraform/tutorials/cloud/stacks-deploy
4. Reference the language documentation: https://developer.hashicorp.com/terraform/language/stacks

Operational Impact

Terraform Stacks address the orchestration gap that previously required external tooling at enterprise scale. The abstraction layer enables platform teams to provide self-service infrastructure provisioning with enforced consistency across deployments.

For teams managing infrastructure across multiple environments, regions, or accounts, Stacks reduce operational complexity while improving reliability through automated dependency management and change propagation.

The infrastructure-as-code ecosystem has evolved substantially with this release.