Terragrunt
llms.txtlists every page for an agent
A Terragrunt repo of units or explicit stacks, or one on Terragrunt Scale.
Works
- Each unit is a root, and dependency order decides the waves
- A pull request plans the units of every layer it reaches, each on its upstream's planned outputs
- terragucci import terragrunt-scale reads Gruntwork Pipelines' environments and roles
Differs
- roots is refused; terragrunt.exclude leaves units out.
- A step after init is refused, since Terragrunt inits each unit inside the plan.
- CDK Terrain in a Terragrunt repo is not supported.
On Terraform, choudoufu, GitLab
On Terraform
- Two overlapping pushes to one root can fail the newer apply with "Saved plan is stale"; run it again and it plans again.
On choudoufu
- terragucci does not read a root's required_version as a choudoufu release.
On GitLab
- Comment commands answer on a schedule, since a merge request note starts no pipeline.
- Roots lock on /terragucci apply or /terragucci lock, not at the first plan.
- The agent comment and drift fixes are GitHub and Forgejo only.
First step
Proof
Terragrunt, on Forgejo
- Plan and reviewPlan and review, Terragrunt10 checks, all proven.
- tf-check fails an unformatted Terragrunt file and names it
- only the units a change reaches are planned, including a file a module reads that Terragrunt misses
- a dependency whose mock_outputs can stand in for apply is named by a tip
- Approve and applyApprove and apply, Terragrunt14 checks, all proven.
- the Terragrunt example boots in five waves, one job each: the dependency layers of the dev canary, then the layers of staging and prod, each with one run --all
- a Terragrunt wave waits for an approval of its set digest, and once approved applies its saved plans while the next wave waits at its own gate
- a Terragrunt wave whose plans changed after approval applies nothing and names the unit that moved
- Locks and safetyLocks and safety, Terragrunt3 checks, all proven.
- a new upstream and its dependent merge together and apply in order, so no mock reaches real state
- in a Terragrunt repo, a pull request that changes a unit whose dependencies block names a unit another open pull request applied is refused with the unit and the holder named
- in a Terragrunt repo a change to root.hcl locks every unit and says why, and a Markdown-only change locks none
- PolicyPolicy, Terragrunt2 checks, all proven.
- in a Terragrunt repo a unit the policy denies fails tf-plan, and its wave applies nothing
- with cost.approve_above set, a Terragrunt wave whose saved unit plans are priced over the amount waits for an approval under gate: never, while a wave within it applies
- DriftDrift, Terragrunt4 checks, all proven.
- drift is reported by unit in a Terragrunt repo, with the same tracking issue
- a drifted Terragrunt unit gets a pull request that writes the live value into its own terragrunt.hcl inputs and leaves the module its units share alone
- with respond.drift: attribute in a Terragrunt repo, tf-drift lists who changed each drifted attribute under its unit in the drift issue
- Chat and notifyChat and notify, TerragruntNo check recorded.
- Reports and visibilityReports and visibility, Terragrunt2 checks, all proven.
- the plan of each Terragrunt unit sends its spans to the report through the TG_TF_PATH wrapper, and waits up to five minutes for the state lock
- in a Terragrunt repo the plan note gives the blast radius of a changed unit through the units that depend on it, and the run view and the estate graph hold each unit by wave with an edge for each dependency block
- ModulesModules, Terragrunt1 check, proven.
- with modules.require: attested in a Terragrunt repo tf-check and tf-plan refuse a unit whose terraform source pins an unattested release, and pass one that pins an attested release
- State and migrationState and migration, Terragrunt3 checks, all proven.
- a Terragrunt unit whose state is in a versioned S3 bucket applies twice, its backend read from its remote_state block, and the estate page lists both state version ids newest first, each one the bucket holds
- a migration file moves a resource from the state of one Terragrunt unit to that of another: the plan proves it with no change, wave 1 waits for its digest, and once approved writes both states under their locks, recording each version before and after
- terragucci state export of a Terragrunt unit prepares it through Terragrunt, asks for the version of the state its remote_state block names, and once someone else approved it writes that version on the machine of the person who asked, recorded on chant/lifecycle
- Agents and pull request environmentsAgents and pull request environments, Terragrunt1 check, proven.
- in a Terragrunt repo whose remote_state key reads TERRAGUCCI_EPHEMERAL_SUFFIX, opening a pull request applies its own copy of a unit at the key suffixed -pr-<n>, prepared through Terragrunt, beside the state of the unit itself, and closing it destroys the copy on the record
- Setup and runtimeSetup and runtime, Terragrunt8 checks, all proven.
- init finds Terragrunt and its 15 units on its own and writes the pipeline the Terragrunt example commits
- terragucci import terragrunt-scale writes the plan and apply roles of each Gruntwork Pipelines environment as terragrunt.credentials, and every unit then assumes the roles of its environment, a unit with its own gruntwork.hcl its own
- in a Terragrunt repo terragucci generate writes terragucci.hcl from terragucci.yml, the check step passes it, and each unit that includes it applies with the backend key and provider settings generate gives it, while a unit that does not include it is refused by name
- proven passes, and fails with the feature cut out
- not supported not supported by design; a corner mark means part of the area
- none no check recorded
Every check runs on OpenTofu on Forgejo. Runs on Terraform, choudoufu and github.com are expensive, so they re-run only the checks where the binary or forge changes what happens.
Open a cell for the checks behind it. Recorded: example checks, last full run Oct 8, 2026; per-forge checks Oct 7 to Oct 9, 2026; github.com Oct 10, 2026.
You can count on
- A plan note on every pull request
- Gated applies of the plans you approved
- No overlapping or stale applies
- Re-plan from a comment
- Scheduled drift checks
- OIDC roles, one to plan, one to apply
- Policy on every plan
- An audit trail in your bucket
- Secrets kept out of notes and logs
- Your state backend, as is
- Your own runners
- Your forge's sign-in and permissions
Then read
These docs count page views and clicks with PostHog. They set no cookies, store nothing in your browser, and send nothing when your browser asks not to be tracked.