Gruntwork Pipelines now supports native configuration of authentication to Azure. In addition we’re providing a built-in mechanism to execute custom scripts to provide authentication credentials for Terragrunt executions. This change makes it easy to use Gruntwork Pipelines with any of your preferred cloud providers.

Native Azure Authentication Support

We’ve introduced an azure_oidc block inside the Gruntwork HCL configuration as code specification. This block requires that you specify your tenant_idand subscription_id as well as a client_id for plans and applies. For example:

# 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"
    }
  }
}

Custom Authentication Scripts

Within any given environment, you can also now specify a custom block with a auth_provider_cmd. The provided command will be executed prior to every Terragrunt invocation and can return/inject values into the environment for Terragrunt and ultimately your OpenTofu/Terraform code. This is useful if, for example, you want to fetch secrets from a vault before running, or run a custom OIDC flow for a cloud provider that doesn’t yet have built in support with pipelines. We’ve published a page covering several examples of how to use this new capability. Here’s an example:

# my_cloudflare_environment.hcl

environment "cloudflare_environment" {
  filter {
    paths = ["cloudflare/*"]
  }

  authentication {
    custom {
      auth_provider_cmd = "./scripts/cloudflare-auth.sh"
    }
  }
}

# cloudflare-auth.sh

#!/bin/bash
set -e

# Acquire a Cloudflare API token
# This is just an example of how to acquire a Cloudflare API token from a secrets manager.
# You can use any method you like to set environment variables like this,
# but you are encouraged never to hardcode secrets in your repository.
CLOUDFLARE_API_TOKEN=$(aws secretsmanager get-secret-value --secret-id cloudflare-api-token --query SecretString --output text)

# Output credentials in the format expected by Terragrunt
cat <<EOF
{
  "envs": {
    "CLOUDFLARE_API_TOKEN": "$CLOUDFLARE_API_TOKEN",
  }
}
EOF

How to Upgrade

These new capabilities are available now with the GitHub v4 and GitLab v2 releases, which you can update to following our migration guides (GitHub guide) (GitLab guide).

Today we’re formally promoting our HCL Configuration as Code language to Generally Available.  HCL was introduced to provide a significantly more expressive and flexible mechanism to model your DevOps estate. HCL configurations now cover all the same functionality provided by the YML configuration. See our complete HCL Configuration as Code reference for additional details.

What does this mean for me?

If you’re a GitLab user, you’re all set. If you’re a GitHub user, we strongly encourage you to migrate your configuration to HCL as part of the upgrade to GitHub v4 by following our migration guide. YML configuration is now deprecated and will be removed in the next major release.

We’re excited to announce support for Gruntwork Account Factory on GitLab, bringing the same convenience, speed, and governance of our automated AWS account creation workflow to GitLab users across both Enterprise and non-enterprise plans.

This integration lets you provision new AWS accounts and GitLab projects together through a single, GitOps-driven workflow. If your teams already live in GitLab, you can now manage the entire lifecycle of your AWS accounts using merge requests and pipelines, just like the rest of your infrastructure, giving you:

• Speed — fewer tickets, no manual AWS setup.
• Consistency — every account and repo starts with a secure, repeatable baseline.
• Visibility & governance — GitLab reviews, audit logs, and least-privilege defaults.
• Scalable onboarding — teams just open a merge request to get started.

Gruntwork Account Factory is available to all Gruntwork Platform customers as of the Gitlab v2 release. To upgrade, follow our migration guide. If you’d like to configure Account Factory for your teams, the Gruntwork team is standing by to assist at support@gruntwork.io.

Drift Detection now supports advanced filtering. This makes it easy to detect drift only in the areas that need it, while excluding parts of your infrastructure where drift is either expected or common. This avoids unnecessary work and helps your team build confidence in resolving the drift that matters.

