FAQs

Yes. Terragrunt is an IaC orchestration tool built for both OpenTofu and Terraform. Where OpenTofu/Terraform is the execution engine, Terragrunt is the orchestration and configuration layer for running IaC at scale: it treats OpenTofu/Terraform modules as versioned, reusable infrastructure patterns and deploys them consistently across environments. Terragrunt Scale likewise supports Terragrunt, OpenTofu, and Terraform.

Terragrunt organizes infrastructure into units (directories containing a terragrunt.hcl file that are independently operable, atomic, and reproducible), so changes are isolated to smaller portions of the system instead of applying to one large monolithic OpenTofu/Terraform root module. Because each unit has its own state and deployment boundary, teams can plan, apply, and troubleshoot smaller parts of the system independently. Related units are grouped into stacks, which help control the blast radius of changes and manage dependencies between units. Terragrunt's Run Queue runs operations in a safe order across the dependency graph.

Terragrunt can generate backend configuration and manage remote state settings in a reusable way. Its remote_state functionality supports common backend patterns and can help bootstrap state resources such as S3 buckets and DynamoDB tables for AWS, which cuts down on manual state setup and keeps configuration consistent. Backend settings can be defined once in shared configuration and inherited across units, so every environment is configured the same way instead of repeating backend blocks in each root module.

Terragrunt allows shared configuration to be defined once and inherited across units. Common backend settings, provider configuration, module inputs, and environment conventions can be centralized so the same code is not repeated across development, staging, and production. This is especially useful when the same infrastructure pattern, such as a VPC, cluster, database, and application stack, must be deployed across multiple environments. You define the common configuration once and override only the values that differ by environment.

Terragrunt's Run Queue controls ordering and concurrency when running OpenTofu/Terraform commands across multiple units. It uses a directed acyclic graph (DAG) built from the dependencies between units, so dependencies run before dependent units for operations such as plan or apply, and destroy operations occur in a safe reverse order, while still allowing safe concurrency where possible. This automates common ordering requirements such as networks before clusters, IAM before services, and databases before applications.

Yes. Terragrunt is an IaC orchestration tool built for both OpenTofu and Terraform. Where OpenTofu/Terraform is the execution engine, Terragrunt is the orchestration and configuration layer for running IaC at scale: it treats OpenTofu/Terraform modules as versioned, reusable infrastructure patterns and deploys them consistently across environments. Terragrunt Scale likewise supports Terragrunt, OpenTofu, and Terraform.

A Terragrunt unit is a directory containing a terragrunt.hcl file. It is the smallest deployable entity in Terragrunt and is intended to be independently operable, atomic, and reproducible, so teams can isolate infrastructure changes to smaller portions of the system instead of applying changes to a large monolithic OpenTofu/Terraform root module. A stack is a collection of related units managed together: stacks let teams deploy multiple infrastructure components with a single command, manage dependencies between units, control the blast radius of changes, and organize infrastructure into logical groups. Terragrunt supports both implicit stacks, based on directory structure, and explicit stacks, defined with terragrunt.stack.hcl files. Use units to keep each piece of infrastructure independently deployable; use stacks when you need to operate a group of related units as one.

Terragrunt has first-class support for feature flags. Feature flags improve the speed and safety with which engineers can integrate their IaC: they let engineers integrate incomplete work without introducing undue risk to the infrastructure they manage, decouple infrastructure release from deployment, and codify important information about the evolution of IaC. They were built for teams operating Terragrunt at large scale, where an error in one unit would otherwise prevent its dependents (and their dependents) from running, so that potentially risky changes can be introduced without slowing down code integration across long dependency chains. See the Terragrunt documentation for configuration details and common patterns.

