Klutch

A young open-source control plane, built on Crossplane, that lets many application clusters order databases from one central Kubernetes cluster.

What it is: Container orchestration,Relational databases
Part of: Built on Kubernetes
Type: Open source
Made by: Klutch authors (sponsored by anynines)
License: Apache 2.0
Facts checked: 6 October 2026

What it is

Klutch splits the work between two kinds of Kubernetes cluster. Application clusters run the apps and no databases. One control plane cluster runs Crossplane, the providers that talk to the real backends, and Klutch’s own binding service. A developer in an app cluster runs the klutch-bind CLI once: it signs in through OpenID Connect (Dex or Keycloak, for example) and installs a small agent called the konnector. The konnector creates the chosen custom resource definitions in the app cluster, such as PostgresqlInstance, ServiceBinding, Backup and Restore, and keeps copying objects and their status between the two clusters. Apply a PostgresqlInstance with kubectl and the control plane provisions the database wherever its backend lives; apply a ServiceBinding and the credentials appear as a Secret in the app cluster. The cross-cluster binding comes from kube-bind (now kbind), and every service is a Crossplane composite resource, so platform teams can add their own.

The interface borrows its service instance and service binding ideas from the Open Service Broker API, and adds backup and restore as resources of their own. Out of the box, the APIs target anynines’ own products: a9s Data Services (VM-based PostgreSQL, MariaDB, MongoDB, search, messaging and others, reached through a service broker) and a8s PostgreSQL, which runs on Kubernetes. Klutch is Apache 2.0, maintained by a small group of contributors and sponsored by anynines, a German cloud automation company that sells support and data services around it. It is young: version 1.0 came out in August 2024, the repository had 19 contributors by October 2026, and it isn’t part of any foundation.

Why teams pick it

Operators and databases stay in one place: app clusters get only CRDs and a lightweight konnector, so there is no operator sprawl to patch on every cluster
Developers keep a Kubernetes-native workflow (kubectl apply, GitOps) while the platform team controls plans, backends and policy centrally
Backup and restore are first-class resources, not left to each backend
Built on Crossplane, so any backend with a Crossplane provider or composition can be exposed; a control plane mode can also run the konnector centrally to keep app clusters even lighter

Watch out for

Young and mostly maintained by one sponsor: a small contributor base and breaking changes between minor versions (1.3, 1.4 and 1.5 all had some)
The ready-made APIs mostly target anynines’ own a8s and a9s services; for anything else you write the Crossplane compositions yourself
It orchestrates databases rather than running them: failover and backups come from whatever backend sits underneath
More moving parts than a single operator: Crossplane and its providers, an OIDC provider, the binding backend and a konnector per app cluster

More of the Kubernetes family

What all container orchestration have in common →

AgonesOpen sourceBuilt on itRuns dedicated multiplayer game servers on Kubernetes: keeps a fleet of them warm, hands one to each match, and never kills a server while players are on it.

Amazon EKSAWSManaged servicesAWS runs the Kubernetes control plane for you; you choose how much of the worker side to hand over too.

Azure Kubernetes ServiceAzureManaged servicesMicrosoft’s managed Kubernetes: a control plane that can be free, node pools of Azure VMs, and an Automatic mode that runs the nodes too.

Google Kubernetes EngineGoogle CloudManaged servicesGoogle’s managed Kubernetes, the oldest one: Google runs the control plane, and in Autopilot mode the nodes too.

K3sOpen sourceDistributionsA certified Kubernetes distribution in one small binary, built for edge, IoT and other places where a full cluster is too heavy, with SQLite or embedded etcd for state.

MicroK8sOpen sourceDistributionsCanonical’s Kubernetes in one snap package: installs with one command on Linux, forms a highly available cluster by itself at three nodes, and adds features as addons.

Red Hat OpenShiftCommercialDistributionsRed Hat’s Kubernetes platform: Kubernetes plus its own OS, operators that install and upgrade everything, and stricter security defaults, sold by subscription.

