terragrunt plan and apply: Run Terraform via Terragrunt
terragrunt plan and terragrunt apply run the matching terraform command for one unit with backend and inputs already resolved.
For a single unit, terragrunt plan/apply behaves like terraform plan/apply, except Terragrunt has already generated the backend and mapped inputs to TF_VAR variables.
What it does
terragrunt plan and apply auto-init the unit, set TF_VAR_* from the inputs map in terragrunt.hcl, resolve any dependency outputs, then invoke terraform plan or terraform apply inside the cache. Extra arguments after the subcommand pass straight to terraform.
Common usage
terragrunt plan
terragrunt apply
# non-interactive apply in CI
terragrunt apply -auto-approve
# save and reuse a plan file
terragrunt plan -out=tfplan
terragrunt apply tfplanOptions
| Flag | What it does |
|---|---|
| -auto-approve | Apply without the interactive prompt (terraform flag) |
| -out=<file> | Write the plan to a file (terraform flag) |
| -target=<addr> | Limit the operation to a resource (terraform flag) |
| --terragrunt-non-interactive | Assume yes to Terragrunt prompts |
| --terragrunt-no-auto-init | Do not auto-run init first |
In CI
Always pass -auto-approve to apply and --terragrunt-non-interactive so Terragrunt does not prompt to create an S3 bucket or DynamoDB lock table and hang the job. A saved plan from plan -out is the safest gate: run plan in one stage, apply the exact file in the next.
Common errors in CI
"Error acquiring the state lock" with a DynamoDB or blob lease ID means a previous run died mid-apply; inspect and terragrunt force-unlock <ID> only after confirming nothing else is running. "Unsupported argument: inputs" means inputs is at the wrong nesting in terragrunt.hcl. A dependency error like "Module ... has not been applied yet" means a dependency block points at an un-applied unit.