Yes. The question comes up every time OpenTofu or Terraform ships a new feature, and the answer has not changed. Terragrunt was started in 2016 to plug gaps in Terraform, and some early Terragrunt features, such as state locking, were later adopted by Terraform itself. As OpenTofu and Terraform matured, Terragrunt's focus shifted to higher level concerns: orchestrating infrastructure as code at scale. The relationship is symbiotic, to the point that Gruntwork works with the OpenTofu core team to adopt the features Terragrunt implements to plug gaps in OpenTofu, so Terragrunt can concentrate on orchestration and safety at scale.

That orchestration is why teams keep using it. Terragrunt isolates infrastructure into units with their own state, so the blast radius of a change stays limited to the unit being updated instead of putting all of your infrastructure at risk, and it combines units into stacks that run in dependency order. It also handles the messy, real-world scenarios that OpenTofu/Terraform keep out of scope by design: retrying transient errors, ignoring errors that are safe to ignore, and hooks that codify operational practices, such as backing up a database before every update, so they happen the same way locally and in CI. For the full argument, read Terragrunt & OpenTofu: Better together.

When deploying a stack of infrastructure units, Pipelines will concurrently generate a plan for all the infrastructure units in the stack, and display them in a single pull request / merge request comment as separate plans.

Pipelines uses an "apply after merge" approach. This means that while multiple PRs are proposing changes to the same resources, there’s only ever a single source of truth for the infrastructure that will be provisioned (the Infrastructure as Code on the deploy branch e.g. main). During initial implementation we guide teams to using features of their SCM platform to enforce branch protection rules that ensure that plans are recent and applies are predictable.

Pipelines natively integrates with the Terragrunt CLI to drive infrastructure updates through the Directed Acyclic Graph (DAG). When creating or updating multiple infrastructure components, dependencies will be created or updated before dependents (e.g. VPCs before servers), and when deleting infrastructure components, dependents will be destroyed before dependencies (e.g. servers before VPCs). This ordering is applied even if infrastructure is deployed through different units.

Yes, you can make changes to infrastructure components within any number of different environments (e.g. AWS accounts) at the same time in the same PR, and the pipeline will update them concurrently on merge.

Access control to infrastructure is segmented by least privilege principals (e.g. AWS IAM roles) that only have access to individual environments, further segmented by a different principal used for read-only access during pull requests / merge requests open and a principal used for read-write access during pull request merge.

As a consequence, updates to a particular environment will only be done by a principal that only has access to that environment, and can only be used after review by your team.

Pipelines takes full advantage of state isolation using Terragrunt to ensure that infrastructure is only updated if a corresponding code-change would impact that resource.

When you create a PR, Pipelines will run a plan on units affected by the code change. The plan output shows in the PR comments with: (1) a clear plan summary of what specific infrastructure resources were impacted, and (2) a full plan output of what's changing. When you merge the PR, it kicks off the CI/CD pipeline to apply it.

Pipelines is flexible and can be configured to support your repository structure using HCL Configurations as Code. You programmatically define the relationship your Infrastructure as Code has to your environments, and Pipelines will operate in those environments accordingly. Pipelines supports dependencies between Terragrunt units, even if those units are in different environments or require different cloud authentication credentials.

Both are supported.

Usage of OIDC-based credential acquisition means that repositories are trusted to assume particular credentials in target environments. You can delegate management of limited infrastructure to separate repositories, or have all your infrastructure managed in one repository. Pipelines and Terragrunt are designed to scale to very large and sophisticated monorepo structures.

Pipelines uses a GitHub app in GitHub and a GitLab machine user in GitLab to authenticate with the respective Source Code Management (SCM) provider.

When authenticating with cloud providers, Pipelines will perform an OIDC handshake between the repository in the SCM and a principal in a given environment to acquire temporary, least privilege credentials for the actions it needs to perform in that environment. Pipelines also provides an escape-hatch mechanism which allows developers to implement a per-environment custom authentication mechanism to authenticate with arbitrary APIs and pass those credentials into Terragrunt at runtime.

