Konstruct product updates: A look back at releases 0.1 - 0.3

Over the past few months, we’ve shipped a significant amount of functionality in Konstruct. To make sense of it all, I’m kicking off a new monthly series where we’ll share what’s new, why we built it, and where it’s going next.

Because this is the first blog, I’m going to do something slightly different: instead of focusing on a single release, I want to take a step back and walk through everything we’ve launched so far, Konstruct 0.1 through 0.3, and, more importantly, explain the thinking behind it.

What is Konstruct?

Konstruct is a platform engineering product designed to help organizations manage cloud-native infrastructure and applications at scale. At its core, it’s about making Kubernetes, GitOps, and infrastructure as code operable for real companies, not just technically possible, but repeatable, governable, and adaptable to how different teams actually work.

From day one, Konstruct has been built around a simple hierarchy:

Platform → Organizations → Teams → Clusters → Applications

Each layer exists to provide isolation where you need it, standardization where it helps, and flexibility where it matters.

👉 Explore the Konstruct documentation

Konstruct 0.1: Foundations and core platform primitives

The 0.1 release was intentionally foundational. We focused on making sure that we could provision and manage Kubernetes clusters properly, on a brand-new platform architecture.

You can learn more about our 0.1 release by clicking here.

First-class platform concepts

In 0.1, we introduced the core domain objects that everything else builds on:

• Multi-organization and team management, allowing a single Konstruct installation to support multiple business units or customers with strong isolation.
• Self service isolation, where each team gets its own dedicated management cluster and control plane and administrative overrides.
• Cloud account integration, starting with AWS, including secure credential handling and multi-account support.
• Git account and GitOps repository management, baked directly into the platform rather than bolted on later.

These weren’t treated as configuration details; they were first-class citizens of the platform. You don’t just “point” Konstruct at a cloud account or a Git repository; you manage them as part of the system.

Cluster provisioning, reimagined

Konstruct 0.1 introduced support for:

• Management clusters
• Workload clusters
• Virtual clusters
• Standardized cluster templates

Under the hood, we made a deliberate architectural shift: instead of driving infrastructure through a CLI, Konstruct uses Crossplane as its orchestration layer. That move pushed us fully into a GitOps-forward model for infrastructure as code and gave us a much stronger foundation for scale.

By the end of 0.1, organizations could create teams, connect cloud accounts, provision clusters, and deploy applications, all within a single, coherent system.

Konstruct 0.2: Templates, customization, and opinion ownership

If 0.1 proved that the platform worked, 0.2 focused on a more subtle problem: how much opinion is too much opinion?

Every platform has opinions. The real question is whether users can change them.

While templates were a core part of the Konstruct 0.2 release, there is more you can explore by checking out the official release notes here.

Cluster templates

In 0.2, we introduced custom workload and management cluster templates. When you create a cluster in Konstruct, you’re not just getting infrastructure; you’re getting a set of platform tools, installed in a specific order, with a specific set of assumptions behind them.

Those assumptions come from years of operating Kubernetes in real environments. They’re solid defaults. But they’re still defaults. With cluster templates, teams can:

• Start from Konstruct’s upstream templates
• Fork and version their own infrastructure patterns
• Swap tools in or out
• Apply different templates per team or use case

The result is a platform that accelerates teams on day one but doesn’t lock them into decisions they didn’t make.

Pipeline templates

The same philosophy shows up again with pipeline templates. When an application is registered in Konstruct, the platform automatically:

• Builds a container
• Publishes it to the organization’s registry
• Generates and versions a Helm chart
• Deploys progressively across environments

All of this works out of the box via GitHub Actions, with no manual setup.

But real companies always need more: tests, checks, migrations, performance gates. Konstruct’s solution isn’t to predict every workflow; it’s to let you own them. Teams can fork Konstruct’s upstream pipeline templates, add their own logic, and make those pipelines the default for every new application on the platform. You get consistency without sacrificing control.

Konstruct 0.3: Simplification and GitOps expansion

Version 0.3 was about two things: radical simplification and expanding what GitOps can represent. Read our full 0.3 release notes by clicking here.

The GitOps Catalog

The biggest conceptual leap in 0.3 is the GitOps Catalog.

Most organizations have a long tail of “platform-adjacent” software: observability agents, security tooling, networking components, and internal services. These aren’t always part of a base cluster template, but they still need to be distributed safely and consistently.

The GitOps Catalog allows platform teams to define reusable, self-hosted catalog entries that can be installed on demand across teams and clusters. These entries aren’t limited to Kubernetes manifests; they can include infrastructure dependencies like buckets, DNS, or databases.

This is the advantage Konstruct has over other template-based portal tools like Backstage. Because of its architectural posture and understanding of your organization, GitOps, IaC, clusters, environments, and applications, it’s able to produce a much more intuitive user experience for components that blur the lines of application and infrastructure.

In 0.3, the catalog is global to the platform. In future releases, that capability expands to allow organizations to self-host their own catalog as well, enabling even finer-grained control without central bottlenecks.

Native GitHub application integration

The 0.3.6 patch release introduced native GitHub App integrations across the Konstruct platform. Read the full release notes for this here.

Git access underpins nearly every platform workflow, from GitOps repositories and pipelines to infrastructure as code. Traditionally, this has relied on long-lived tokens or manually managed credentials, which introduces operational overhead and security risk. With 0.3.6, Konstruct now uses GitHub Apps to generate short-lived credentials on demand, removing the need to manage or rotate static tokens.

To support this model throughout the stack, we forked the Crossplane Terraform provider used by Konstruct to add native GitHub App authentication for infrastructure workflows. This ensures the same authentication approach is used consistently across the control plane, GitOps operations, repository workflows, and automated IaC tasks.

Each GitHub organization connected to Konstruct receives its own isolated GitHub App instance and API rate limit boundary. We also added Prometheus metrics so platform teams can observe GitHub API usage and rate limits across their organizations.

Looking ahead

Konstruct didn’t appear overnight; we’ve been quietly productionalizing the product with our largest clients, preparing it for delivery to organizations with tens of thousands of engineers.. We’re excited to share more with you over the coming months, so keep an eye out for more updates.

If you are interested in a demo of the Konstruct platform or talking to someone about our enterprise scalability, schedule time with me here. Or learn more about Konstruct's history by reading my latest blog here.