Terragrunt: Keep Terraform DRY

By Khimananda Oli | Last reviewed: August 2026

Managing dozens of environments with vanilla Terraform inevitably leads to massive code duplication and fragile state configurations. If you are copying backend blocks or provider configs across fifty directories, you are violating the core principle that Terragrunt: Keep Terraform DRY was designed to enforce. This wrapper solves the scalability gap by introducing configuration inheritance, automatic backend management, and orchestration primitives that native HCL lacks. For teams building production-grade Infrastructure as Code, adopting this tool is often the turning point between unmanageable sprawl and a scalable platform.

How does Terragrunt keep Terraform DRY in practice?

The primary mechanism for maintaining DRY (Don't Repeat Yourself) principles is hierarchical configuration inheritance. Unlike standard Terraform, which treats each directory as an isolated unit requiring explicit backend and provider definitions, Terragrunt allows you to define these once in a root terragrunt.hcl file. Child configurations use the include block to pull in these parent settings, overriding only what is specific to that component.

Eliminating Backend Configuration Duplication

In a typical multi-account AWS setup, every single state file needs a unique S3 key but shares the same bucket, region, encryption settings, and DynamoDB lock table. Without Terragrunt, you copy-paste this 10-line block hundreds of times. With Terragrunt, you define it once:

# Root terragrunt.hcl
remote_state {
  backend = "s3"
  generate = {
    path      = "backend.tf"
    if_exists = "overwrite_terragrunt"
  }
  config = {
    bucket         = "my-org-terraform-state"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
    key            = "${path_relative_to_include()}/terraform.tfstate"
  }
}

The key attribute uses the built-in path_relative_to_include() function to automatically derive a unique state path based on the directory structure. When you run terragrunt apply in prod/us-east-1/vpc, it generates a backend.tf with the correct key without you ever typing it manually. This single feature prevents the most common source of state corruption in large-scale cloud infrastructure projects.

Centralizing Provider Configuration

Provider versions and default tags should be standardized across your organization. Terragrunt’s generate block creates a provider.tf in the working directory at runtime, ensuring every module uses the exact same provider constraints and default tagging strategy for cost allocation and compliance auditing.

generate "provider" {
  path      = "provider.tf"
  if_exists = "overwrite_terragrunt"
  contents  = <<EOF
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.80"
    }
  }
}

provider "aws" {
  region = var.aws_region
  default_tags {
    tags = {
      ManagedBy   = "terragrunt"
      Environment = var.env
      CostCenter  = var.cost_center
    }
  }
}
EOF
}

What is the difference between Terragrunt and Terraform modules?

A common mistake among engineers new to this ecosystem is confusing reusable modules with orchestration. They solve fundamentally different problems. Modules package infrastructure logic; Terragrunt packages deployment context. Understanding this distinction is critical when deciding which IaC approach fits your team.

In practice, you use both together. Your Terraform modules define what to build (e.g., an EKS cluster). Your Terragrunt configuration defines where and how to deploy it (e.g., prod us-east-1 with specific VPC outputs injected). Never put backend configuration or cross-module dependency logic inside a Terraform module; that is Terragrunt’s job.

How do you manage cross-stack dependencies without coupling?

Real infrastructure has dependencies: your EKS cluster needs the VPC ID, your RDS instance needs the security group, your app needs the database endpoint. In monolithic Terraform, these are simple resource references. In modular, DRY architectures with separate state files, you need a safe way to pass outputs between stacks.

Using Dependency Blocks Safely

The dependency block reads outputs from another stack’s state file without creating a hard Terraform-level coupling. This keeps your modules pure and testable while allowing orchestrated deployments.

# eks/terragrunt.hcl
dependency "vpc" {
  config_path = "../vpc"

  # Mock outputs allow planning even if VPC hasn't been applied yet
  mock_outputs = {
    vpc_id     = "vpc-mock-12345"
    subnet_ids = ["subnet-mock-a", "subnet-mock-b"]
  }
  mock_outputs_allowed_terraform_commands = ["plan", "validate"]
}

inputs = {
  vpc_id     = dependency.vpc.outputs.vpc_id
  subnet_ids = dependency.vpc.outputs.subnet_ids
}

The mock_outputs pattern is essential for developer experience. It allows team members to run terragrunt plan on the EKS stack without having deployed the VPC first, enabling parallel development and faster CI feedback loops. Without mocks, every plan requires the full dependency chain to exist, which kills productivity in large organizations.

When should you adopt Terragrunt over native Terraform?

Terragrunt adds operational complexity. You should not adopt it for a single-project hobby setup. However, for teams managing multiple environments, regions, or microservice stacks, the trade-off pays dividends quickly. The decision typically comes down to three factors: state management burden, team size, and compliance requirements.

• Multi-environment parity: If you maintain dev, staging, and prod with identical structure but different inputs, Terragrunt’s inheritance eliminates drift caused by manual copying.
• Compliance and audit readiness: For teams pursuing SOC 2 or ISO 27001 certification, centralized provider configs ensure mandatory tagging and encryption policies cannot be accidentally omitted in individual modules.
• State isolation requirements: If your security model demands separate state files per component (to limit blast radius), Terragrunt makes this manageable. Native Terraform makes separate-state architectures painful to maintain.
• Team autonomy: Platform teams can own the root configuration and enforce standards, while product teams own their component terragrunt.hcl files with minimal boilerplate.

Conversely, stick with native Terraform if you have fewer than five stacks, a single environment, or a team unfamiliar with HCL basics. Premature abstraction with Terragrunt can obscure debugging and increase onboarding friction. Start with solid Terraform fundamentals before adding the orchestration layer.

How do you structure a scalable Terragrunt repository?

Directory layout determines long-term maintainability. A proven pattern separates live infrastructure configurations from reusable modules, mirroring the organizational boundary between platform and product teams.

infrastructure-live/
├── terragrunt.hcl              # Root: backend, provider, global vars
├── _envcommon/                 # Shared env-specific overrides
│   ├── vpc.hcl
│   └── eks.hcl
├── prod/
│   ├── terragrunt.hcl          # Env-level: region, account ID, env name
│   ├── us-east-1/
│   │   ├── vpc/terragrunt.hcl
│   │   └── eks/terragrunt.hcl
│   └── eu-west-1/
│       └── vpc/terragrunt.hcl
└── staging/
    └── ... (mirrors prod structure)

This layout leverages find_in_parent_folders() for automatic config discovery. Each level adds specificity: root defines global standards, environment defines account/region context, and leaf nodes define component-specific inputs. The _envcommon directory holds shared component configs that can be included via include "envcommon" blocks, preventing duplication even across environments when component configs are identical except for the environment name.

Implementing Terragrunt for Production Workloads

Adopting Terragrunt is not just about writing less code; it is about establishing guardrails that prevent configuration drift and state corruption as your team grows. Start by migrating a single non-critical environment to validate your inheritance hierarchy and CI integration before converting production. Ensure your CI pipelines support Terragrunt commands natively, as standard Terraform CI actions will not handle the orchestration layer correctly. Remember that the goal is sustainable velocity: if your Terragrunt configuration becomes harder to understand than the duplicated Terraform it replaced, simplify the hierarchy. The best infrastructure code is the code your team can confidently modify at 2 AM during an incident.

If you are evaluating whether Terragrunt fits your current architecture or need help migrating a legacy Terraform codebase to a DRY, scalable structure, reach out to discuss your infrastructure challenges. I help teams design IaC foundations that survive growth, audits, and personnel changes without accumulating technical debt.