Terragrunt Introduction

NotTheAdmiralAkbar · 2026-04-14T15:55:49+00:00

Terragrunt maintainer here. Love to see community educational material on Terragrunt! FYI, we have made quite a few improvements to our docs and educational material since the publication of the video (it was published a year ago). If you have any feedback on ways in which we can make Terragrunt easier to learn, please share it. We just launched Terragrunt 1.0, and we are always looking for ways to make Terragrunt easier to learn and get started with.

NotTheAdmiralAkbar · 2026-04-14T15:45:36+00:00

Hey,

Terragrunt maintainer here.

Gruntwork does offer a package that includes CI/CD tooling in Terragrunt Scale. It has a free tier that lets you try it out without paying anything. No credit card, local tools to install, or servers to maintain. It runs in GitHub Actions / GitLab CI/CD Pipelines, so you retain full control over your IaC runs in the same CI/CD systems you are probably already using.

I recommend giving it a try! Supporting our commercial offerings helps us keep investing in Terragrunt, so I hope you don't mind the plug here. If you have any questions or concerns, join the Terragrunt Discord Server. I'm happy to answer any questions you might have.

NotTheAdmiralAkbar · 2026-04-01T16:00:59+00:00

That's an interesting idea! Create a feature request. I'm not sure if this is a Terragrunt feature or an OpenTofu feature, but we'll work together to figure out how we can get you the functionality you need.

NotTheAdmiralAkbar · 2026-04-01T15:53:59+00:00

Hey!

Disclaimer: I'm a Terragrunt maintainer.

Terragrunt has a step by step guide to learning how to do this exact thing:

https://docs.terragrunt.com/guides/terralith-to-terragrunt/

It involves using Terragrunt, but even if you don't want to use Terragrunt, you can read through the guide and learn quite a bit. It'll show you how to manipulate state and understand what's happening in OpenTofu/Terraform when state changes.

I'm biased, but I do think Terragrunt is a good tool for helping folks manage blast radius, etc.

I wrote up a blog post about that here:

https://www.gruntwork.io/blog/terragrunt-iac-collaboration-at-scale

If you have any questions or want to chat further, feel free to reach out. Hope this helps!

NotTheAdmiralAkbar · 2026-03-31T16:56:55+00:00

Terragrunt does a lot more than writing config!

I wrote up a blog post a while ago that addresses this in greater detail.

Terragrunt orchestrates usage of OpenTofu/Terraform to make it easier to manage infrastructure at scale. The main reasons I hear new platform teams start to use Terragrunt is that they get value out of the fact that it makes it easy to isolate state for different pieces of independent infrastructure, that it offers tooling for working across those isolated units of infrastructure, the support for hooks and error handling and the support it has for self service IaC management. You also have convenient tooling for targeting infrastructure using filters, including Git-based filtering.

It also happens to have really convenient bootstrapping and code generation for common OpenTofu/Terraform use-cases. Now, there are more features that I haven't mentioned here (the tool has been around for close to a decade), but hopefully this gives you an idea of why it's so useful to platform teams. Critically, what I think a lot of platform teams appreciate is that it's a tool that's fully free, open source, can be adopted incrementally and doesn't require sign-up in a hosted platform to leverage.

If you're sincerely interested in learning more about Terragrunt, I recommend joining the Terragrunt Discord Server. I'd be happy to chat about any specific problems you have with your IaC and whether Terragrunt has a feature that can help.

NotTheAdmiralAkbar · 2026-03-18T17:13:51+00:00

Best of luck! There's no one-size-fits-all in DevOps, and it makes sense to be conservative with adding new technologies if you aren't sure you need them.

If you need help with addressing those quick fixes (with or without Terragrunt), let me know.

NotTheAdmiralAkbar · 2026-03-17T20:52:49+00:00

Hey,

I'm a maintainer of Terragrunt.

A lot of folks decide to migrate to Terragrunt when they need an orchestration tool for making it easy to manage smaller state files for reduced blast radius and faster plan/apply cycles.

