A common question: how do Terragrunt Stacks compare with Terramate Stacks? The naming is misleading — a more accurate comparison is between Terramate Bundles and Terragrunt Stacks.

This article cuts through the terminology confusion by building from foundational concepts, then directly comparing Terramate Bundles with Terragrunt Stacks.

Terraform / OpenTofu (TF)

Let’s do a bit of basics, which might mainly feel like repetition, but it helps to build the hierarchy that we try to simplify with Terramate Bundles.

TF Resources and TF Data Sources

In Terraform, resources and data sources are the smallest units. They define how Terraform communicates with APIs, synchronizes data, and applies actions to

API-managed resources — primarily cloud APIs, though not exclusively.

Resources and data sources are implemented in Terraform Providers, which abstract away the complex CRUD operations on underlying APIs.

Terraform configuration is declarative (HCL). Every resource and data source exposed by a provider can be combined freely in your configuration.

A typical Terraform configuration spans multiple resources and data sources to define complete cloud services: VPCs, subnets, databases, Kubernetes clusters, workloads, and more.

These configurations live in a single directory but can be split across multiple files.

TF State and Versions

Every directory containing Terraform configurations needs three things: resource definitions, a backend configuration, and pinned TF and provider versions.

Terraform tracks infrastructure through state — a record of every resource it has deployed. Before making changes, Terraform refreshes this state against the live cloud API, then calculates what to create, update, or delete. State is stored in a remote backend (typically a cloud object storage bucket), which enables multiple engineers to work on the same infrastructure safely.

A single git repository can hold multiple such directories, each containing:

• TF configurations (resources, data sources, modules)
• Backend configuration
• TF and provider version pins

Different tools name these directories differently: Terramate calls them Stacks, Terraform and OpenTofu call them Root Modules, and Terragrunt calls them Units.

TF Modules

Modules group related resources for deployment. Like resources in standard Terraform configurations, modules can be called directly. A module consists of four parts:

• TF configuration - resources, data sources, and nested modules
• Input variables - the interface callers use to configure underlying resources
• Output variables - metadata passed from one resource or module to another as inputs
• Required providers - minimum and maximum provider version constraints

Modules promote reuse and keep configurations DRY. When a module also defines backend and provider configurations, Terraform calls it a Root Module — a naming convention that creates confusion.

Terramate resolved this by introducing a clearer term: any directory that defines a TF backend and owns a state file is called a stack. Stacks are also not limited to Terraform Root Modules — they support Kubernetes configurations and other tooling.

When we adopted the term "Terramate Stacks," no other tool in the space used it. That held true for some time, until Terragrunt Stacks and Terraform Stacks both appeared roughly a year ago.

Terramate Components

Terramate Components define templates for generating any type of code or file — YAML , JSON , Markdown , TXT , or HCL . We'll focus on HCL here.

Each Component has four parts:

• Metadata — name, description, version, and capabilities.
• Inputs — typed values set when instantiating the Component.
• Code generation templates — output code based on those inputs, using generate_hcl or .tmgen.
• Exports — transformed or additional configuration passed downstream.

In most cases today, the generated code is Terraform: referencing TF modules, or extending them with additional resources, data sources, or nested modules. This keeps TF modules generic while letting Components handle the specifics — so teams with existing modules can adopt Terramate without rewriting them.

Components can be instantiated into existing stacks, but they're designed to work alongside Terramate Bundles, not as standalone units.

Comparing Terramate Components with Terragrunt Units

With the addition of Terragrunt Stacks, Terragrunt Units are easily reusable. Those Terragrunt Units can be considered to share the same high-level intent as Terramate Components: Reuse TF Configuration. While they are not 1:1 comparable lets focus on some important parts in the following table.

Terramate Bundles

The purpose of Terramate Bundles is provide re-usable units that serve as a contract layer between infrastructure producers (experts) and infrastructure consumers (non-experts).

When enabling non-experts, it is important to hide as much complexity as possible. By pre-configuring the bulk of the configuration and exposing only a limited set of choices to the infrastructure consumers, producers can prevent any non-compliant, non-secure, and non-reliable configuration at all times.

When focusing on experts, it is important to remain un-opinionated and allow for flexibility without limiting them to specific patterns. There is no single silver bullet, and different teams have different requirements.

How can Terramate Bundles bring both worlds together: prevent specific actions but allow full flexibility?

Experts define, create, curate, and maintain repeatable, reusable patterns following best practices while ensuring compliance. Experts set and control the limits that they want to expose to non-expert users.

• TF modules can be fully flexible, exposing all possible options to their callers and taking care of grouping underlying TF configurations.
• Terramate Components can still be flexible and extend existing TF modules with additional safeguards. But they can also only expose a subset of configuration options and hard-code other settings. E.g., always enable encryption at rest and in transit when possible, and do not allow disabling it when using the component; e.g., always enable HA by default when deploying to production & always disable HA for cost control when in pre-prod environments.
• Terramate Bundles define the interface for non-experts in two levels: What values are required to get new infrastructure up and running? And what values shall be adjustable over time or when promoting infrastructure through the environment stages to production.

Terramate Bundles consist of the following parts:

• Bundle Metadata - defining details about the component, such as a name, description, class, version, and further capabilities.
• Bundle Inputs - A set of inputs of any possible type that can be set when instantiating the component.
• Bundle Exports - that allow the export of transformed and additional configuration details.
• Bundle Stacks - define what Terramate Stacks shall be created or extended and what components shall be called within those stacks.

So let's go a bit deeper and see what experts can control and what non-experts can forget about:

The Developer Friendly Experience DevX

When a non-expert user (or an expert ofc) wants to deploy a new type of infrastructure, they call terramate scaffold and can choose an environment to deploy to and a bundle to be deployed into that environment. In an upcoming version, this can even be done by natural language, e.g., “I would like to deploy my new service to staging and connect it to the main database”.

The following will then be triggered via the Terramate Terminal User Interface (TUI):

• an environment will or can be selected
• the user gets a pre-filled form to deploy a “service” bundle.
• a name for the service will be set or asked for,
• a database matching the criteria will be pre-selected or can be created too in the same step.
• other backing services could be attached or configured if needed.

Once this form is completed, one or more Bundle Instance YAML files are created in directories that are pre-defined by the expert users who created the Bundle. The non-expert can safely ignore such artifacts.

Deterministic code generation can automatically be triggered, which will take care of creating a bunch of stacks as defined by the Bundle Stacks definition (by expert users). Multiple directories will be created & initialized, and then code generation will fill each stack with life.

A commit can also be created if desired, followed by a draft PR that can optionally be synchronized to Terramate Cloud and reviewed in detail. Or the review can be skipped altogether, as all code is guaranteed to be curated in advance and generated from templates that have already been reviewed by the experts. If the preview was generated without failure, the pull request can automatically be marked ready for review and merged.

If you do not want to use the terminal user interface, all of this can be done with modern tooling, leveraging the AI agent of your choice and running the Terramate MCP server, leveraging the agent skills you use on a daily basis. The AI creates the configuration, and Terramate generates the code, ensuring full compliance by deterministically following what was defined before.

Expect all of this in by the end of Q1 2026 - we are very close to releasing this full experience, adding the missing AI parts. The manual process is available and ready to be used as of today.

Environment promotion

Terramate Bundles introduce native Environment support. Environments are, for example, pre-production and production, maybe with multiple stages going from development to staging to production. They do not match every company’s view of the world - if you have a different worldview on environment promotion, please reach out and let us know.

Each Bundle Instance YAML file can be extended to deploy the exact same configuration to any next environment. This can again be done in multiple ways, using the upcoming promote feature of the Terramate Terminal UI, using the AI tool of your choice, or manually editing the YAML file.

Yes, one YAML configuration controls multiple stacks, multiple Components in each stack, and multiple environments in which those Components can be deployed in.

Comparing Terramate Bundles with Terragrunt Stacks

They are not the same. Terragrunt Stacks are meant to be copied and not created from templates by filling in forms. But they do have similarities. Terragrunt Stacks also create new directories and initialize them with Terragrunt Units. The user needs to copy and paste the configuration when promoting it to new environments. This is mainly a feature from Platform Experts for Platform Experts to be used by Platform Experts.

But let's try to compare some highlights, which we believe are game changers, when using Terramate Bundles:

Bundle Roadmap: What’s next?

Below is a laundry list of capabilities. We are aiming to deliver this list by mid Q2 2026.

• ✅ Terramate Bundles, Components and Environments are fully available
• ✅ AI-based scaffolding or reconfiguration using your tools and the terramate agent skills
• ✅ terramate scaffold allows to scaffold new infra with bundles for non-experts
• ✅ manual reconfiguration of existing bundles (edit the YAML → generate → apply → done)
• ✅ manual environment promotion (edit the YAML → generate → apply → done)
• ✅ advanced types system for better documentation, improved auto-completion in IDEs
• 🚧 fully support all new types and auto-completion in the language server
• 🚧 improved AI workflows to generate Components and Bundles on scale
• 🚧 full AI support in the Terminal User Interface or on Terramate Cloud to prompt your infrastructure together
• 🚧 improved Terminal User Interface to scaffold new infrastructure, reconfigure existing and promote everything through environments
• 🚧 full support for Bundles, Components on Terramate Cloud
  • track versions instantiated and detect required updates for Bundles, Components, TF Modules, and TF Providers
  • track environment promotion of all parts of your infrastructure
  • Bundles, Components Registry to
• 🚧 more features for Bundle and Component authors to access internal data structures and simplify code generation
• 🚧 your custom feature that will make your life easier → talk to us, share your pain, be part of the journey to make your team even more successful ;)

Terramate Bundles and Terragrunt Stacks are not the same abstraction. Terragrunt improves how experts structure and reuse Terraform modules. Terramate Bundles introduce a contract layer on top — separating configuration from implementation, enabling environment promotion, and making self-service viable without giving up control.

If you want the broader picture beyond this specific comparison, read our article “Terramate vs Terragrunt: A 2026 Comparison”. It dives deeper into architectural trade-offs, performance, change detection, environment promotion, AI workflows, and long-term maintainability at scale.