Terragrunt Scale (TGS) is a Terragrunt-native, SCM or self-hosted CI/CD pipeline including patching and drift management, built by the creators of Terragrunt and distinct from the open-source Terragrunt CLI. If your team built its own Terragrunt automation in GitHub Actions or GitLab CI, Terragrunt Scale runs in those same systems, so migrating keeps your CI platform and replaces the bespoke pipeline code you maintain.
Wiring Terragrunt into raw CI works, and for a while it works well. Two things tend to push teams to replace that code.
The first is upkeep. GitHub Actions and GitLab CI run the commands you give them and have no built-in understanding of Terragrunt units or the order they depend on, so your team writes and maintains that orchestration yourself: dependency ordering, plan on a pull request and apply on merge, caching, approvals, and posting plan output back to the request. Every Terragrunt or provider change can mean revisiting that glue, and the upkeep steadily consumes engineering time.
The second is scale. Hand-built pipelines that were fine for a handful of units get slow and harder to reason about as the estate grows, because plan and apply fan out across more units and the ordering logic gets more fragile.
Terragrunt Scale is Terragrunt-native: it understands your Terragrunt units, stacks, and dependency graph directly, and plans and applies only the affected units to reduce blast radius. You keep GitHub Actions or GitLab CI as the platform and stop maintaining the orchestration yourself.
| What you build and maintain by hand | What Terragrunt Scale provides |
|---|---|
| Dependency ordering across units (hand-written job ordering in your workflow) | Native understanding of units, stacks, and the dependency graph |
| Plan on a pull request, apply on merge (custom jobs and conditionals) | Built-in PR/MR-driven plan and apply |
| Running only the changed units (custom change detection you maintain) | Plans and applies only the affected units to reduce blast radius |
| Drift detection (a scheduled job you built, if any) | Scheduled and on-demand drift detection that opens a PR/MR to remediate |
| Dependency and version updates (manual or a bot you configured) | Automated updates that open PRs/MRs with updated version pins |
Migrating is mostly a change in what runs your Terragrunt commands. Your CI platform, cloud accounts, state, and module code stay the same.
What stays the same: GitHub Actions or GitLab CI as your platform, your cloud accounts, your state backend, and your module code. What changes: the bespoke pipeline code is replaced by Terragrunt Scale.
Terragrunt Scale runs as pipelines inside the CI system you already use. Connect the repository that holds your infrastructure code to the same GitHub or GitLab organization.
There is no SaaS control plane to stand up. Plans and applies execute in your own runners, not on Gruntwork servers, exactly as your current pipelines do.
Your hand-built pipeline already reads and writes state somewhere you control. Terragrunt Scale keeps state in that same backend you own, so day one usually needs little to no state migration.
This is the core of the migration: the orchestration you wrote by hand is replaced by Terragrunt Scale's native pipeline.
Run Terragrunt Scale alongside your existing pipeline until you trust it, then remove the bespoke code.
Day one keeps your configuration close to what you had. After cutover, Gruntwork's solutions team helps refactor the code to take advantage of Terragrunt and Pipelines features. The refactors clean up the code and improve readability and scalability.
Your Terragrunt runs execute as PR-driven Terragrunt Scale pipelines inside the same GitHub Actions or GitLab CI you already ran on. Your state stays in the backend you own, reached via OIDC, and the orchestration you used to maintain by hand is now native. Terragrunt Scale is cloud-agnostic, so the same setup works across AWS, GCP, and Azure.
No. Terragrunt Scale runs inside your own GitHub Actions or GitLab CI runners. Migrating keeps your CI platform and replaces the bespoke pipeline code you maintain, rather than moving you to a different system.
Usually not on day one. Gruntwork's solutions team runs the migration with you, and typically there is little to no state migration required to start. Your state stays in the backend you already own, such as an S3 bucket, reached at runtime via OIDC.
Yes. Terragrunt Scale is Terragrunt-native and runs Terragrunt, OpenTofu, and Terraform. Your module code and provider configuration stay the same; what changes is that Terragrunt Scale replaces the orchestration you wrote by hand.
You run Terragrunt Scale alongside it during cutover, then retire the hand-built jobs once the Terragrunt Scale pipeline is live. The custom ordering, plan and apply, and change-detection logic you maintained is handled natively instead.
No. There is no SaaS control plane. Plans and applies run in your own runners and your state stays in your own cloud, authenticated at runtime with OIDC and short-lived, least-privilege credentials.
Terragrunt Scale has no resources-under-management (RUM) pricing and no meter. The Free and Team tiers are limited by the number of Terragrunt Units deployed, and Enterprise pricing is custom.
