In the previous subchapter, we saw that the directory-per-environment strategy is excellent, but it has a small drawback: some repetition between environments. When you have many environments or many components, that repetition grows. Terragrunt is a community tool that solves exactly that, helping you keep your code DRY. Let’s see what it is and when it’s worth it.

DRY stands for "Don't Repeat Yourself". It’s a fundamental programming principle: each piece of information or logic should exist in one single place. Repeating code is bad because, if you need to change something, you have to change it in many places (and it’s easy to forget one).

In subchapter 19.2, we saw that the directory strategy leaves some repetition in the main.tf of each environment (backend configuration, calls to similar modules...). Terragrunt tackles that repetition.

Terragrunt is a tool that wraps Terraform (a "wrapper"), created by the company Gruntwork. It does not replace Terraform: it complements it, adding features to better manage multiple environments and reduce repetition.

Analogy: if Terraform is the engine, Terragrunt is a driver assistance system that sits on top: the engine still does the work, but driving becomes more comfortable and you make fewer mistakes, especially on long and repetitive journeys (many environments).

Remember that each environment needs to configure its state backend (Chapter 11, subchapter 20.1), and that is repeated in each folder. With Terragrunt, you define the backend configuration only once and each environment inherits it, automatically generating the part that changes (for example, the state path for each environment).

Values shared by all environments (region, common tags, accounts...) are defined once and inherited, instead of being copied into each environment.

Each environment is reduced to a small file that says "use this module with these specific values," while all the common machinery (backend, providers, configuration) is centralized. The files for each environment are minimal: only their differences.

Terragrunt also helps orchestrate multiple infrastructure components (network, database, application) and their dependencies, applying them in order, which is very useful in large projects.

Like any tool, Terragrunt adds its own complexity (another tool to learn and maintain). The decision to adopt it depends on the size of your project:

Important tip: don’t adopt Terragrunt from day one. Start with Terraform and the directory strategy from subchapter 19.2. Only when you feel that repetition between environments becomes a real problem, consider Terragrunt. Adopting it too soon adds unnecessary complexity (remember the lesson from Chapter 17 about not choosing complex tools just because they’re trendy).

It’s worth knowing that Terragrunt is not the only option. Terraform itself has been adding improvements, and platforms like Terraform Cloud / HCP Terraform (which we’ll see in Chapter 22) also help manage environments. Terragrunt is still very popular, but the ecosystem evolves; choose according to what your team needs and knows.

• DRY ("Don't Repeat Yourself") is the principle of not repeating code: each thing should be in one single place, so you don’t have to change it in many places.
• Terragrunt is a tool that wraps Terraform (does not replace it) to reduce repetition when managing multiple environments. Like a "driver assistant" on top of the Terraform engine.
• It solves: backend configuration without repetition, common values in one place, less code per environment (only the differences), and orchestration of dependencies between components.
• Don’t adopt it from the start: begin with Terraform + directories per environment (subchap. 19.2), and switch to Terragrunt only if repetition becomes a real problem. Don’t add complexity just because it’s trendy.

In the last subchapter of the chapter, we’ll see how to manage values for each environment in detail: environment variables and .tfvars files.