Every few months, we send out a newsletter to all Gruntwork customers that describes all the updates we’ve made since the last newsletter and news from the DevOps industry. Note that some of the links below may go to private repositories in the Gruntwork Infrastructure as Code Library that are only accessible to customers.

Welcome to the March 2025 Gruntwork Newsletter! For many of our customers their Sunday, March 9th was shorter by an hour — but don’t worry, we’re here to bring you plenty of DevOps updates that will help you save that hour and more on your next infrastructure project!

As always, if you have any questions or need help, email us at support@gruntwork.io!

Gruntwork Updates

Library Modules moving to v1.0

The Gruntwork Library is made up of over 30 source code repositories that, for many years now, have all been on ZeroVer (i.e. pre-1.0 versions that don’t yet follow Semantic Versioning). Since each repository is made up of multiple modules that are updated independently, the concept of a “breakage” for a major version bump has been murky. Namely, just because one out of many modules has a breaking change, it seemed burdensome and heavy-handed to then have to bump the major version on all the other non-broken modules.

The library is now fairly mature and breakages are both identifiable and a lot less common than they used to be. The underlying Terraform/OpenTofu language is stable and our modules have had years of iteration and testing. Given that, it now makes sense to adopt full Semantic Versioning, where major versions signal breaking changes.

Major version bumps will now clearly indicate breaking changes, so customers can plan upgrades more confidently. Modules that wrap AWS services or external tools will be more closley aligned with upstream versioning (e.g., EKS, RDS, OpenSearch, Kafka), helping you correlate changes in your cloud infrastructure with module updates.

As of the publication of this newsletter most modules are still on 0.x, however in the coming weeks and months you’ll start to notice Gruntwork incrementing the major version number.

Pipelines Govcloud Support

Gruntwork Pipelines now supports deploying resources to AWS GovCloud. For customers targeting FedRAMP or similar programs, it’s now easy to setup the necessary configurations with Gruntwork Pipelines to get a compliant automation pipeline for deploying Infrastructure as Code.

Added support of logging V2 for Cloudfront.

This month, we enhanced our CloudFront module by implementing standard logging V2. This upgrade allows direct delivery of CloudFront access logs to Amazon CloudWatch Logs and Amazon Data Firehose. You can now leverage additional output formats including JSON and Apache Parquet for S3 delivery. The module now also allows automatic partitioning of logs delivered to S3, along with custom selection and ordering of log fields. These improvements give greater flexibility in how you collect, store, and analyze CloudFront usage data.

The future of Gruntwork’s VPC Modules

Gruntwork’s VPC module was one of the very first library modules we created in 2016. Since then it has grown tremendously and covers a wide range of capabilities. In that same time, Terraform (and now OpenTofu) have evolved, as have best practices. To make the VPC module as easy to use as possible, we’ve begun a progress of redesigning the VPC modules to modernize, address limitations and streamline modern best practices network implementation. Stay tuned for more updates on how to adopt the updated implementation.

AL Linux 2023 Support

We have expanded our terraform-aws-security module to offer full support for Amazon Linux 2023, ensuring enhanced protection and compatibility for systems running on the latest version of Amazon’s Linux distribution. This update strengthens security features while maintaining seamless integration with Amazon Linux 2023 environments. The update to AL2023 with Gruntwork modules is seamless, there are no known breaking issues.

Terragrunt Updates

Terragrunt Stacks Experiment Continues

The Terragrunt Stacks experiment is almost complete with all major functionality delivered.

The terragrunt.stack.hcl file now supports the stack configuration block, supporting recursive generation of nested stacks. This allows users to abstract away collections of units into reproducible stack templates that can be deployed as children of other stacks.

Unknown block type "inlineImage", specify a component for it in the `components.types` option

Stay tuned for future announcements when we’ll be announcing the final push for validation and testing with the Terragrunt community to find any final edge cases before stabilizing Terragrunt Stacks for 1.0.

Get involved in the Terragrunt Discord to stay in the loop as we drive the Terragrunt Stacks experiment towards stabilization.

CLI Redesign: Introduction of — all and — graph

Progress continues on the CLI Redesign experiment, with major milestones achieved.

The Terragrunt CLI now supports two flags for the run command that replaces the usage of the run-all and graph commands:

$ terragrunt run-all plan# Is now:$ terragrunt run --all plan$ terragrunt graph plan# Is now:$ terragrunt run --graph plan

This continues the standardization of moving commands used to orchestrate OpenTofu/Terraform under the run command, and presents a unified interface for performing runs against multiple units, regardless of discovery strategy.

The --all flag discovers all units recursively in child directories of the current working directory, whereas the --graph flag discovers units by traversing up to the root of the Terragrunt project, then discovering all units that are part of the dependency graph of the unit in the current working directory.

Deprecation of legacy commands like run-all and graph are expected to start gradually in April, and you can subscribe to the removal schedule to learn of any timelines for removal of feature support.

CLI Redesign: Introduction of the find command

To help users better understand their IaC, we’ve introduced the new find command.

Unknown block type "inlineImage", specify a component for it in the `components.types` option

The find command is a standalone utility for discovering Terragrunt configurations in a Terragrunt project, with tooling to display output in JSON format, and sort results according to the Directed Acyclic Graph (DAG).

Introduction of the Content Addressable Store (CAS)

Terragrunt now has support for an experimental feature we’re calling the Content Addressable Store (CAS). When using the CAS, Git-cloned content is de-duplicated, reducing disk utilization and network traffic, improving the efficiency of git-based repository cloning.

As of the release of this newsletter, the only supported usage of the CAS is de-duplication of Git clones for the catalog command. More integrated support is planned in the future for the CAS feature, and users can expect it to improve performance of multiple sources of Git cloning in the future.

Errors block supports module sources

In collaboration with Terragrunt Enterprise customers, we’ve introduced an integration between the errors block and the terraform block to support handling of errors that occur during module fetches.

The errors block now supports the ability to retry or ignore errors during module fetching, which is especially important for users with internal module registries like Artifactory, as intermittent network errors can usually be mitigated with a retry.

See “Errors during source fetching” for more information.

DevOps News

In late February IBM announced that they have closed on the acquisition of HashiCorp. Since the original announcement in April of 2024 it has been uncertain what this means for the future of the original Terraform project, and as of writing of this blog post, no public information has been released. Terraform 1.6+ remains under the Business Source License (BSL). Gruntwork continues to advocate that OpenTofu is the best choice for IaC orchestrate both from a commercial licensing perspective and on the merits of its technical capabilities.