Gruntwork Newsletter, October 2025

Every few months, we send out a newsletter to all Gruntwork customers summarizing updates we’ve made since the last newsletter, along with news from the DevOps industry. Note that some of the links below may lead to private repositories in the Gruntwork Infrastructure as Code Library that are accessible only to customers.

As always, if you have any questions or need help, email us at support@gruntwork.io!

In This Issue

• A major new release of the Gruntwork platform, bringing stability, security, and UX improvements, including:
  • More efficient change detection and a smaller default blast radius when making infrastructure changes with Gruntwork Pipelines
  • De-multiplexed logs for multi-unit --all plans and applies
  • Better support for Terragrunt Stacks across both Pipelines and Drift Detection
  • Support for Azure short-lived authentication tokens via OIDC as well as custom authentication hooks
  • A new, more flexible HCL configuration-as-code approach (YML config is now deprecated)
  • Advanced filtering for Drift Detection
• Full GitLab support for Pipelines, Account Factory, and Drift Detection
• Terragrunt continues its march toward 1.0:
  • All pre-1.0 deprecations are now complete
  • The new --filter feature is coming soon and available now as experiment
  • Runner Pools enable faster deployments for large infrastructure environments
  • Run summaries provide at-a-glance overviews of your Terragrunt executions
  • OpenTofu Provide Cache offers an out-of-the-box speed boost

Gruntwork Updates

Major Platform Release

We’ve released GitHub v4 and GitLab v2! We recommend upgrading using our GitHub migration guide or GitLab migration guide. Read on to learn how you can benefit from the new features and capabilities included in this release.

Improvements to Gruntwork Pipelines Change Detection

We’ve removed several previously announced experimental feature flags, making Pipelines more predictable and responsive to the full range of codebase modifications by default. Specifically:

• Unit Changed events are now triggered when any file within a given Terragrunt unit is modified (including files such as .terraform.lock.hcl). Previously, these triggered File Changed events, which did not account for a file’s semantic association with its unit.
• Pipelines now consolidates Terragrunt operations to improve dependency handling and minimize redundant executions. This reduces duplicated work — for example, when both File Changed and EnvCommon events would trigger plans for the same unit — resulting in faster runs, cleaner output, and fewer CI minutes consumed.
• To keep the blast radius of your changes localized, Pipelines now executes Terragrunt run --all with the --queue-strict-include option, ensuring that dependencies no longer run automatically when dependents are modified.

New HCL Configuration as Code

We introduced our HCL Configuration as Code language, offering a significantly more expressive and flexible way to model your DevOps estate. HCL configurations now support all Gruntwork products.

If you’re a GitLab user, you’re already using this configuration. If you’re on GitHub, we strongly encourage you to migrate to HCL as part of the upgrade to GitHub v4 by following our migration guide. YML configurations are now deprecated and will be removed in the next major release.

Better Logs for Multi-unit Plans and Applies

We’ve made the logs for multi-unit plans and applies easier to read. When running a --all plan or apply, the STDOUT from the underlying OpenTofu/Terraform process can interlace between units. Terragrunt’s log format capability now enables Gruntwork Pipelines to annotate each log line with its originating unit and collate them for clear, organized display in your pull or merge request comments.

Azure & Custom Authentication

Gruntwork Pipelines now supports native Azure authentication, along with a built-in mechanism to execute custom scripts for providing authentication credentials to Terragrunt. This makes it easy to use Pipelines with any preferred cloud provider.

We’ve introduced an azure_oidc block inside the Gruntwork HCL configuration specification, where you can specify your tenant_id, subscription_id, and client_id for plans and applies:

# my_azure_environment.hcl

environment "my_azure_subscription" {
  filter {
    paths = ["my-azure-subscription/*"]
  }

  authentication {
    azure_oidc {
      tenant_id       = "a-tenant-id"
      subscription_id = "a-subscription-id"
      plan_client_id  = "plan-client-id"
      apply_client_id = "apply-client-id"
    }
  }
}

Within any given environment, you can also define a custom block with an auth_provider_cmd, which executes before each Terragrunt run. This allows you to fetch secrets, perform custom OIDC flows, or integrate with other systems. See this page for examples.

Advanced Filtering for Drift Detection