RKE2Open sourceDistributionsSUSE’s security-focused Kubernetes distribution: one binary per node, hardened defaults, FIPS-validated crypto and close alignment with upstream.

Talos LinuxOpen sourceDistributionsA Linux distribution that only runs Kubernetes: immutable, minimal, with no shell or SSH, and managed entirely through an API.

kindOpen sourceFor local developmentKubernetes IN Docker: each cluster node is a container, so a conformant multi-node cluster starts and disappears inside a CI job.

minikubeOpen sourceFor local developmentA local Kubernetes cluster for developers on Linux, macOS or Windows, in a container, a VM or on the host itself, with laptop-friendly extras.

kubeadmOpen sourceToolsThe official tool for turning Linux machines you already have into a Kubernetes cluster: `kubeadm init`, then `kubeadm join`.

RancherOpen sourceToolsSUSE’s open-source control plane for fleets of Kubernetes clusters: one place to create, import, secure and upgrade them.

How it fits with other technologies

What Klutch uses

In an app cluster: order a PostgreSQL instance, get its credentials, and take a backup · yaml

# once per app cluster: bind to the control plane with the klutch-bind CLI (OIDC login, installs the konnector)
apiVersion: anynines.com/v1
kind: PostgresqlInstance
metadata:
  name: orders-db
  namespace: default
spec:
  service: "a9s-postgresql14"
  plan: "postgresql-single-small"
  expose: "Internal"           # default is LoadBalancer
  compositionRef:
    name: a8s-postgresql
---
apiVersion: anynines.com/v1
kind: ServiceBinding           # credentials arrive as a Secret
metadata:
  name: orders-db
  namespace: default
spec:
  instanceRef: orders-db
  serviceInstanceType: postgresql
  compositionRef:
    name: a8s-servicebinding
---
apiVersion: anynines.com/v1
kind: Backup
metadata:
  name: orders-db-before-migration
  namespace: default
spec:
  instanceRef: orders-db
  serviceInstanceType: postgresql

See it in a real stack

No architecture uses Klutch yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2024–2026

anynines builds automation for data services, including its VM-based a9s Data Services, which applications request from a service broker through the Open Service Broker API. Klutch is aimed at organisations with hundreds or thousands of Kubernetes clusters. For them the usual answer, an operator per database installed on every cluster where it’s needed, leads to sprawl: more software to monitor, patch and keep within budget.

anynines’ answer was to keep the data services in one place and project only their APIs into each app cluster. It combined two existing projects: Crossplane, which turns cloud and infrastructure automation into Kubernetes resources, and kube-bind, which shares a cluster’s APIs with other clusters without installing the provider’s controllers there. The result went public as Klutch in August 2024, with version 1.0 on August 30, shipping APIs for a9s Data Services, a8s PostgreSQL and AWS S3 buckets.

Releases since then have renamed the two roles to app cluster and control plane cluster (1.3, January 2025), added TLS and more a9s services (1.4, December 2025; 1.5, May 2026), and added a mode that runs the konnector on the control plane (1.5.1, June 2026).

Why it’s built this way

A central control plane instead of operators everywhere: Installing an operator on every cluster makes monitoring, patching and cost control harder as cluster counts grow; one control plane serves them all.
Build on Crossplane: Crossplane already connects Kubernetes to many automation backends, so Klutch adds the multi-cluster layer and data service life cycle rather than writing provider code for each backend.
Borrow kube-bind for cross-cluster APIs: kube-bind installs only CRDs and one vendor-neutral agent in the consumer cluster, which lets developers use a service without running its controllers.
Service broker style abstractions: Service instances and bindings, familiar from the Open Service Broker API, give every data service the same shape; backup and restore were added because the broker model left them out.

Timeline

2024
Klutch open-sourced in August; version 1.0 on August 30
2025
1.3 in January renames clusters to app and control plane; 1.4 in December
2026
1.5 in May; 1.5.1 in June adds konnector control plane mode

Sources15 · facts checked 6 October 2026

Improve this page on GitHub