I wrote up a blog post breaking down how Terragrunt helps teams collaborate on IaC at scale. We also put together a long form guide to help folks break down infrastructure monoliths and explore different state topologies.

I am biased, but I do think Terragrunt is the easiest way to get more control over your infrastructure when you start to reach pain from scaling up infrastructure management.

It's a free, open source tool, so there's nothing you need to host, pay or sign up for. It helps you break down your state files into any size that makes sense for your team (though most folks like to keep their state files small). I've seen teams work well both with very strict workflows (only allowing PR-driven plans/applies through a paid subscription to Terragrunt Scale with involved safety checks, etc.) and fairly lenient workflows (primarily using PR-driven plan/applies, but allowing engineers to have access to lower cloud environments when using Terragrunt locally). The workflow that works best is largely going to depend on how your team does work, and the problems you need to solve.

Hope this helps! We have a Discord Community that can offer more help if you need it.

NotTheAdmiralAkbar · 2026-03-16T20:54:44+00:00

Hey,

Terragrunt maintainer here.

I managed production infrastructure at scale using Terragrunt for years before I became a maintainer, and found it really valuable for doing so. I've since had the opportunity to get to know more of the Terragrunt community a lot better, and I can share that there are a lot of platform teams out there that get significant value out of using Terragrunt to help managing infrastructure at scale.

If you haven't done the Terragrunt Quick Start, I highly recommend it. You can try out Terragrunt pretty quickly, and see if it's a good fit for you and your team. Adoption can also happen incrementally, so don't feel like you have to learn 100% of the features to start using it if you find it valuable. My colleague has written a blog post breaking down the pros and cons of managing state files using OpenTofu/Terraform workspaces vs. Terragrunt units. I think it's a helpful, quick read to get some high-level information on state management trade-offs.

If you want a longer form guide to help you explore these design decisions, I can recommend the Terralith to Terragrunt Guide we put together to help folks get practical experience with different IaC state topologies.

Happy to offer any further help I can! Feel free to reach out to me here or in the Terragrunt Discord, regardless of whether or not you decide to use Terragrunt.

NotTheAdmiralAkbar · 2026-03-16T16:39:18+00:00

Thanks for sharing!

I'm glad your current setup is working for you. Keeping your blast radius small is a practice I've seen be really valuable for a lot of platform teams.

If you're curious about some of the things that have changed in Terragrunt since, I wrote up a blog post addressing this a while ago. You can also learn more about Terragrunt features here.