Pipelines creates a clear audit trail of infrastructure changes by tagging each cloud authentication session with unique identifying information of what change initiated that session. In addition, PRs with plan outputs that can be reviewed and approved before merging. Both GitHub and GitLab also provide branch protection rules that require approval before merges. This provides an audit trail of requested changes and approval.

Yes, you can reuse workflow templates across multiple projects or environments and author any steps you want in addition to the ones provided by Gruntwork. Pipelines uses standard GitHub Actions and GitLab CI Pipelines to drive infrastructure updates.

You have full control. All workflows are defined and run in your repository, you can add custom steps, and you're not dependent on calling Gruntwork for infrastructure changes.

Drift detection runs as a GitHub actions workflow / GitLab CI Pipeline at the root of your repository or within a subset (like a directory defining the infrastructure for a specific AWS account). It compares the contents of your Infrastructure as Code (IaC) code against the state of your infrastructure in your cloud environments (e.g. deployed in AWS). When it finds drift (like someone opening port 22 in the AWS console without making a corresponding change in IaC), it creates a PR/MR to remediate the drift by reverting deployed infrastructure to the designated configuration defined in IaC. You can review the impact of remediating the drift in a comment on the PR/MR, then either update the IaC to match the drift, or merge the PR/MR as is to re-apply the IaC specified configuration.

If you are suffering from infrastructure that’s experiencing significant drift from your IaC, first, run drift detection in each environment one-by-one to gradually remediate drift over time. Once you are confident your deployed infrastructure is aligned with the configuration you’ve defined using IaC, schedule automatic runs of Drift Detection once a week to ensure you do not accrue drift.

Terragrunt Scale is a Terragrunt-native, SCM-hosted or self-hosted CI/CD pipeline including patching and drift management, built by the creators of Terragrunt. It is cloud agnostic and supports all clouds, and it automates Terragrunt workflows across teams, repositories, environments, and cloud accounts. It includes three products: Pipelines (a secure GitOps CI/CD pipeline built for Terragrunt, where plans run when a pull or merge request is opened and applies run on merge), Drift Detection (scheduled and on-demand scans that open a PR/MR when deployed cloud resources no longer match your IaC), and Patcher (automated dependency updates for OpenTofu/Terraform modules and Terragrunt units/stacks). All operations run inside your own runners and repositories using standard GitHub Actions or GitLab CI pipelines.

Terragrunt and Terragrunt Scale are complementary. Terragrunt is the open source orchestration and configuration layer for scaling OpenTofu/Terraform code: it organizes IaC into units and stacks, manages dependencies through a directed acyclic graph (DAG), and keeps configurations DRY. Terragrunt Scale is a commercial, Terragrunt-native, SCM-hosted or self-hosted CI/CD pipeline including patching and drift management. It adds the workflows most teams otherwise have to build and maintain themselves: pull-request plans, apply-on-merge, blast-radius minimization, least-privilege cloud authentication, drift detection, and automated dependency updates. Terragrunt itself is free and open source, and Terragrunt Scale has a free tier as well.

Terragrunt Scale runs in your existing CI/CD. All operations run inside your own runners and repositories using standard GitHub Actions or GitLab CI pipelines. Plans and applies execute in your runners, not on Gruntwork servers. Terragrunt Scale never holds direct access to your cloud accounts or state files, and OIDC handshakes provide temporary, least-privilege credentials instead of long-lived secrets. It supports GitHub, GitLab, GitHub Enterprise, and GitLab Self-Managed for version control.

Yes. Terragrunt Scale understands Terragrunt units, stacks, and DAGs. Pipelines executes updates through the dependency graph so adds, changes, and destroys trigger in the right order, and it plans and applies only the affected units to reduce blast radius. Drift Detection supports stacks too: it opens a PR/MR for drifted stacks when deployed cloud resources no longer match your IaC. Patcher scans Terragrunt units and stacks, and OpenTofu/Terraform module references, to find current versions and available updates, and opens PRs/MRs with updated version pins.

