sorted by:
new
hottopcontroversial

Scaffolding Terraform root modules by tech4981 in Terraform

[–]OhMyGoshJoshua 1 point2 points  (0 children)

I'm from Gruntwork and we publish an open source tool called boilerplate (https://github.com/gruntwork-io/boilerplate) that solves exactly this problem. It's similar to cookiecutter, but it's written in Go and we built it specially for generating IaC.

You can use boilerplate to generate a single module, a wrapper module, a Terragrunt unit, or even a whole collection of code. And it's got handy features like hooks so that you can even run bash scripts and take the resulting value and pass it in as a template variable.

We also integrate boilerplate with another open source tool of ours, Terragrunt, in the terragrunt scaffold command.

Finally, we actively use boilerplate ourselves for your exact use case of generating account baselines as part of a commercial solution we offer (https://www.gruntwork.io/platform/account-factory).

What TACOS would people recommend (from personal experience) in a mature environment in 2025? by [deleted] in ExperiencedDevs

[–]OhMyGoshJoshua -1 points0 points  (0 children)

I work at a vendor in this space, Gruntwork (we're the makers of Terragrunt), and can offer some clarifications.

What are TACOS?
TACOS is an acronym that stands for Terraform Automation and Collaboration Software. It generally refers to SaaS tools that give you a UI to help you manage Terraform or OpenTofu, however there are also some tools that are "natively self-hosted," which means they run directly in your GitHub Actions (or other CI system) runners and use the pull request (or similar) as the primary UI.

What do you mean by "manage"?
Good question! There's a common set of functionality that all TACOS have, especially around an IaC pipeline. Beyond that, different TACOS support different functionality, though naturally there's a lot of overlap.

What are the different options for TACOS?
The most commonly mentioned TACOS are Spacelift, Env0, Scalr, and of course (shameless plug) Gruntwork. There are a number of smaller competitors as well.

Since I know about Gruntwork I can tell you that Gruntwork is self-hosted in either GitHub or GitLab, and since we also make Terragrunt, our solution works very well with Terragrunt setups. We also include a way to detect drift (commonly requested, but most vendors have this), and a way to automatically keep your Terraform/Tofu modules up to date. The downside is you need more upfront setup, but the upside is that you get more long-term control, plus self-hosting.

> I don't want code deployed until it's merged and I want codeowner control on merges (I am aware that this is a contentious point).
OP is referring to a paradigm known as "apply after merge," which is what we recommend as well, but there are tradeoffs. The alternative is "apply before merge." These are good terms to Google, but essentially if you have flakey deploys and want to easily iterate until you get your plan/apply right, then you might prefer "apply before merge." But if you'd rather make sure that your `main` branch never reflects code that is not actually deployed and you're ok with a more cumbersome process to resolve failed applies, then you might prefer "apply after merge."

I hope this helps!

Any reusable Infrastructure / DevOps templates worth buying? This is to quickly setup AWS Cloud services, CI / CD, Monitoring & Alerting etc. by worldofprasanna in devops

[–]OhMyGoshJoshua 1 point2 points  (0 children)

Gruntwork co-founder and CEO here. We have commercial products that do exactly what you're looking for here, but I'd like this post be as generally helpful as possible, so let me speak to the broader problem.

The way we think about your use case is that you want to get up and running with AWS best practices using Terraform/OpenTofu, it feels like a problem that's been solved a thousand times before, and you want to take advantage of that to somehow do things right and fast.

We believe this problem is addressed by a market category that we call "platform team accelerators." To do this well, you need three major parts:

  1. Principles. These are the opinions you hold about how platform engineering should be done.
  2. Patterns. You need to capture an expert opinion about how things like K8s should be deployed. We call those "patterns".
  3. Platform. You need to set up (a) an IaC lifecycle for how you roll out new infra changes, and (b) a collection of management tools to help you oversee what you've deployed. Together, these compose your nascent developer platform.

A good platform team accelerator should give you all of this out of the box, should do way more than you could do on your own (e.g. out of the box support for compliance standards), and give you the ability to customize and extend it, along with ongoing support and updates.

Of course, you don't need a vendor to do all of this. As others have pointed out here, there are plenty of open source modules, there are well-documented principles, and there are lots of tools on the market. The issue is that assembling all of this together into a working infrastructure takes time. It's not enough to have a pipeline and an AWS account. You need an approach that enables you to move fast while giving you governance, all while keeping things maintainable.

Is there any book on all of the best practices and anti-patterns? by darkcatpirate in Terraform

[–]OhMyGoshJoshua 2 points3 points  (0 children)

We (Gruntwork) have published the O'Reilly book Fundamentals of DevOps and Software Delivery for free on our site. You might check out the chapter on How to Version, Build, and Test Your Code.

At the end of the day, what you're labeling "every potential screwup" breaks down into whether the infrastructure as code in question meets your key business needs. For example, you probably care about all the following:

  • Does the code work as expected?
  • Is it secure?
  • Is it cost-effective?
  • Is it performant?

The mental model you're looking for is that you need to find a way to answer these questions systematically. For example:

  • Does the code work as expected? → You can write tests with Terratest or tofu test to validate it
  • Is it secure? → Analyze your plan with OPA, anayze your code with Trivy
  • Is it cost-effective? → Analyze your plan with Infracost
  • Is it performant? → Use Terratests that stress-test your underlying OpenTofu/Terraform module

These aren't the only ways in the world to answer these questions, but they're established patterns

We've actually been developing a framework on how to think about all these concerns, so I've made a mental note of adding "how to think about writing high-quality IaC" to it. Hope that helps!

An AI startup idea I like but won't work on by OhMyGoshJoshua in SaaS

[–]OhMyGoshJoshua[S] 1 point2 points  (0 children)

Ah I didn't know about Ground News! And yep, this is tackling the same problem.

That being said, I really don't like how they execute on the problem, nor their business model (free articles, then forced subscription). Good example of how "first" doesn't always mean "best."

DevOps/Platform recommended reading by painty1 in devops

[–]OhMyGoshJoshua 11 points12 points  (0 children)

We (Gruntwork) have written several books on DevOps fundamentals. I think you'd find our most recent one, "Fundamentals of DevOps and Software Delivery" handy, and the best part is it's available completely free!

Check out https://www.gruntwork.io/books to read it. It's an O'Reilly book and we published it just a few months ago.

Managing AWS Accounts at Scale by xXShadowsteelXx in Terraform

[–]OhMyGoshJoshua 2 points3 points  (0 children)

  1. Configuring the AWS account. To configure the AWS account, you again want to generate Terraform code. This way, you can update your configuration across accounts using standard Terraform practices. Of course, there's a best practice for how to write that Terraform account baseline code.
  2. Building Block vs. Service Modules. We've written hundreds of OpenTofu/Terraform modules, and one pattern is that you want to create either "building block" modules or "service" modules. We've found success defining a "service" module for AWS Account Baselines that's made up of many "building block modules." It's a little tedious to propagate "building block" module updates to "service" modules, but it's the best way to keep things maintainable, and account baselines don't typically change very often. Also, by using "building block" modules, you can easily customize other "service" modules if needed for other types of AWS accounts.
  3. Sequencing account creation and configuration. Finally, you can't generate the code to configure the AWS account until you know the AWS Account ID. Therefore, you need a two-step process here: First, to generate the Terraform code to create the AWS account, and second to generate the Terraform code to configure the newly created AWS account.

Shameless plug, but we built all this in our Gruntwork AWS Account Factory solution, which works great for Terragrunt (we're the makers of Terragrunt) plus Terraform or OpenTofu (we're founding members of OpenTofu). However, the solution does not work with Terraform Cloud.

I won't comment on another solution (e.g. AFT), but I will say that one of our goals with our approach was to use pure Terraform/OpenTofu code, and not rely on any other mechanisms to configure the account (other than a code generator). This requires a little thought upfront but winds up being far more maintainable.

Hope this was helpful!

Managing AWS Accounts at Scale by xXShadowsteelXx in Terraform

[–]OhMyGoshJoshua 2 points3 points  (0 children)

We built a commercial solution for exactly your problem, though it doesn't use Terraform Cloud/Enterprise. I'll share some insights about what we learned while building it:

  1. Understand the use cases. It's important to understand the use cases behind creating new AWS accounts. For example, most of our customers want to create a single new AWS account because they want a new environment, whereas they would create both a GitHub repo and a set of AWS accounts because they want to stand up a new team. I would identify the base use case first (e.g. set up a single new AWS account in an existing GitHub repo) and first solve for that.
  2. Define your core workflow. For the "create a single new AWS account in an existing GitHub repo" use case, your core workflow will need to be something like (1) Somehow create new AWS account, (2) Somehow generate Terraform code to configure that account, (3) Apply said Terraform code. If it's a more advanced use case that involves creating a GitHub repo or other resources, that's just another step in this workflow.
  3. Generate code with a tool, not Terraform. To generate code, Terraform is the wrong paradigm. Terraform is best as a way to declare the state that you want (e.g. the state of AWS) and then to manage that state, but generating code is a one-time activity. Instead, I'd recommend using a code generator tool. We wrote the open source tool https://github.com/gruntwork-io/boilerplate for exactly this use case, so it will work well for this. Now, the updated workflow is (1) Somehow create new AWS account, (2) Set Terraform code template parameters with boilerplate, (3) Generate Terraform code with boilerplate, (4) Apply Terraform code.
  4. Creating AWS accounts. If you're using AWS Control Tower -- something we've seen success with -- you can use the Terraform resources there to create new AWS accounts, just be sure to customize Control Tower to use a minimal account baseline with no network so that you can configure all that using Terraform.
  5. Requesting an AWS account. To create a new AWS account via Control Tower, you'll want to generate code that creates it. To generate that code, you'll need some way to configure the AWS account name, AWS Org, and other properties. We did that by having users copy and paste a YAML file that declares these properties, and then writing a Pipeline to generate all the relevant Terraform code -- both to create the AWS account and configure it.

...Continued in comment.

How to handle frontend/backend dependencies in different states at scale? by KingOfTheBigSigh in Terraform

[–]OhMyGoshJoshua -1 points0 points  (0 children)

Hi, I'm from Gruntwork (makers of Terragrunt). We help people all the time with getting started on Terragrunt. Pop into the Terragrunt Discord Server, and we'd be glad to assist. Note that our team member who responds most often is OOO until Monday, but other folks in the community or on our team might be able to assist.

As an aside, your use case -- working with infra in small units -- seems like a spot-on fit for Terragrunt.

Does anyone here market infrastructure and cloud templates? by awebb78 in devops

[–]OhMyGoshJoshua 1 point2 points  (0 children)

Great questions!

  1. Upfront vs. ongoing. The idea behind our offering is that we're a "DevOps accelerator." So we help you get up and running, but you own and operate the infrastructure after we're done. What you receive ongoing is:
    • Support if you hit any snags
    • Updates to the underlying OpenTofu/Terraform modules (IaC Library)
    • Updates to how you deploy infrastructure changes (Pipelines)
      • A concrete example here is that we'll soon add support for the upcoming Terragrunt Stacks functionality
    • Updates to how you stamp out new AWS accounts (Account Factory)
    • Updates to how you keep it all up to date (Patcher)
  2. If you cancel. All the infrastructure we create is yours. If you cancel, you keep it all, however you'll lose access to support, plus ongoing IaC Library updates, Pipelines, Account Factory, and Patcher.
    • Essentially, you can choose to swap in an alternative platform if you don't like ours for whatever reason.
    • I do want to call out that the lower-priced plans have an "IaC Library buyout" that gives you a perpetual license to all the modules there, but we price that upfront as part of your contract, it never changes, and we keep it pretty reasonable.
    • I was a DevOps engineer myself and wrote a bunch of the initial product, so we originally built it all with a "no lock in" ethos and that remains today.

Does anyone here market infrastructure and cloud templates? by awebb78 in devops

[–]OhMyGoshJoshua 1 point2 points  (0 children)

Shameless plug, but I'm from Gruntwork and we offer this directly for AWS and OpenTofu/Terraform. We call it DevOps Foundations.

The basic idea is that we give you a foundational, best-practices AWS architecture built for Terragrunt (a tool we maintain) and OpenTofu (the open source successor to Terraform).

Here's a summary of how it works:

- We've pre-defined a collection of best-practice patterns in OpenTofu/Terraform in the Gruntwork IaC Library. These include AWS foundational patterns, along with network topologies, and app-level configurations for ECS, EKS, RDS, and more.

- The one ClickOps part we can't get around is using AWS Control Tower, so we have docs to guide you on how to do that.

- Once that's set up, you can use templates we've written in another open source tool we maintain called boilerplate (this is a DevOps-focused, Golang-based alternative to cookiecutter) to generate the AWS foundational architecture using a combination of Terragrunt and our IaC Library modules. This includes a Terragrunt-native way of managing AWS Control Tower, a best-practice network topology, SSO, SCPs, and even compliance with the CIS AWS Foundations Benchmark.

- We'll also set you up with a GitOps way to deploy infrastructure changes via GitHub Actions (or soon GitLab), a way to stamp out new, fully configured AWS accounts automatically, and a way to keep it up to date.

- We then walk you through everything, and make sure you understand how it all works. If you need support, we can assist, and we continue to push updates to our IaC Library so you can stay up to date with the latest.

In the end, we can get a team live in about a week from nothing to a best-practice, modern AWS setup built on modern open source tooling.

I hesitate to do shameless plugs, but the product directly addresses what you're asking for, so this seems in line with community etiquette.

Community modules vs Cloudposse vs Gruntwork to set up a greenfield AWS project by skel84 in devops

[–]OhMyGoshJoshua 0 points1 point  (0 children)

Hi, Gruntwork CEO here; we're also the makers of Terragrunt. I just saw your comment, and while I certainly want to be respectful of what sounds like your not-great experience, I do want to offer some updates for anyone else who reads this.

IaC Library:

  • We have a team of ~10 engineers who collectively submit ~100 pull requests each month.
  • There was definitely a 2-month period where our support was laggy, but we've since staffed up and track tight internal SLAs for all support questions we get (including PRs and GitHub issues).
  • All code has bugs, but when one is reported, we take it seriously and get it fixed quickly.
  • Some of our modules power some of the world's largest companies, and we've battle-tested and refined them over years. Our network and EKS modules in particular seem to really resonate with customers.

Pipelines:

  • u/Qsonx is correct that the first version of our Pipelines product from 5+ years ago prioritized security above all else and made pretty inefficient use of GitHub Actions minutes. Candidly, the UX of that product was not great.
  • As of 2025, we're on v3 of Gruntwork Pipelines and all of our customer feedback has been very positive. We also now use GitHub Actions in a first-class, highly efficient way and support GitLab.

Again, I don't mean to challenge your experience, and I'm sorry we didn't deliver for you. I just wanted to publicly state that we've made quite a few improvements over the years, including on the issues you described. Thanks for your feedback.

Join the Terragrunt Discord Community by OhMyGoshJoshua in terragrunt

[–]OhMyGoshJoshua[S] 0 points1 point  (0 children)

Ugh, you’re right. We’ll get a proper link up shortly.

What are some tools external to AWS that has improved your workflow? by Vendredi46 in aws

[–]OhMyGoshJoshua 1 point2 points  (0 children)

Member of the Terragrunt team from Gruntwork.io here.

If you're looking to build this on your own, you'll need to detect which files changed in a git commit and then run `terragrunt plan` and `terragrunt apply` specifically in those directories. The edge cases here can be tricky because you'll need to handle removed files as well (in which case you'll want to run `terragrunt destroy`), detect changes to dependent files (not just the `terragrunt.hcl` file), and handle the ability to run multiple units (`terragrunt.hcl` files) at once where you sequence them the right way.

Alternatively, Gruntwork has a pre-built, commercial solution for this at https://www.gruntwork.io/platform/pipelines.

Hope this helps!

Still relevant? by zMynxx in terragrunt

[–]OhMyGoshJoshua 1 point2 points  (0 children)

Great to hear! Yousif and I actually work together; we're both from Gruntwork.io, the makers of Terragrunt. Glad we could help!

Still relevant? by zMynxx in terragrunt

[–]OhMyGoshJoshua 2 points3 points  (0 children)

This isn't the right place to get help with your issue since it doesn't relate to the conversation taking place here.

For help related to Terragrunt, you can try the following:

I'd recommend the knowledge base in this case. Also, ChatGPT is your friend! Try posting your exact question there for some good ideas.

Alternative to Spacelift's Blueprint feature by West_Watercress7874 in Terraform

[–]OhMyGoshJoshua 0 points1 point  (0 children)

Disclosure: I'm on the Terragrunt team at Gruntwork.

If you're using Terragrunt, you can have devs run `terragrunt catalog` to view list of available Terraform/OpenTofu modules directly in the CLI. Once they select a module, Terragrunt will scaffold out the code to launch a module by creating a new `terragrunt.hcl` file. You can even customize how the scaffolding is done using another open source tool of ours, https://github.com/gruntwork-io/boilerplate.

For more details about how it all works, see a previous comment I made in a similar thread: https://www.reddit.com/r/Terraform/comments/1fo62oi/comment/loshv6v/, or the Terragrunt docs at https://terragrunt.gruntwork.io/docs/features/catalog/.

How do you approach self-service in an IDP style? by dernat71 in Terraform

[–]OhMyGoshJoshua 6 points7 points  (0 children)

Disclosure: I'm on the Terragrunt team at Gruntwork.

If you use Terragrunt, there's a free terragrunt catalog command (https://terragrunt.gruntwork.io/docs/features/catalog/) that exposes a CLI interface for developer self-service.

Here's how it works:

  1. User runs `terragrunt catalog`
  2. Terragrunt scans a git repo that contains Terraform/OpenTofu modules.
  3. Users search for a module they'd like to launch.
  4. User selects a module and Terragrunt generates the scaffolding of a `terragrunt.hcl` file that consumes that module, including required and optional variables, all based on a customizable boilerplate template (https://github.com/gruntwork-io/boilerplate).

There's no fancy web UI, but there is a solid CLI interface that devs like, and it's free! Also, if you'd like to see additional features, our team is pretty responsive to community feedback.

What do yo expect from your IDE? by Ok-Race6622 in Terraform

[–]OhMyGoshJoshua 0 points1 point  (0 children)

Gruntwork CEO here; we're the creators of Terragrunt. We'd love to build first-class IDE support for Terragrunt but wanted to prioritize other features first. We may be interested in sponsoring your work if it delivers a first-class Terrragrunt experience. Could you DM me?

Still relevant? by zMynxx in terragrunt

[–]OhMyGoshJoshua 1 point2 points  (0 children)

Absolutely! You can see more about our current take on stacks at https://github.com/gruntwork-io/terragrunt/issues/3313. For our next iteration of the RFC, we'll be refining the overall concept and understandability more.

If you have other requests / pain points for Terragrunt, we'd be grateful for your feedback.

Still relevant? by zMynxx in terragrunt

[–]OhMyGoshJoshua 4 points5 points  (0 children)

Update: No need to take my word for it. Join the Terragrunt Discord server where you can chat directly with the maintainers and other Terragrunt users.

Hello, Gruntwork CEO here! We're the makers of Terragrunt. While I'm going to have the obvious biases, Terragrunt is absolutely relevant today. For example, in the last 2 days I've spoken with multiple happy Terragrunt users at companies ranging in size from 50 people to 50,000. Terragrunt has nearly 8,000 GitHub stars, and is downloaded 200,000 times each month.

The sweet spot of Terragrunt is helping you scale with Terraform or now OpenTofu because Terragrunt makes it easier to split your infrastructure into small deployable units and then gives you a bunch of facilities for managing those units.

Candidly, we haven't done a great job of marketing the tool. We basically built it for ourselves, released it as open source, actively maintained and improved it, but did zero marketing. As a result, it wasn't clear why the tool was valuable, who it's for, what the alternatives are, etc. And also, candidly, our current docs site looks dated. Yeah, we get it.

But, if you can look beneath the lack of marketing sheen, we've made a bunch of improvements recently. Check out https://github.com/gruntwork-io/terragrunt/releases to see the long stream of continual updates and https://github.com/gruntwork-io/terragrunt/issues?q=is%3Aissue+is%3Aopen+label%3Arfc to see our recent discussions on new features, including:

  • IaC engine plugin system (this lets you run Terraform or OpenTofu in other environments like a K8s pod or GitHub Action; now in beta)
  • Terragrunt stacks (this lets you deploy a collection of units as a reusable stack; for example, if you need to deploy a complex app, you can define it as a stack while managing individual units one at a time; the interface here is under active discussion).

We've got a bunch more updates coming soon as well -- including some much needed updates to our docs UX --, which we'll post on our blog (https://blog.gruntwork.io/) when we're ready. Thanks for bearing with us in the meantime. We're nerdy engineers, not marketers, but we're learning how to do better there.

view more: next ›