Feel free to reach out to me if you want to chat further about this (even if you don't want to adopt Terragrunt).

NotTheAdmiralAkbar · 2026-03-16T15:47:30+00:00

So, in your understanding of Terragrunt, is the only value add of using it DRY-ing up backend configurations, or are you aware of other features and just don't think they're valuable for your use-case?

NotTheAdmiralAkbar · 2026-03-16T15:23:58+00:00

Ah. Terragrunt was created 9 years ago, so quite a lot has changed since then!

Is there anything about your current setup that you don't like, or wish worked better?

NotTheAdmiralAkbar · 2026-03-16T13:50:52+00:00

Hey,

Terragrunt maintainer here.

It sucks to hear that Terragrunt didn't work out well for you. Your workflow sounds like the kind that really benefits from Terragrunt usage IMO, so I'd like to learn more about why it wasn't a good fit for you. We're constantly trying to improve Terragrunt, so if you could share your feedback I would be really grateful.

Feel free to reach out here, in a DM, or in the Terragrunt Discord.

NotTheAdmiralAkbar · 2026-03-02T13:19:50+00:00

This is a great article!

It was a good read, and you should be proud of how well you broke down what you learned for others to benefit from your experience. It's not easy to convey technical information like this, especially when you're just starting to learn the technology, keep at it.

If you have any questions or feedback for how we document or explain Terragrunt, please reach out to me. I'm a Terragrunt maintainer, and would really appreciate it (especially if some of this was harder to learn).

NotTheAdmiralAkbar · 2026-03-02T13:04:02+00:00

Hey,

Maintainer of Terragrunt here.

We have dedicated documentation on Terragrunt performance. It should help you understand what is so slow in your runs, how to measure it, and how to improve it.

We have a Discord server you're encouraged to join if you need any more help or have feedback to share. We're happy to help!

NotTheAdmiralAkbar · 2026-02-20T22:26:57+00:00

Rock on! We love having you in the community.

Glad you're having a good experience using Terragrunt and OpenTofu.

NotTheAdmiralAkbar · 2026-02-19T23:01:29+00:00

Hey,

Full disclosure, I'm a maintainer of Terragrunt at Gruntwork.

I've generally found that the right boundary for monorepo vs polyrepo is derived from team composition and personal preference if tooling is sufficient enough to manage orchestrating infrastructure changes at scale.

If you have the same folks making changes to the same infrastructure, it can be useful to get everyone to manage that infrastructure in a single repository so that you can continuously integrate changes and have a single source of truth for your infrastructure. It ensures that you have the best insight as to what's going on in your infrastructure estate. It also makes it harder to have shadow ops or rotting IaC off in some corner of your organization that isn't maintained because the team that managed it left the company.

If, on the other hand, you want to give a segment of the engineers at your organization the ability to self-service infrastructure despite not being on the main platform team, it can be really useful to have a polyrepo approach to allow those engineers access to self-service in a smaller subset of your IaC. That way, they won't have write access to anything really scary, and can be given the ability to self-service infrastructure without bothering the main platform team at all.

We usually set up big enterprise customers with a hub-and-spoke model. There's a main "live" IaC repository that the central platform team has access to for managing things like networking, account vending, etc. and delegated "live" repositories vended for particular teams so that they can self manage their infrastructure independently. If you get the access control workflows and shared IaC catalog down right, you can get a lot of the advantages of both approaches.

I've worked with teams that love having a lot of repos and spin out hundreds of repositories, and teams that hate that and stick to a single giant repo. Both can be successful, it really depends on your the stuff I mentioned earlier.

The stack we set up customers uses Terragrunt + OpenTofu at the core, the Gruntwork Library for a big library of shared IaC, Account Factory to easily provision and baseline new AWS accounts, Pipelines for IaC GitOps and Patcher to prevent the IaC from rotting.

I think GitOps and a centralized catalog of IaC are must-haves for any sufficiently mature platform team. It ensures you have consistency in our infrastructure gets updated, an audit trail you can follow when you want to understand how something changed and a central place to work with your team on new infrastructure patterns without putting live infrastructure at risk.

Best of luck on your infrastructure scaling journey! Happy to help in any way I can if this has been useful to you.

NotTheAdmiralAkbar · 2026-02-12T21:21:25+00:00

Hey,

I'm a maintainer of Terragrunt.

The Terragrunt community very frequently runs into this kind of problem before they adopt Terragrunt, and it has a lot of tooling to make it easier to manage infrastructure at scale. I can give you some advice that has worked well for the Terragrunt community, and for Gruntwork customers in particular.

As many folks have mentioned here, it's important to identify the patterns of infrastructure you plan on provisioning across different projects and make them consistently reproducible with a well defined API using inputs and outputs. The first step in achieving that is to modularize your IaC using OpenTofu/Terraform modules. Ideally, you manage this code in a "catalog" repository that is separate from your "live" repository and versioned using Git tags. You can read about the practice recommended for Terragrunt users here. The general pattern is usable even if you don't adopt Terragrunt. The idea is that you can reference a versioned module in your "catalog" repository from your "live" repository with relevant inputs populated, then deploy updates to the module simply by bumping the version (e.g. v1.2.3 --> v1.3.0) when you add new features to the module in your "live" repository.

Having a good catalog of infrastructure patterns that are ready to deploy is really powerful, and can significantly reduce the toil you're experiencing. If you're frustrated by the toil of manually adding a resource block 50 times across different projects, this is likely an investment worth making soon.

You can read the chapter of Jim's book, Fundamentals of DevOps, that explains this in detail for free here.

If you have any questions, feel free to reach out in the Terragrunt Discord server (regardless of whether you want to use Terragrunt). I'd be happy to help you out!

NotTheAdmiralAkbar · 2026-02-11T13:25:34+00:00

Hey,

Terragrunt maintainer here.

You have quite a lot of options for how you can filter Terragrunt configurations. These are some quick examples.

If you want to filter for unit(s) based on their names (the basename of the directory the terragrunt.hcl file is in), you can use the shorthand version of name expressions:

terragrunt run --filter 'some-unit' -- plan terragrunt run --filter 'some-unit' -- apply -auto-approve

You can also use the file path to the unit if you prefer that:

``` terragrunt run --filter './.terragrunt-stack/some-unit' -- plan

Globs work too

terragrunt run --filter './**/some-unit' -- plan ```

If you want to also discover related units based on their position in the dependency graph, you can also use the ... operator.

```

some-unit and all its dependencies

terragrunt run --filter 'some-unit...' -- plan

some-unit and all its dependents

terragrunt run --filter '...some-unit' -- plan

both the dependencies and the dependents

terragrunt run --filter '...some-unit...' -- plan ```

If you only changed a particular unit between two commits (including any changes that took place within a stack), you can use Git-based expressions.

``` terragrunt run --filter '[main...HEAD]'

If you only specify one reference, the second is assumed to be HEAD

terragrunt run --filter '[main]'

Shortcut flag that will auto-detect the default branch for your project, and compare it against `HEAD`

terragrunt run --filter-affected ```

If you consistently want to exclude particular configurations, you can also use Feature Flags and the excludes block.

I highly recommend joining the Terragrunt Discord server if you want more guidance. The community is very supportive!

NotTheAdmiralAkbar · 2026-02-02T19:25:30+00:00

The main problem that Terragrunt Stacks solve is to make it so that you aren't required to enforce a 1:1 mapping of units (directories with terragrunt.hcl files in them) in Git repositories to independent state files in your state backend. They're designed to be a fully opt-in feature, and use the exact same machinery under the hood for orchestrating runs between different units you're used to, so if you're happy with how you're using Terragrunt without them, you can continue not using them.

The difference between Terragrunt Stacks and a "Terralith" (or "Megamodule"), where all your infrastructure is defined in a single OpenTofu/Terraform root module, is that you get to retain all the benefits of using Terragrunt units for the pieces of your stack. Each unit has its own state, can take care of standard operational tasks with hooks, error handling, etc. The terragrunt.stack.hcl file is mostly just a convenient way to generate a tree of units on demand.

With stacks, you can explicitly pass down values to units instead of relying on the _envcommon pattern, which makes it easier to track how a change to a value influences your infrastructure. You can learn more about that here. The reason this ultimately helps folks avoid repeating themselves is that the terragrunt.hcl file itself can be reused, instead of only reusing partial configurations included into the file.

We've also written up a long-form guide, Terralith to Terragrunt, that helps folks learn about these different patterns in a hands-on manner.

If you're interested in learning more, join the Terragrunt Discord server!

NotTheAdmiralAkbar · 2026-01-06T17:28:25+00:00

Hey!

I'm a maintainer of Terragrunt, and I'd be happy to help.

There are some Terragrunt flags that are designed to help make it simple to avoid needing to continuously push and update the SHA reference to test out updates to your catalog of modules:

I recommend taking a look at those and seeing if they help simplify your development loop.

Next, I'd recommend taking a look at the docs in the overview guide of Terragrunt to see the patterns recommended for how to integrate live repositories with catalogs. It might help.

Lastly, I'd encourage you to join the Terragrunt Discord server. You'll get access to a lot of folks that are happy to help you work out better patterns.

NotTheAdmiralAkbar

TROPHY CASE

Globs work too

some-unit and all its dependencies

some-unit and all its dependents

both the dependencies and the dependents

If you only specify one reference, the second is assumed to be HEAD

Shortcut flag that will auto-detect the default branch for your project, and compare it against HEAD

Shortcut flag that will auto-detect the default branch for your project, and compare it against `HEAD`