Gruntwork Newsletter, Summer 2026

Every few months, we round up what's new across Gruntwork and the broader DevOps ecosystem. This issue covers what we've shipped from April through August 2026 — from major open-source milestones to practical improvements you can start using right away. 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, reach out at support@gruntwork.io.

In This Issue

• Gruntwork Library MCP Server
• Extending Your Pipeline With Hooks
• Cost Estimates In Your PRs
• Pipelines Comment Consolidation
• Terragrunt 1.1, Terratest 1.0 & Terratest 2.0 beta
• Industry Updates

Gruntwork Library MCP Server

We've launched an MCP (Model Context Protocol) server that connects your AI coding assistant — Claude Code, Cursor, and others — directly to the Gruntwork IaC Library. Instead of generating infrastructure code from training data, your assistant can now search our full catalog of 285+ production-tested modules, read their documentation, browse working examples, and follow Gruntwork best practices.

The server is in private beta — contact us to enable MCP access for your account, then generate an access token in the Developer Portal and add a single line to your tool's configuration. See the setup guide for details, or contact us at support@gruntwork.io to get started.

If you're thinking about how to use AI coding assistants for infrastructure work without losing control over production changes, our guest post on velocity without losing control is a good companion read.

Extending Your Pipeline With Hooks

Pipelines can now run your own scripts as part of a pipeline run. Hooks, a new Enterprise feature, let you extend Pipelines plans and applies with custom logic: notify external systems, enforce policies, generate reports, or integrate with internal tooling. Each hook returns pass, warn, or deny (which blocks merge), and its output appears directly in the pull request comment, so reviewers see your custom checks alongside the infrastructure plan.

Here’s an example of what hooks look like:

Hooks are declared in the repository block of your gruntwork.hcl, can be configured with environment variables, and can be scoped to specific infrastructure. You can declare as many hook blocks as needed, with different parameters.

repository {
  after_hook "policy_scan" {
    name     = "Policy Scan"
    commands = ["plan"]
    execute  = [".gruntwork/hooks/policy-scan.sh"]

    env {
      # specify any configuration for the hook as environment variables
    }

    filter {
      # limit the set of infrastructure the hook applies to by path, label, or environment
    }
  }
}

You can also store your hook scripts in a shared location outside the infrastructure repository, making it easy to share versioned hooks with all your infrastructure repositories. Declare a source on the hook and Pipelines fetches it before the hook runs.

Hooks are available today as of GitHub v4.19.0 and GitLab v2.14.0; remote script sources landed in v4.20.0 and v2.15.0. See the documentation for setup instructions and additional details.

Cost Estimates with the new Infracost Hook

Cost surprises usually show up in the monthly bill, long after infrastructure changes were applied. Our new Infracost hook provides a cost estimate directly on each pull request, giving you and your team immediate insight into the cost impact of each change.

repository {
  after_hook "infracost_estimate" {
    name     = "Infracost Estimate"
    commands = ["plan"]
    execute  = ["pipelines", "hook", "infracost@v0"]

    env {
      INFRACOST_API_KEY = "" # learn how to provide this secret in docs
    }
  }
}

The hook uses the Infracost CLI to estimate the cost of every unit a run affects and reports it on the pull or merge request: a summary line showing the change to your monthly bill, plus a table breaking that down by unit. Usage-based costs (requests, storage, data transfer) are projected from Infracost Cloud's defaults, or from your own infracost-usage.yml if you commit one to the repo root. Additionally, you can configure cost thresholds above which the hook will display a warning, or even block merge if desired.

Infracost is the first of Gruntwork's provided hooks: ready to use by name and version (infracost@v0) with no source block required. It's available as of GitHub v4.24.0 and GitLab v2.19.0. See the docs for additional details, and reach out to support@gruntwork.io if you’d like help with setup or have any feedback to share.

Consolidated Pipelines Comments

Pipelines now offers a new option to consolidate status update comments into a single pinned comment on your pull requests and merge requests, rather than posting a new comment on every push.

To enable it, add this to your .gruntwork/repository.hcl or gruntwork.hcl:

