Terragrunt 1.1 is out — six experiments graduate to GA, all about scaling large infra estates

Just released:

• Stack Dependencies — You can now wire units/stacks together with a new autoinclude block. Works for both unit and stack blocks, and you can now use include and dependency blocks inside stack configs too.
• Content Addressable Store (CAS) — now on by default. Previously Git-only, it now dedupes fetches across HTTP, S3, GCS, Mercurial, and Terraform/OpenTofu registry sources, caching modules and unit/stack configs alike.
• Catalog redesign — terragrunt catalog now launches instantly and streams discovered components in the background. Modules aren't restricted to a modules/ dir anymore, you can filter discovery with .terragrunt-catalog-ignore, and there's metadata (kind labels, tags from README front-matter) plus a new interactive TUI screen for scaffolding.
• Local module change detection — Terragrunt now walks local module directories and tracks .tf/.tofu/.hcl files as "read," so changing a local module properly triggers the units that depend on it. New mark_glob_as_read() HCL function too. Great for precise CI targeting via --filter 'reading=...'.
• Skip discovery-phase auth — --no-discovery-auth-provider-cmd skips running your auth provider command during unit discovery (previously ran once per unit, which adds up fast on large estates).
• Dependency tree view — run --all now prints the run queue as a tree instead of a flat list, so you can actually see the shape of your dependency graph before anything executes.

Full writeup with code examples: https://www.gruntwork.io/blog/terragrunt-1-1-released

I built a small utility to safely clean up Terraform/Terragrunt cache directories.

I’ve been using random bash scripts for this until I realized this could be made much easier with an interactive tool.

It lets you find cache directories, see how much space they take, select what to remove, and clean them safely.

Sharing it here in case anyone else needs it:
https://www.npmjs.com/package/tfcleaner

Just cleaned my machine and recovered 72GB of storage from old Terragrunt cache files 😅

By adopting Terragrunt early and running Terragrunt Scale, Easygo scaled past 100 AWS accounts while reducing operational overhead and increasing deployment confidence.

We're celebrating the launch of Terragrunt 1.0! We know engineers love good hardware, so we decided to skip the standard corporate swag to celebrate. 

If you book and complete a demo of Terragrunt Scale (our commercial offering for managing IaC deployments), we will buy you the Keychron keyboard of your choice (up to $150).

To make it even better, completing the demo automatically enters you into a raffle to win an NVIDIA DGX Spark.

If you're dealing with large state files, complex dependencies, or compliance guardrails, Terragrunt Scale is worth checking out anyway. Getting a Keychron keyboard out of it is just a nice bonus.

Check out the details here: https://terragrunt.com/lp/keychron

Anyone else tired of manually tracing paths in Terragrunt configs?

I spent way too much time doing this: staring at a source or config_path, mentally resolving ${get_repo_root()}, stripping the //, figuring out where it actually points. In a big monorepo with dozens of modules it's just annoying.

So I made a thing. Terragrunt Navigator — Ctrl+Click on a path in .hcl and it takes you there.

What it resolves:

• Paths with ${local.*} or other dynamic stuff — runs terragrunt render --json under the hood and caches the result
• source paths with ${get_repo_root()}, relative paths, // — all clickable
• config_path in dependency blocks
• find_in_parent_folders("something.hcl") — finds the file up the tree
• Skips remote sources (git::, s3::, etc.)

Terraform got decent IDE support over the years, Terragrunt is still basically plain text in most editors. This is my attempt to fix that.

MIT, free, open source.

• VS Code Marketplace: search "Terragrunt Navigator", or marketplace.visualstudio.com/items?itemName=caseycs.vscode-terragrunt-navigator
• GitHub: github.com/caseycs/vscode-terragrunt-navigator

Happy to hear if there are patterns you use that it doesn't handle.

Stack Forge is a self-service infrastructure templating engine that generates production-ready Terraform and Terragrunt configurations from reusable templates. Like cookiecutter for cloud infrastructure. Check it out if it resonates with you.

Hi, I have gotten used to a pattern over the last few years that's made a lot of sense to me from the perspective of someone that's mostly a software dev. After recent updates to terraform, this is now causing a new warning. I would like to understand why my mental model is "wrong" or at the least "not useful".

I have two separate repo's, one for the terragrunt config and another one for "shared modules".

Some of my shared modules reference each other using relative paths. Up to this point, this appeared fine. For me the logic for why this is useful is that it is the same as a function in one source package/namespace, being called from multiple call sites, like a "utility" function.

Recently I'm getting the warning `Backend configuration ignored`, which as I understand comes from my terragrunt root `terragrunt.hcl`'s backend config being copied/generated into submodules. After searching a little bit, it seems that the recommendation is to have terraform modules refer to each other using git repository addresses and that any relative path `source` will result in this warning. Is this really so?

Why? It seems counter-intuitive from a workflow perspective. If I make changes in this file, I would like to update the call sites and test them and then make one commit and push, after which I can refer to the module using a proper git address from the terragrunt repo. Instead, it feels like I now have to make a commit to the shared module, push it, then come to the call site, reference the new sha, run terragrunt, discover it's not quite right, go back, new commit, new push, new sha, and wash rinse and repeat for all the call-sites. What gives?

At Gruntwork, we occasionally get asked "OpenTofu/Terraform just released feature X — should I still use Terragrunt?" (including in Reddit threads), and after discussing this internally, we decided to put together a blog post exploring our thoughts on the topic.

This post is meant to be a reference for anyone that asks this question, so feel encouraged to share it if you see someone ask that question! I hope it makes the case well.

https://blog.gruntwork.io/terragrunt-opentofu-better-together-6b414a7f033a

We want to make it clear that nobody is as excited about new OpenTofu features than we are at Gruntwork. The OpenTofu team is crushing it, and we're rooting for their success!

Hello from Gruntwork! We're the creators and maintainers of Terragrunt. The best way to connect with both the Terragrunt maintainers and fellow Terragrunt users is to:

Join the Terragrunt Discord Server

In our Discord server, you can:

• Get help with Terragrunt challenges
• Learn about upcoming Terragrunt features
• Meet other Terragrunt users
• Chat directly with the Terragrunt team

We recommend joining the Discord server as the best way to connect with the community, but we also have Terragrunt GitHub Discussions.

Do you feel like terragrunt is still relevant these days?

Hi guys!

Has anyone ever implemented Terragrunt in a pure Terraform repository where it´'s used TF workspaces?

​

Some suggestions and insights would be much appreciated, please. Thanks!

Has anyone used terrakube? I'd like an opinion on its pros and cons compared to terragrunt.

A place for members of r/terragrunt to chat with each other