How Terramate Catalyst Reimagines IaC Self-Service

In our previous post, we explored why current approaches that promise to provide developers with infrastructure self-service via IaC often don’t work. In this article, we will explore how Terramate Catalyst offers a new approach that fundamentally rethinks the balance between platform engineers and developers to standardize and simplify IaC self-service radically.

The Importance Of Developer Self-Service

The average engineering organization has a Platform Engineer-to-Developer ratio of 1:10 to 1:20. Before the rise of DevOps and the emergence of platform engineering, developers didn’t have to manage cloud infrastructure, as a centralized operations team handled it. But given the ratio mentioned above, ticket-Ops will never scale, as it leads to ticket fatigue, long wait times, and frustration among the teams.

So instead of fully managing cloud infrastructure for developers, platform engineering now has the responsibility to provide tools and workflows that enable developers to deploy and manage their services in a self-service manner. This also includes the ability for them to provision, deploy and manage complex cloud infrastructure services such as databases, queues and caches - basically whatever infrastructure is required to run their services.

The de facto standard technology for building workflows that enable developer self-service is IaC, as it allows platform teams to codify complex infrastructure patterns while preserving full control.

Scaling Developer Self-Service With IaC

But if you're trying to scale IaC and enable developer self-service without chaos, the right abstractions are key. IaC promised automation, consistency, and self-service infrastructure. But in most organizations, it’s just another source of friction. Developers are expected to wrangle raw cloud APIs, platform teams spend their time reviewing infrastructure PRs, and every deployment turns into a game of 20 questions about networking, security, and resource sizing.

The problem isn’t IaC itself — it’s how we use it. Most teams rely on overly generic modules that expose too many low-level details, forcing developers to make decisions they shouldn’t have to. Meanwhile, platform teams either act as gatekeepers or find themselves stuck maintaining fragile, one-off configurations.

The most commonly used way of providing self-service with IaC is the “Service Catalog”, which is basically a catalog of vetted modules, maintained by your expert users (the platform team) that is supposed to enable developers to deploy and manage complex infrastructure in self-service using golden paths that match your organizational needs. But using such catalogs requires developers to have in-depth knowledge of the underlying tool, such as Terraform, which can cause cognitive load and frustration.

To mention a few of the challenges that come with the Terraform Service Catalog approach:

Developers have to learn HashiCorp Configuration Language (HCL), the configuration language used to write Terraform and OpenTofu
Developers have to know how to manage state
Developers are often facing an overwhelming amount of configuration options for the provided modules
Developers have to take care of maintenance tasks such as provider, module, and Terraform updates

A New Approach: Meeting Both Personas Where They Are

If you look closely at why most infrastructure self-service initiatives fail, it becomes clear that the root cause is not Terraform, Kubernetes, or any individual technology. It’s the fact that the tooling is designed around the needs of only one persona at a time.

In the past, approaches have either optimized for developers and frustrated platform teams (Infra from Code) or have optimized for platform teams at the expense of developers (self-service by module catalogue). Neither is sustainable.

To build real self-service at scale, you need a system that is explicitly multi-persona by design—one that gives developers a frictionless experience while preserving (and even strengthening) the control and investment of platform teams. This is where Terramate Catalyst introduces a fundamentally different approach.

Terramate Catalyst: Infrastructure Self-Service Without The Trade-Offs

Terramate Catalyst is built on a simple premise:

Developers should not need to understand Terraform or the details of cloud providers to consume infrastructure safely and reliably.

Platform teams should not need to reinvent their entire IaC stack to provide self-service.

Catalyst doesn’t replace IaC — it operationalizes it.

Instead of asking developers to write or modify Terraform modules, Catalyst introduces two new primitives: Terramate Bundles and Components. These are highly opinionated, use-case-specific building blocks that encode your organizational standards, best practices, and governance rules.

Terramate Components define reusable infrastructure patterns—databases, message queues, buckets, caches, VPC services—expressed in Terraform (or OpenTofu). Components are a unit of reuse for platform engineers. They maintain these like they would any IaC asset and can even import their existing module catalog to Terramate Components.
Terramate Bundles assemble components into deployable, ready-to-use units that developers can provision autonomously — without editing Terraform, touching cloud APIs, or understanding low-level abstractions. They are the unit of re-use for developers. Bundles separate configuration from code and provide a really simple interface to developers.

The result is a clean separation of concerns:

For Developers

A simple, predictable self-service workflow. No HCL. No state bootstrapping. No dealing with providers. No 20-question architecture reviews. Developers focus on what they need—“a database,” “a queue,” “a bucket”—while platform teams ensure it’s created the right way.

For Platform Engineers

Full control over IaC implementation, resource mappings, state separation, security policies, naming conventions, cost-optimization, and compliance. You keep your Terraform investment, your module catalog, your automation, and your expertise — just exposed through a safer, cleaner interface.

Catalyst doesn’t ask you to abandon your stack. Instead, it amplifies it. And makes day 2 operations a breeze.

Why This Works: IaC’s Real Superpower Is Variant Generation

We strongly believe that IaC’s true power is not in provisioning but in codifying variants: pre-approved, opinionated, safe patterns that can be reproduced at scale.

Catalyst takes this idea and operationalizes it across personas.

Platform teams define the variants.

Developers consume the variants.

Catalyst ensures everything stays secure, consistent, and maintainable.

Instead of developers creating accidental snowflakes or platform engineers drowning in support requests, everyone finally operates within a shared standardized mental model that scales.

The Payoff: A Path Toward Sustainable Infrastructure Self-Service

Time and again, we hear from engineering organizations that tried multiple self-service strategies— module catalogs, IDPs, no-code builders, infra-from-code solutions — and ran into the same systemic challenges:

Too much Terraform complexity for developers, while too little flexibility for platform teams
Too much cleanup and governance work for platform teams
Too much drift, divergence, and fragmentation
Too little reuse of existing IaC investments
Too little operational consistency across teams

Terramate Catalyst directly addresses these challenges by aligning infrastructure workflows with how teams actually operate.

Developers get autonomy without needing expertise
Platform teams get governance without becoming gatekeepers
Organizations get consistency, velocity, and leverage from their IaC investment

Infrastructure self-service doesn’t have to be a zero-sum game. When abstractions are purpose-built, use-case-specific, and designed for multiple personas — not just one — you unlock a model that finally scales.

Getting Started with Terramate Catalyst

Catalyst is now available in public beta. The following resources can help you get started with Catalyst.

Terramate Catalyst Binary (drop-in replacement for Terramate CLI): https://github.com/terramate-io/terramate-catalyst/releases
WIP Docs: https://github.com/terramate-io/terramate-catalyst/blob/main/CATALYST.md
GitHub As Code Reference Architecture: https://github.com/terramate-io/terramate-github-as-code

In our next article, we will take an in-depth look at how Terramate Catalyst works and how you can get started by importing any existing Terraform module to Terramate Catalyst.