Terragrunt v1.2.1: Security Fix, Faster Discovery, and Shared Config Parsing

Introduction

Terragrunt v1.2.1 is out, bumping from v1.1.6. This release is mostly a performance and process update: a Go security patch, an internal change to how git, hg, and smb:// sources are downloaded, and several discovery/parsing speedups that matter most on large monorepos with many units. There are no breaking changes called out in the release notes.

Release page: https://github.com/gruntwork-io/terragrunt/releases/tag/v1.2.1

What Is New

Go bumped to v1.27.3 (security fix)

The Terragrunt binary is now compiled with Go v1.27.3, up from v1.27.2. This is a security release that fixes CVE-2026-111943 in crypto/x509: certificate verification now rejects chains containing a small set of untrusted intermediate certificates. Terragrunt relies on this verification for every HTTPS connection it makes — source downloads, provider registry lookups, and remote state backends — so an upgrade is recommended for anyone running Terragrunt in CI or production.

Terragrunt now runs git, hg, and smbclient downloads itself

Previously, git::, hg::, and smb:// source downloads went through getters built into the go-getter library, which started git, hg, and smbclient on their own. Terragrunt now implements these getters itself and invokes those binaries the same way it runs any other command. Functional behavior for downloads should be unchanged; if you notice a difference, the release notes point to opening an issue at https://github.com/gruntwork-io/terragrunt/issues. As a side effect, Terragrunt's own test suite can now exercise these code paths without needing a real git, hg, or smbclient install or a remote server.

Faster parsing of shared configuration

Repositories where every unit includes a root.hcl that pulls in shared files via read_terragrunt_config now parse significantly faster:

# root.hcl
locals {
  common = read_terragrunt_config(find_in_parent_folders("common.hcl"))
}

Previously, each unit parsed shared files like common.hcl independently, so a yamldecode(file(...)) call on a large YAML file was repeated once per unit. Terragrunt now parses each file once and reuses the result across units, re-parsing only when the file (or something it reads) changes during the command. run --all re-parses once more after unit discovery. Configuration that can legitimately differ per unit — for example anything using get_original_terragrunt_dir() or containing dependency blocks — is still parsed per unit, as expected.

Additional parsing overhead was removed: since v1.1.2, discovery parsed every included configuration twice (once for feature flag defaults, once to merge it); it now parses each include once and skips includes with merge_strategy = "no_merge" that would previously have been parsed and discarded. Locals and inputs also skip an unnecessary JSON round trip on the way into Terragrunt.

Benchmarks on an Apple M3 Max, for a generated repo where units read a 48 KB YAML file via read_terragrunt_config:

Memory allocated during discovery dropped by about 95%.

Faster discovery with path filters

Terragrunt now analyzes --filter expressions before starting discovery and uses them to narrow the filesystem walk:

# Matches a glob subset of units — walk is narrowed to that subtree
terragrunt run --all plan --filter './doublestar/glob/**'
 
# Names a single unit — walk effectively skipped
terragrunt run --all plan --filter './path/to/specific/unit'

On a 10,000-unit repository, the glob filter above (matching 1,250 units) dropped from 224ms to 27ms, and the single-unit filter dropped from 215ms to under 1ms. Discovery still selects the same units as before. A full walk still happens when there's no filter, every filter is negated, or a filter could match a unit anywhere (e.g. name=vpc or ...vpc).

run_cmd results are now shared across concurrent discovery

When a run_cmd call uses --terragrunt-global-cache, or appears in a file loaded via read_terragrunt_config, its result is meant to be shared across units. Because discovery parses units concurrently, multiple units could previously start the same command before any had cached a result, and run --all could end up running a shared command once per unit instead of once overall. Units now wait for the first run to complete and reuse its result; if that first run fails, the next unit in line retries it.

Documentation: Azure and GCP examples

The Overview docs, Units, Includes, Importing, and the backend bootstrap / backend migrate / backend delete command pages now include parallel Azure (azurerm backend, eastus/westus2) and GCP (gcs backend, us-central1/us-east1) examples alongside the existing AWS ones. Fixtures live under test/fixtures/docs/02-overview-azure and test/fixtures/docs/02-overview-gcp and are exercised by integration tests.

Upgrade Steps

Pin the version and re-run init. If you manage Terragrunt via a version file or wrapper, update that reference as well.

# terragrunt.hcl or root.hcl
terraform_version_constraint  = ">= 1.5.0"
terragrunt_version_constraint = ">= 1.2.1"

# If installed via tenv/tgswitch or a package manager, update the binary first
tenv terragrunt install 1.2.1
tenv terragrunt use 1.2.1
 
# Confirm the binary version
terragrunt --version
 
# Re-initialize working directories
terragrunt run --all init -upgrade

No HCL syntax changes or deprecated attributes are mentioned in this release, so existing configurations should not require edits. If you use git::, hg::, or smb:// source URLs, re-test those downloads in CI after upgrading, since the getter implementation changed internally even though behavior should be unchanged.

Verify

terragrunt --version
# should report v1.2.1
 
# Sanity-check discovery and plan on a representative repo
terragrunt run --all plan --filter './path/to/specific/unit'

On large repos with many units, compare run --all timing before and after the upgrade (e.g. time terragrunt run --all plan --filter ...) to confirm the discovery and shared-config parsing improvements are visible in your setup. If you rely on git::/hg::/smb:// sources, verify a full init succeeds against those sources in CI.

Conclusion

v1.2.1 is a low-risk upgrade: a Go security patch worth applying promptly, an internal rework of VCS source downloads that should be invisible in practice, and discovery/parsing performance work that pays off most in large monorepos with shared root.hcl configs or heavy use of --filter. No breaking changes or deprecations are listed in the release notes; teams on v1.1.6 can move to v1.2.1 with a standard init -upgrade.