Skip to main content
Discover Knodex, our open-source platformLearn more
Back to Blog
Infrastructure

Why We Built Knodex

Platform teams have a scaling problem. Terraform doesn't solve platforms. Infrastructure as CRDs is the future. Here's why we built Knodex.

Tristan ParisMarch 15, 2025

Platform teams have a scaling problem that nobody wants to name. As organizations grow, the team responsible for infrastructure becomes a bottleneck: fielding tickets, maintaining Terraform modules, chasing drift. Developers wait days for resources that should take minutes. Platform engineers spend more time on maintenance and ticket routing than on actual platform work.

This isn't a tooling failure. It's an architectural one. And we think the industry is about to correct it.

Terraform Solved Provisioning. It Didn't Solve Platforms.

Terraform brought infrastructure into version control. That mattered. But the model that emerged, hundreds of modules, each with its own lifecycle, its own versioning, its own pipeline, doesn't scale the way organizations need it to.

Module upgrades break downstream consumers. State files drift between applies. Compliance checks run manually, if they run at all. Every new resource type means another module, another pipeline, another set of docs. The maintenance cost compounds faster than the value delivered.

We've seen platform teams report 40% of their time going to module maintenance alone. The rest goes to routing tickets. That's not platform engineering. That's operations behind a newer label.

Infrastructure as Code Is Not the End State

The largest tech companies in the world have already moved past this model. Google, Microsoft, and Amazon are converging on the same architectural bet: Infrastructure as CRDs.

Custom Resource Definitions turn the Kubernetes API into a universal control plane. Not just for workloads, but for databases, DNS records, certificates, queues, cloud services. Projects like Kro (Kubernetes Resource Orchestrator, CNCF), Azure Service Operator, and AWS Controllers for Kubernetes all point in the same direction: infrastructure managed natively through Kubernetes, with reconciliation, drift correction, and GitOps built into the runtime.

No state files to manage. No separate toolchain to maintain. No bolt-on drift detection. The control loop handles convergence continuously.

This isn't a prediction. It's already happening in production at scale. The CNCF ecosystem is standardizing around it. The question for most organizations isn't whether to adopt this model, it's when.

The Developer Experience Gap

Infrastructure as CRDs solves the management layer. But it doesn't solve the developer experience.

Handing developers raw YAML and cluster access isn't autonomy. It's a liability. Without a catalog, forms, project isolation, and compliance guardrails, the power of Kubernetes-native infrastructure stays locked behind the platform team.

We looked for a developer-facing layer built for this new paradigm. The existing Internal Developer Platforms were either too opinionated, forcing a specific workflow, or too heavy, requiring months of setup, or completely disconnected from Kubernetes-native resources. Nothing fit.

That gap is why Knodex exists.

Knodex, the Catalog of Tomorrow

Knodex is an open-source infrastructure catalog built on Kro. Platform teams define resources using Kubernetes annotations. Knodex reads the schema and generates the UI. No frontend code, no separate configuration layer.

Developers browse a catalog, fill a form, deploy. Namespace isolation, RBAC, OPA Gatekeeper policies, and GitOps integration enforce governance without requiring platform team involvement on every request.

The platform team controls what's available and how it's governed. Developers get autonomy within defined boundaries.

We released Knodex under AGPL-3.0. If your infrastructure already runs on Kubernetes, the developer experience layer shouldn't be locked behind a vendor. It installs with a single Helm command in under five minutes.

Why This Matters Now

The shift from Infrastructure as Code to Infrastructure as CRDs is accelerating. The CNCF ecosystem is moving in this direction. Major cloud providers are investing in Kubernetes operators as the primary interface for their services. Organizations that build developer autonomy on top of this layer will eliminate the ticket bottleneck that has defined platform teams for the last decade.

Organizations that don't will keep scaling the same human API, just on newer infrastructure.

We built Knodex because we think that's a problem worth solving, and because the tools to solve it finally exist.


Tristan Paris is the founder of Provops, a Platform Engineering company helping teams replace Terraform sprawl with developer-facing infrastructure on Kubernetes.

knodexplatform-engineeringkubernetesterraformkro