The execution model

How Terragrunt calls Terraform.

Advanced10 min · lesson 4 of 12

Understanding what Terragrunt actually does on each command demystifies it. For a single unit it: reads terragrunt.hcl, downloads the source module into .terragrunt-cache, writes the generated backend and provider files, assembles the inputs (as TF_VAR_ environment variables or an auto tfvars), and then runs the underlying terraform command in that cache directory, streaming its output. So terragrunt plan is terraform plan with all the glue applied first.

What one terragrunt command does

1read hcl

source + inputs + state

2fetch module

into .terragrunt-cache

3generate

backend + provider files

4run terraform

plan/apply in the cache

Every Terragrunt run is a Terraform run with generated config injected — same plan/apply semantics you already know.

It is still Terraform underneath

Because the real work is Terraform in the cache directory, everything you know transfers: read the plan the same way, the same +/~/-/+- symbols mean the same things, state lives in the same backend, and you can drop into the cache directory to run raw terraform for debugging. Terragrunt passes through most terraform commands and flags, so terragrunt output, terragrunt state, terragrunt import all work.

terminal

$ terragrunt plan
# (downloads module, writes backend.tf/provider.tf, then:) 
Terraform will perform the following actions:
  + aws_vpc.main will be created
Plan: 1 to add, 0 to change, 0 to destroy.
# to debug, cd into .terragrunt-cache/.../ and run raw terraform there

The -/+ replace symbol still means data loss

Terragrunt does not change Terraform’s plan semantics, so a -/+ (destroy and recreate) on a database or volume is exactly as dangerous here — read every plan before applying. The wrapper adds convenience, not safety around destructive changes; the discipline of reading plans from the Terraform course applies unchanged.

Generating backend & provider…DRY remote state