Terragrunt in CI/CD

Plan/apply many units safely.

Advanced12 min · lesson 12 of 12

Terragrunt in CI follows the plan-on-PR, apply-on-merge pattern, scaled to many units. On a pull request, run run-all plan (or plan just the changed units) and surface the aggregate diff for review; on merge, run-all apply the reviewed changes with approval for production. The challenge is scale — dozens of units — so teams often detect which units changed and plan only those, and use Terragrunt’s output-module-groups to parallelize safely.

.gitlab-ci.yml

plan:
  script:
    - cd live/prod
    - terragrunt run-all plan --terragrunt-non-interactive 2>&1 | tee plan.txt
    # (optionally: only changed units via --terragrunt-include-dir)
 
apply:
  script: [cd live/prod && terragrunt run-all apply --terragrunt-non-interactive]
  rules: [{ if: '$CI_COMMIT_BRANCH == "main"' }]
  when: manual                         # human approval for prod
  environment: production

Guardrails at scale

The same guardrails as any IaC pipeline, but the blast radius is larger: authenticate to the cloud with OIDC and scoped roles per account, run policy/scan hooks before apply (Conftest/Checkov on the generated plan), gate prod behind approval, and never run-all destroy from automation without heavy protection. Because one pipeline can change an entire multi-account estate, its own hardening — least privilege, protected environments, reviewed config — is proportionally critical.

The secure Terragrunt pipeline

1PR: run-all plan

changed units, aggregated

2policy + review

scan + human reads diff

3merge: run-all apply

reviewed, approved

4guardrails

OIDC, scoped roles, locked state

Plan the changed units, scan and review the aggregate, apply on merge with per-account short-lived credentials.

One pipeline can reshape the whole estate

A Terragrunt CI job with run-all can change many accounts and regions at once, so a bug or a compromise has estate-wide reach. Scope runs to changed units where possible, require approval for prod applies, keep destroy out of routine automation, use per-account least-privilege OIDC roles, and protect the state backend — the pipeline that orchestrates everything deserves the strongest controls you have.

Remote-state & credential securityFinish · self-test