The filter parameter accepts a comma-separated list of paths to be included when checking for drift. For example, to perform drift detection exclusively within your management account, you might supply the management/** filter. The filter can be combined with the Ignore List (which uses the same syntax) to further limit the units that are checked for drift.

To add a drift detection filter:

• GitHub users can add this filter as a workflow parameter for manual runs, or by supplying a default to the pipelines_drift_detection_filter input parameter in your .github/workflows/pipelines-drift-detection.yml file for scheduled runs.
• GitLab customers can supply the filter to the pipelines_drift_detection_filter input of their pipeline for both manual and scheduled runs.

Advanced drift detection filters are available now with the GitHub v4 and GitLab v2 releases, which you can update to following our migration guides (GitHub guide) (GitLab guide). See the filter documentation for additional details.

Perusing the logs for multi-unit plans is about to get much better. Today we’re announcing de-multiplexed logging in Terragrunt Pipelines, which makes it easy to review logs for each individual unit in your change independently. When running a --all plan or apply, the STDOUT of the underlying OpenTofu/Terraform process is interlaced. However, using Terragrunt’s log format capability, Gruntwork Pipelines will now annotate the logs with the unit they originate from, and then collate those logs for convenient display in your pull/merge request comment.

Here’s what it looks like. Note how the output for each bucket is displayed separately, so you can easily understand how each unit is impacted by your change.

De-multiplexed logging is available now with the release of GitHub v4 (migration guide) and GitLab v2 (migration guide)

Drift Detection is now fully supported on GitLab, bringing the same set of capabilities GitHub users have enjoyed. This includes:

• On-demand drift detection runs
• Scheduled drift detection runs
• Automated drift remediation plans/applies
• Advanced filtering for both on-demand and scheduled runs

Drift Detection is available now with the GitLab v2 release. To update, follow our migration guide. To start using Drift Detection, follow the steps in this guide to update your .gitlab-ci.yml file and then create a new drift detection pipeline.

Gruntwork Patcher now natively supports Terragrunt Stacks. Stacks help you manage infrastructure at scale by logically grouping OpenTofu/Terraform units into versioned entities, keeping your IaC DRY and your blast radius small. For a detailed overview, see our announcement blog post.

Now, when you release new versions of your unit and stack definitions, Patcher automatically detects these changes and ensures all stacks referencing previous versions receive the corresponding updates. Specifically, Patcher will:

1. Update the version of a unit definition specified as a source in a terragrunt.stack.hcl file in your catalog repo when a new unit version is released
2. Update the version of a stack definition specified as a source in a terragrunt.stack.hcl file in your catalog repo when a new stack version is released
3. Update the version of a unit specified as a source in a terragrunt.stack.hcl file in your live infrastructure repo when a new unit version is released
4. Update the version of a stack specified as a source in a terragrunt.stack.hcl file in your live infrastructure repo when a new stack version is released

This functionality is available now. Using Patcher with Terragrunt Stacks lets you maintain DRY code while preserving flexibility in which versions deploy to each environment, and we now recommend versioned stacks over the _envcommon pattern. Refer to the migration guide for more information on using versioned stacks.

We're excited to introduce significant improvements to how Gruntwork Pipelines detects and processes changes in your infrastructure code. These enhancements make Pipelines more predictable and responsive to the full range of modifications in your codebase.

We've added several opt-in feature flags that you can enable by setting environment variables in your Pipelines configuration. You can enable these independently, or set PIPELINES_FEATURE_EXPERIMENT_ALL to true to enable the full set of functionality described below.

We expect to enable these behaviors by default in a future major version of Pipelines. Check out our feature flags documentation for more details on how to implement these improvements in your workflow in the meantime.

Improved Unit File Change Detection

Feature Flag: PIPELINES_FEATURE_EXPERIMENT_COLOCATED_FILE_UNIT_CHANGE_DETECTION

This flag enhances how Pipelines detects changes within Terragrunt Units (any non-root directory of the repo that contains a terragrunt.hcl file) to better align with our semantic notion of a unit.

When enabled, any file modified within a Terragrunt Unit will trigger a ModuleChanged event for that unit, causing Pipelines to run a Terragrunt Plan/Apply operation for the affected directory. This includes files like terragrunt.lock.hcl and other support files within the unit. Previously, these would trigger a FileChanged event, which disregarded the semantic connection to the unit being affected.

For example, consider a unit containing these files:

tags.yml
dir1/terragrunt.hcl
dir1/myvars.json

With this new flag enabled:

• A change to dir1/myvars.json is detected as a ModuleChanged event for dir1, triggering a Terragrunt Plan/Apply for this directory.
• A change to tags.yml is still detected as a FileChanged event, causing Pipelines to run Terragrunt with queue-include-units-reading for this file.

Smarter Change Consolidation

Feature Flag: PIPELINES_FEATURE_EXPERIMENT_AGGRESSIVE_CONSOLIDATION

This flag improves how Pipelines consolidates and executes Terragrunt operations to improve dependency handling and minimize redundant change execution. When enabled, Pipelines will consolidate as many Terragrunt plan/apply changes as possible into a single run --all job. This reduces duplicated work when, for example, both FileChanged and EnvCommon events would trigger plans for the same unit.

Minimizing Blast Radius

Feature Flag: PIPELINES_FEATURE_EXPERIMENT_MINIMIZE_BLAST_RADIUS

Safety is a core principle of Gruntwork Pipelines. In that spirit, we’re making improvements to ensure that the blast radius of your changes remain as localized as possible by default. With this flag enabled, Pipelines will execute Terragrunt run --all with the --queue-strict-include option, which helps reduce the blast radius of per-unit changes as dependencies will no longer run automatically when dependents are modified. This ensures that run --all behaviors are consistent with runs for individual units.

Tired of triggering Pipelines on README updates? We've added a file exclusion mechanism to help you focus Pipelines on what matters. The new ignore list lets you exclude specific files and directories from change detection, such as documentation files, test fixtures, or any other non-infrastructure files that change frequently.

Add the ignore_list key to the repository block of your Pipelines config.yml. This supports a comma-separated list of patterns with wildcards, allowing you to exclude files like documentation (**.md), specific files in any directory (README.md,**/README.md), or entire directories and their contents (docs/**). Check out our docs for the complete syntax and additional examples.

Good news for GitLab users! Gruntwork Pipelines now supports GitLab Enterprise Self Hosted instances, in addition to our existing GitHub Cloud support.

This means you can now get all the great features of Pipelines right within your own self-hosted GitLab environment. Going self-hosted gives you more flexibility and control over your runtime, security, and compliance.

It's ready to go right now, check out the docs for more info on how to get started!

Stay tuned as GitHub Enterprise / Self Hosted support is also on the way.

Gruntwork Pipelines now natively supports Terragrunt Stacks. Stacks help you manage your infrastructure at scale by logically grouping collections of OpenTofu/Terraform units into versioned entities, keeping your IaC dry and your blast radius small. For a detailed overview, see our announcement blog post.

Now when you push updates involving terragrunt.stack.hcl files in your pull/merge requests, Gruntwork Pipelines automatically evaluates the required changes and orchestrates the necessary infrastructure updates. This process ensures:

1. Small IaC Footprint: Pipelines uses terragrunt stack generate to identify impacted units, so you don't need to check in the generated units—only the terragrunt.stack.hcl files.‍
2. Minimal Blast Radius: Pipelines identifies the minimum set of infrastructure units affected by your changes, avoiding unnecessary operations and limiting risk.‍
3. Complete Management: All relevant infrastructure actions triggered by your terragrunt.stack.hcl updates (create, read, update, destroy) are handled automatically.‍
4. DAG Aware Execution: Updates are applied while respecting the dependency graph (DAG) order so that adds, changes, and destroys all occur successfully.

You can freely mix changes to terragrunt.stack.hcl and terragrunt.hcl files within the same Pull/Merge Request. Pipelines will handle the rest.

This functionality is available now for both GitHub and GitLab. Refer to our docs and the migration guide for more information on how to get started with stacks.

At Gruntwork, we’re always shipping new features—but we know it can be hard to keep track with updates spread across multiple tools. That’s why we’re excited to launch our new Product Changelog: a single place to stay up to date with the latest improvements and highlights.

We’ll keep it short, sweet, and useful. This isn’t a full list of every change, and we won’t use it to market to you—just quick, meaningful updates with links if you want to dive deeper.

Have thoughts or feedback? We’d love to hear from you! Let us know at feedback@gruntwork.io.