repository {
  status_update {
    new_comment_per_push = false
  }
}

This keeps your PRs cleaner and makes it easy to find the latest status at a glance. This feature is available as of GitHub v4.12.0 and GitLab v2.9.0.

🎉 Terragrunt 1.1

Terragrunt 1.1 is here! Six long-running experiments have graduated to General Availability — no --experiment flag required:

• Stack Dependencies — declare relationships between units inside a stack up front with autoinclude blocks, so dependents can reference stack outputs directly.
• Content Addressable Store (CAS) — dedupes source downloads by content hash, now covering Git, HTTP, S3, GCS, Mercurial, SMB, and OpenTofu/Terraform registry sources.
• A redesigned terragrunt catalog — discovers components across repos without upfront configuration, streams results into the TUI, and supports interactive scaffolding.
• Change-detection for local modules — the new mark_glob_as_read() function lets change-based CI runs account for edits to local .tf/.hcl module files.
• Faster discovery via --no-discovery-auth-provider-cmd, which skips auth during discovery on large repos.
• A clearer run queue — run --all now renders the unit queue as a nested dependency tree before executing, instead of a flat list.

Releases are also now published as immutable GitHub releases, with the install script verifying downloads against attestations.

A follow-up patch, v1.1.2, added a 7–10x speedup to find_in_parent_folders() (a big win on deeply nested estates), a ctrl+d shortcut to instantly scaffold a component from the catalog TUI, and new experimental support for OpenTelemetry log export, CPU/memory profiling, an Azure Storage backend, and OCI registry module sources.

For the full breakdown, see the Terragrunt 1.1 announcement and release notes. If you want to go deeper, we also published guides on the Content Addressable Store, the filter flag, and the autoinclude block.

🎉 Terratest Hits 1.0, Too

After a decade of development, Terratest — our open-source Go library for testing infrastructure code — has reached 1.0. The release adopts semantic versioning and brings context plumbing and mockable SDK clients across its cloud helpers, making tests easier to write and maintain.

Additionally, a public beta of Terratest 2.0 is now available. Terratest 2.0 restructures the library into composable modules that can be imported individually to address specific infrastructure testing needs.

Over time, the surface area of Terratest has increased to include packages for testing many types of tools—Terragrunt, OpenTofu, AWS, Azure, GCP, OCI, Docker, Kubernetes, Helm, OPA, Packer, and more. In v2, you can opt to install only what you need for your tests. For example, you can now import the dedicated Terragrunt module without pulling in dependencies for Kubernetes or OPA unless you choose to.

This is a breaking change, but migration can be done gradually. Learn how to get started with the Terratest v2 migration docs. We're excited to hear how Terratest v2 works for you! Please try it out and share any feedback during this beta period.

Industry Updates

A few notable developments from the broader ecosystem and our own customers this summer:

Informa's Migration from Terraform to OpenTofu

Informa migrated from Terraform to OpenTofu via a phased rollout across many repositories and AWS accounts — and reported no consumer-facing issues along the way. It's a good proof point for any team considering the same move.

Easygo Scales AWS 10x While Cutting Maintenance 90%

By adopting Terragrunt and Terragrunt Scale, Easygo grew from 10 to over 100 AWS accounts with a 20-engineer team, while cutting pipeline maintenance work by roughly 90%.

AI Agents and Infrastructure as Code

A widely-shared story this spring — an AI agent that wiped a production database by acting on the wrong Terraform state — was a sharp reminder that AI coding assistants need guardrails, not just capability, when they touch production infrastructure. We shared our own thoughts on using AI safely with Terraform; it's a useful read alongside the MCP Server launch above.

Wrapping Up

It's been a busy summer:

• A new way for AI coding assistants to work directly against the Gruntwork IaC Library
• New Pipelines Hooks for Enterprise customers, Infracost cost-estimation in every PR, and cleaner PR comments
• 🎉 Terragrunt 1.1 and Terratest 1.0, two major open-source milestones, with Terratest 2.0 on the horizon
• Strong customer results from Informa and Easygo

We look forward to sharing more in the coming months!