An introduction to the GitOps Catalog

One of the challenges teams face as their platforms grow is how to standardize what gets deployed without slowing teams down. The GitOps Catalog from Konstruct is designed to solve this by providing a consistent way to distribute reusable infrastructure modules, application components, and full environment stacks across clusters.

At a glance, it looks like a templating system. In practice, it is a structured approach to packaging and reusing platform capabilities through GitOps, while still allowing teams to configure deployments to their specific needs.

Both platform and application teams benefit from the same underlying model: reusable definitions stored in Git, deployed consistently, and parameterized where flexibility is required.

What is the GitOps Catalog?

The GitOps Catalog provides reusable templates stored in the catalog/ directory of your organization’s GitOps repository. These templates define how infrastructure resources and applications should be deployed.

Instead of recreating configurations for each environment or cluster, teams can deploy catalog items with custom parameter values. This ensures consistency across environments while still allowing for environment-specific variation.

Each deployment of a catalog item is an instance of that template, generated into a defined path in the GitOps repository, where it is then reconciled in the usual GitOps workflow.

There are a few core ideas that underpin how the catalog works:

The catalog itself is not a separate system. It operates entirely within your existing GitOps model, using the same repositories, workflows, and reconciliation mechanisms.

Catalog item types

Konstruct supports three catalog item types, each designed for a different class of problem.

Application catalog items

Application catalog items are used to deploy Kubernetes applications and platform tooling using Helm and Argo CD.

These are typically used for things like monitoring agents, security tools, developer tooling, and application services that already exist as Helm charts.

The deployment flow is straightforward. Parameters are defined in values.yaml, users provide values at deployment time, Helm renders the templates, and Argo CD applications are generated and committed to the application GitOps repository. From there, Argo CD syncs them to the target clusters.

These items deploy into environment and cluster-specific paths under registry/environments/, ensuring clear separation between environments.

IaC catalog items

IaC catalog items are used to provision cloud infrastructure using Terraform via Crossplane’s Terraform provider.

These templates live in a separate repository and define infrastructure such as storage, databases, networking, IAM roles, and other cloud resources.

When deployed, the control plane operator clones the template, commits it into the platform GitOps repository, and generates the required Crossplane resources. Terraform execution is then handled by Crossplane, which runs plan and apply operations.

A key detail in this model is how values are handled. Tokens without a TF_ prefix are used for provider configuration through string replacement, while tokens with a TF_ prefix are converted into Terraform variables using snake_case naming.

IaC catalog items deploy into the platform GitOps repository, under paths that include both the Terraform module and the generated Crossplane resources.

Hybrid catalog items

Hybrid catalog items combine both approaches, allowing you to provision infrastructure and deploy applications together as a single unit.

This is useful for scenarios where applications depend directly on infrastructure, such as a database with a management UI, or a full application stack with dedicated resources.

Hybrid deployments run in two phases. Infrastructure is provisioned first through Crossplane and Terraform. Once the infrastructure reaches an available state, application resources are deployed via Argo CD.

The connection between the two is handled through Terraform outputs, which can be passed into application configurations, often via mechanisms like External Secrets.

Hybrid items deploy to both the platform and application GitOps repositories, reflecting their dual nature.

How the GitOps Catalog works

Although the catalog supports different types of deployments, the underlying workflow remains consistent.

• Templates define the structure and parameters.
  Users provide values at deployment time.
• The system generates the required resources into the GitOps repository.
• Argo CD and Crossplane reconcile those resources to reach the desired state.

For application deployments, this results in Argo CD Applications being created and synced to clusters.

For infrastructure, Crossplane creates ProviderConfig and Workspace resources, which execute Terraform.

For hybrid deployments, both flows are coordinated, with infrastructure provisioned before applications are deployed.

This approach ensures that all deployments, regardless of type, follow the same GitOps-driven lifecycle.

Common use cases

The catalog is designed to address repeatable deployment patterns across teams and environments. You can standardize monitoring by defining a catalog item for deploying agents consistently across clusters, with environment-specific configuration.

You can provision cloud resources such as storage or databases with predefined security settings, versioning, and encryption, ensuring consistency without manual configuration. You can also deploy complete environments by combining infrastructure and applications into a single catalog item, allowing teams to spin up full stacks with the correct dependencies already in place.

Getting started

To start using the GitOps Catalog, you need access to your organization’s GitOps repository with write permissions and a basic understanding of GitOps workflows, YAML, and Kubernetes.

From there, the process is incremental:

• Review the prerequisites and repository structure.
• Choose the appropriate catalog item type based on what you need to deploy.
• Create your first catalog item by defining templates and parameters.
• Commit it to the repository and verify it in the Konstruct UI.
• Deploy it to your environments and clusters.

Each catalog item type builds on familiar tooling, whether that is Helm and Argo CD for applications, or Terraform and Crossplane for infrastructure.

Summary

The GitOps Catalog provides a structured way to package and distribute reusable platform capabilities across your organization.

• Application catalog items standardize Kubernetes deployments.
• IaC catalog items standardize infrastructure provisioning.
• Hybrid catalog items bring both together into a single, coordinated workflow.

All three models operate within the same GitOps foundation, using Git as the source of truth and automated reconciliation to enforce consistency. The result is not just reusable templates, but a repeatable system for delivering infrastructure and applications in a way that scales with your platform.

If you are interested in a demo of the Konstruct platform or talking to someone about our GitOps Catalog, schedule time with me here.