With new product enhancements to the a9s Hub for use on AWS or on-premises, Klutch is evolving into a central control plane that lets enterprises deliver developer self-service without sacrificing governance.
Enterprise Kubernetes adoption has hit a familiar wall. As organizations scale their cluster footprints across dozens of tenants, teams, and accounts, a contradiction emerges: developers want on-demand access to services, but operations and security teams cannot afford to give up centralized governance. Most platforms force a choice between the two. anynines is building something that refuses to.
Klutch, the Kubernetes orchestration and governance platform from anynines, has been maturing quietly. According to Julian Fischer, CEO of anynines, significant work has been underway behind the scenes, including adding integrations, refining the architecture, and preparing the platform to meet the demands of large enterprise deployments. That work is now converging into a concrete product direction: enterprise-grade Hubs targeting the two biggest Kubernetes deployment scenarios.
“We are about to take Klutch and add what is necessary to become enterprise grade,” Fischer said in an interview at KubeCon + CloudNativeCon Amsterdam 2026. “Which means building the a9s Hub in the two major use cases, the a9s Hub for AWS and the a9s Hub for on-premises.”
The EKS Problem No One Has Solved Cleanly
For organizations running Kubernetes at scale on AWS, the AWS Well-Architected Framework provides a reference architecture for structuring accounts. The framework prescribes account isolation at the tenant level; each tenant gets its own dedicated EKS account for application clusters and a separate account for services. That means in a large multi-tenant deployment, you are managing two AWS accounts per tenant, multiplied across potentially dozens or hundreds of tenants.
This account structure is good for security and compliance. It creates clean blast radius boundaries. But it creates a provisioning nightmare.
When a developer needs a database, a message queue, or a cache, the platform must automatically route that request to the correct tenant account. Without a purpose-built control plane, that process involves manual coordination between platform and operations teams, custom scripting, or both. Neither scales.
“If you run a lot of Kubernetes clusters on AWS and you are an EKS user using the Well-Architected Framework, how do you enable your users to get on-demand self-service while providing that central governance using Klutch as a central control plane for orchestration and governance?” – Fischer asked. That is precisely the problem the a9s Hub for AWS is designed to solve.
How the a9s Hub for AWS Works
The a9s Hub for AWS is built natively around the account model prescribed by the Well-Architected Framework. When a new application cluster is provisioned on EKS, the Klutch client is installed on that cluster during provisioning. Once the client is present, it carries the context of which tenant it belongs to.
“When application clusters are provisioned, and the Klutch client is installed, it should be able to provision data services in the corresponding account that corresponds to the tenant,” Fischer explained.
That automatic account-to-tenant mapping is the key architectural insight. The developer or application does not need to know which AWS account their data services live in. The Klutch client handles that routing transparently. The result is genuine self-service for developers and genuine governance for operators, simultaneously, not as a trade-off.
On-Premises Is the Second Major Use Case
Not every enterprise runs on AWS. For organizations operating Kubernetes on their own infrastructure, anynines is building the a9s Hub for on-premises deployments. Fischer confirmed that on-premises represents the second pillar of the enterprise-grade Klutch strategy, alongside the AWS Hub. While the architectural specifics of the on-premises Hub differ from those of the AWS implementation, the governing principle remains the same: a central control plane that enforces governance while enabling self-service provisioning at scale.
What Enterprise Grade Actually Means
Fischer was precise about what “enterprise grade” requires for Klutch. It is not a rebrand. It is a set of specific integrations, account-aware provisioning logic, and Hub configurations built to handle the scale, complexity, and governance requirements that large organizations actually operate under. The platform has been maturing toward this moment, and the a9s Hubs represent the culmination of that work.
For platform engineering teams running large EKS deployments or enterprise on-premises Kubernetes infrastructure, Klutch’s trajectory is worth tracking. The combination of developer self-service and centralized governance, without manual operations bridging the gap, is exactly what enterprise Kubernetes has been missing.