Drift Detection now supports advanced filters, allowing you to detect drift only where it matters most while excluding areas where drift is expected or benign. This helps your team focus remediation efforts on the changes that count.

You can include a comma-separated list of paths to check for drift. For example, to detect drift only within your management account, use the management/** filter. Check out our docs for more details.

Account Factory & Drift Detection for GitLab

We’re excited to announce general availability of Account Factory and Drift Detection for GitLab customers — available on both enterprise and non-enterprise plans!

Account Factory provides a faster, more consistent, and governed way to provision new AWS accounts and GitLab projects in one GitOps-drive workflow. Benefits include:

• Speed — Fewer tickets and no manual AWS setup
• Consistency — Secure, repeatable baselines for every account and repo
• Visibility & governance — GitLab reviews, audit logs, and least-privilege defaults
• Scalable onboarding — Teams simply open a merge request to get started

Drift Detection ensures all of your cloud resources remain in sync with your IaC, offering automated remediation plans and applies. You can run it manually or on a schedule, with advanced filters to target only specific accounts or directories.

Upgrade using our migration guide and follow our installation docs to get started. If you’d like help setting up Account Factory for your teams, reach out at support@gruntwork.io.

Terragrunt Updates

Pre-1.0 Deprecations are Complete

All pre-announced deprecations for the upcoming 1.0 release are now official. These include:

• Removal of deprecated commands (e.g. plan-all, terragrunt-info)
• Removal of legacy flags (all flags that start with terragrunt-)
• Removal of backend provisioning by default
• Removal of command forwarding by default
• Removal of reading inputs from dependencies
• Removal of deprecated runtime controls (skip, retryable_errors)

If you previously opted into these changes, strict mode is no longer required. Refer to the GitHub issue for guidance on maintaining compatibility.

Advanced Filtering with --filter

We’re introducing a flexible new filtering capability for easily targeting specific Terragrunt units with your commands. The --filter flag accepts a query string supporting filters by name, path, attributes, Git reference, or combinations thereof.

It provides:

1. A unified way to include or exclude units with a single flag
2. Consistent unit targeting units across multiple commands
3. And, coming soon, Git-based change detection and heterogenous runs via one Terragrunt command

Here are a few simple examples:

# plan any unit named `acme`
$ terragrunt run --filter='acme' plan

# plan the unit at relative path `./acme`
$ terragrunt run --filter='./acme' plan

# plan any units matching the glob `./acme/**/foo`
$ terragrunt run --filter='./acme/**/foo' plan

Try it out today using the  --experiment filter-flag option. See the Filter Flag RFC for details. Full functionality is coming soon with the release of Terragrunt 1.0!

Faster Deployments with Runner Pools

Runner Pools replace Terragrunt’s group-based execution with a dynamic pool that schedules units as soon as dependencies resolve. This increases efficiency, reduces bottlenecks, and limits the impact of failures, allowing large run --all invocations to complete faster (on average) and more reliably.

Runner pools are available starting in Terragrunt v0.89.0. See the original RFC for details.

At-a-Glance Run Summaries

The new Run Summary and Run Report features give you clear visibility into each Terragrunt run, surfacing results, failures, and performance insights.

At the end of a queue-based run — for example, terragrunt run --all plan — Terragrunt now prints a compact summary of the number of units executed, their outcomes (succeeded/failed/exited early/excluded), and the total runtime:

$ terragrunt run --all plan

# … (logs of individual units) …

❯❯ Run Summary  3 units  62 ms
   ────────────────────────────
   Succeeded     3

You can add --summary-per-unit for more detail about each unit, or suppress summaries with --summary-disable.

$ terragrunt run --all plan --summary-per-unit

# … (logs of individual units) …

❯❯ Run Summary  3 units     10m
   ──────────────────────────────
   Succeeded (3)
      long-running-unit     10m
      medium-running-unit   12s
      short-running-unit    5ms

For structured output, use --report-file to generate a JSON or CSV file containing complete details of your runs.

Run reports are available starting in Terragrunt v0.89.0. Read the Run Report docs for additional details.

OpenTofu Provider Cache

OpenTofu Auto Provider Cache Dir delivers an immediate performance boost for OpenTofu users in Terragrunt, with no configuration required. We thank the OpenTofu team for continuing to make OpenTofu the best tool to integrate with Terragrunt.