Terragrunt — When and Why

Terragrunt is a thin wrapper around Terraform that exists to remove the boilerplate native Terraform leaves you to repeat. It generates the backend and provider blocks every stack would otherwise duplicate, wires dependencies between stacks so one's outputs feed another's inputs, and runs apply across many stacks at once in the right order. None of that is new capability — it is the same Terraform underneath — but it deletes toil that grows with the number of stacks.

So the question is never "is Terragrunt good" but "do I have enough stacks for it to pay off." It earns its keep when you have dozens of stacks — many Hatch projects, each a root module — and the per-stack backend duplication and ordered cross-stack applies become real work. Below that scale it is a second tool, a second config dialect, and a license to weigh, bought for a problem the native patterns from the last topic already solved.

What Terragrunt Adds

Two things, mainly. First, DRY generation of the backend and provider blocks every stack would otherwise repeat — you declare the backend pattern once in a root terragrunt.hcl and Terragrunt generates the per-stack block at runtime, so there is no -backend-config ceremony per stack. Second, dependency blocks that pass one stack's outputs into another's inputs, replacing hand-written terraform_remote_state lookups with explicit, mockable dependencies.

These map directly onto the native patterns from Topic 67. The partial backend config you supplied with -backend-config becomes a generated block; the terraform_remote_state data source you wired by hand becomes a dependency. Terragrunt is automation of the same DRY discipline, not a different idea — which is exactly why it only pays off once that discipline is repeated across many stacks.

run --all Across Stacks

terragrunt run --all apply plans and applies every stack in a tree in dependency order. Standing up hatch-net-host and then the service projects that attach to its Shared VPC becomes one command instead of a hand-ordered sequence of cd and apply per stack. Terragrunt reads the dependency graph across stacks and walks it for you, the way Terraform walks the resource graph within a single stack.

One naming note worth carrying: the older run-all subcommand is now spelled run --all. The behavior is the same, but a Terragrunt upgrade will deprecate the old form, so write run --all in scripts and CI from the start to avoid the rename biting later.

Dependency Wiring

A dependency "network" block reads the Shared VPC host project's outputs and feeds them to a service project that attaches to it. This replaces the brittle data "terraform_remote_state" lookups you would otherwise copy between every consuming stack — each one reaching into another stack's state by hand and breaking silently when an output is renamed.

# Terragrunt: explicit, mockable dependency
dependency "network" {
  config_path = "../hatch-net-host"
}

inputs = {
  network_id = dependency.network.outputs.network_id
}

The dependency is named, version-checkable, and can be mocked for a plan before the upstream stack exists. A renamed output now breaks at plan time with a clear error pointing at the dependency, instead of failing deep inside a consuming stack that quietly read stale state.

When Terragrunt Earns Its Keep

The signal is scale and ordering. Many stacks with repetitive backend and provider config, real cross-stack dependency ordering, and a team tired of -backend-config ceremony — that is where Terragrunt pays for itself. A multi-project Hatch org with dozens of root modules and a network host that everything depends on is the shape it was built for.

At five stacks it is not. There, the native patterns from Topic 67 — shared modules, per-environment .tfvars, and partial backend config — are simpler and add no extra tool. The crossover is roughly where hand-maintaining backend blocks and a hand-ordered apply script stops being a minor chore and becomes a recurring tax; below it, native Terraform wins on simplicity.

The Cost of Adopting It

Terragrunt is a second tool to install, pin, and learn, with its own HCL dialect layered over Terraform's. A small estate pays that learning cost up front and never collects the payoff, because there was little duplication to delete. The honest framing is that Terragrunt trades a fixed adoption cost for a per-stack saving — worth it only when the stack count makes the saving large.

A license note worth getting right: Terragrunt itself remains MIT-licensed and fully open source — it did not follow Terraform's 2023 move to the BUSL, and Gruntwork explicitly pivoted Terragrunt to support OpenTofu. So an OpenTofu-first organization that chose OpenTofu for its open-source license can add Terragrunt without undercutting that choice; the cost to weigh is the second tool and dependency, not its license. Pin the Terragrunt version alongside Terraform, and decide on it the same way — once, at the org level.