Pipelines identifies the smallest set of units affected by a change and runs plans only for those, rather than the whole repository, to minimize blast radius. It supports concurrent runs for independent units, posts results back to the PR/MR, and applies on merge in dependency order, including multi-environment changes. Plan summaries and logs appear directly in PR/MR comments.

Terragrunt Scale offers unlimited runs and unlimited resources, and there is a free tier. The Free and Team tiers are limited by the number of Terragrunt Units being deployed, with no usage meter, and Enterprises are offered custom pricing. Terragrunt Scale has no resources-under-management (RUM) pricing: you are never charged based on the number of resources you manage.

Yes. Terragrunt Scale runs in your existing CI/CD: all operations run inside your own runners and repositories using standard GitHub Actions or GitLab CI pipelines. Plans and applies execute in your runners, not on Gruntwork servers. It supports GitHub, GitLab, GitHub Enterprise, and GitLab Self-Managed for version control, and it works with self-hosted GitLab and GitHub Enterprise Server.

Yes. Terragrunt Scale can integrate with any secret manager you want: your workflows use the OIDC credentials provided by your CI/CD platform to call cloud APIs and access your own secret manager. For cloud authentication, OIDC handshakes provide temporary, least-privilege credentials instead of long-lived secrets, and Terragrunt Scale never holds direct access to your cloud accounts or state files.

Patcher is the automated dependency-update product in Terragrunt Scale. It scans your Terragrunt units and stacks, and your OpenTofu/Terraform module references, to find the current versions in use and the updates available. It then opens pull/merge requests with updated version pins. For breaking changes, Patcher applies patches where available, or generates guidance files when manual action is required. This gives teams that use many reusable modules a repeatable process for staying current instead of tracking updates manually.

Yes. Terragrunt Scale was designed with a strong security posture from day one, which makes it a fit for enterprise and regulated environments. There is no SaaS control plane: all operations run inside your own runners and repositories using standard GitHub Actions or GitLab CI pipelines, and it can run fully self-hosted on self-hosted GitLab or GitHub Enterprise Server. Your state lives in your own cloud (for example, an S3 bucket), and authentication uses OIDC to obtain temporary, short-lived credentials at runtime, so no cloud credentials are stored in the pipeline. Access follows the principle of least privilege, changes go through pull/merge-request review with branch-protection-enforced approvals, and you get a complete audit trail of who changed what, when, and why. Terragrunt Scale does not hold compliance certifications of its own: your code and data live in your SCM, so the security model is inherited from GitHub or GitLab.

Open source Terragrunt is the orchestration and configuration layer for running OpenTofu/Terraform at scale. It is and always will be free to use. Terragrunt Scale is a commercial, Terragrunt-native, SCM-hosted or self-hosted CI/CD pipeline including patching and drift management, built by the creators of Terragrunt, that automates Terragrunt workflows across teams, repositories, environments, and cloud accounts. Consider Terragrunt Scale when you want plans to run automatically on pull/merge requests and applies to run on merge (Pipelines), scheduled and on-demand drift scans that open PRs/MRs when deployed resources no longer match your IaC (Drift Detection), and automated dependency updates for your modules and units/stacks (Patcher). That applies whether you have not built this automation yet, you built it in-house and its upkeep now consumes significant engineering time, or you adopted another solution and are hitting its scaling limits. There is a free tier, so you can adopt it incrementally: the Free and Team tiers are limited by the number of Terragrunt Units being deployed, with no meter and no resources-under-management (RUM) pricing. Enterprises receive custom pricing.

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. Unlike managed platforms, plans and applies run inside your own GitHub Actions or GitLab CI runners, and there is no resources-under-management (RUM) pricing. For a comparison of seven tools including Spacelift, env0, Scalr, Atlantis, and Terrateam, see the best Terraform CI/CD pipeline tools. For head-to-head comparisons, see Terragrunt Scale vs Spacelift and Terragrunt Scale vs Terraform Cloud (HCP Terraform).