# Claudie builds one Kubernetes cluster across clouds and bare metal

> Claudie is a Go platform that takes a single InputManifest and provisions a Kubernetes cluster whose node pools mix AWS, Azure, GCP, OCI and your own servers, and its architecture is a set of specialised services rather than one controller.

**berops/claudie** — Cloud-agnostic managed Kubernetes

- Repository: https://github.com/berops/claudie
- Website: https://docs.claudie.io/
- Stars: 793 · Forks: 61
- Language: Go
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/berops-claudie

## One manifest spans providers, and the goal is not to migrate away

The stated vision is that the purpose of Claudie is to become the final Kubernetes engine you will ever need, that it builds clusters which leverage features and costs across on-premises datacenters and multiple cloud vendors, all from a single InputManifest, producing a Kubernetes that you will not ever need to migrate away from. That last clause is the product positioning and it is worth taking seriously, because it is a different goal from most cluster tooling. A tool that provisions a cluster on one provider lets you move later. A tool that spans providers from the start is designed to make moving unnecessary. The use cases the README lists follow from that: cost savings, data locality and compliance such as GDPR, managed Kubernetes for providers that do not offer it, cloud bursting, service interconnect, on-premises and hybrid integration of existing bare-metal or co-located servers as nodepools, and integration of GPU nodes into Kubernetes for AI workloads. The audience is a platform team with a reason to spread one cluster across more than one owner.

## The service split is the architecture

The Makefile is the clearest map of the system, because it names each service and the port it listens on. The manager runs the API server on port 50055. The terraformer runs on 50052 and is pointed at a bucket with BUCKET_URL, with AWS credentials pointing at MinIO in the local setup, so it is the component that talks to cloud providers and Terraform. The ansibler runs on 50053. The kube-eleven service runs on 50054, which is the pun on eleven for a component whose job is, by the name and the surrounding services, the Kubernetes layer. The kuber runs on 50057 and the claudie-operator is started without a port. The communication between them is NATS, with github.com/nats-io/nats.go in the dependencies, and the project also depends on the AWS SDK v2, HCL v2 for parsing, MongoDB as the state store, gRPC with protobuf for the service contracts, and controller-runtime with client-go at v0.37. The repository layout mirrors it, with services/ for the individual services, proto/ for the protocol definitions, internal/ for shared code, manifests/ for the Kubernetes deployment, api/ for the interface, and docs/ with an mkdocs.yml. So this is a distributed control plane with a message bus, not a single binary that reconciles a CRD.

## It installs itself into a cluster you already have

The prerequisite that decides whether you can try Claudie is the first one. Claudie needs to be installed on an existing Kubernetes cluster, referred to as the Management Cluster, which it uses to manage the clusters it provisions. The README says that for testing you can use ephemeral clusters like Minikube or Kind, and that for production environments it recommends a more resilient solution, because Claudie maintains the state of the infrastructure it creates. That state comment is the important one, since the management cluster is not a convenience, it is the database of your estate. The second prerequisite is cert-manager in the management cluster.

```bash
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.19.3/cert-manager.yaml
```

The version is pinned in the command, which tells you the project tests against a specific cert-manager release. The Makefile also has a kind-deploy target and a kind-load-images target, so the local development path is a Kind cluster with the built images loaded into it, plus a mongo target for the state store and a minio target for the bucket the terraformer uses.

## Nine providers, and the feature columns are not uniform

The provider table is more informative than a flat list of names, because it shows which capabilities each one supports. The columns are Node Pools, DNS, DNS healthchecks, GPU and Spot. AWS, Azure, GCP and OCI have every column marked. Exoscale and Hetzner have node pools, DNS and GPU, with DNS healthchecks and Spot marked not applicable. CloudRift and VastAI have node pools and GPU only, with DNS, DNS healthchecks and Spot all marked not applicable; Verda additionally supports Spot. The pattern is a ranking of provider maturity, and the two columns with the most not applicable entries are the ones that need provider-specific API support rather than generic infrastructure calls. A team choosing a provider for a Claudie cluster should read the table rather than the provider list, because a provider without DNS support means you bring your own DNS.

## Load balancing and storage are built in rather than delegated

Two capabilities are provided by Claudie itself, and that is a significant part of what makes a multi cloud cluster workable. The first is load balancing. Claudie has its own managed load-balancing solution, which you can use for Ingresses, for the Kubernetes API server, or generally for anything, with the load balancing documentation linked from the README. A cluster spread across four providers has no shared layer 4 or layer 7 target, so a managed load balancer that can program each provider's API is what makes Ingress work at all. The second is persistent storage. Claudie comes pre-configured with a storage solution, with ready-to-use Storage Classes, documented separately. The pattern is consistent. Where the providers disagree, Claudie implements the hard part itself rather than leaving a gap, which is also why the project carries a Terraformer for the provider side, an Ansibler for configuration work, and a Kuber for the Kubernetes side.

## Where Claudie is the wrong choice

The first limit is that all of this machinery is pointless if you have one provider and no special constraint. A managed Kubernetes service from AWS, Azure or GCP gives you node pools, load balancing and storage classes with none of the state management, the message bus or the six services. The second limit is the operational model. Claudie maintains the state of the infrastructure it creates in a management cluster, so you now have a control plane whose failure or loss matters, and the README is careful to say that a production management cluster should be resilient rather than ephemeral. A team that does not have the capacity to run and back up that cluster is signing up for a new operational dependency in exchange for portability they may not need. The third is the version line. The project is at v0.16.2, which is pre-1.0, so the manifest syntax and the service interfaces are still moving, and the input manifest is the contract between you and the tool, which means a schema change can require rewriting your configuration. The fourth is the documentation split, since the README is an overview and the substance lives at docs.claudie.io, so evaluating the project properly means reading the docs, not the repository.

## Conclusion

Claudie suits a platform team that needs a cluster to span providers and on-premises hardware for cost, data residency or GPU reasons, and it suits anyone who wants that described in one YAML file rather than in several Terraform modules. It is the wrong tool for a single provider workload, where a managed Kubernetes service is less machinery, and it is the wrong tool for a team without a Kubernetes cluster of its own to run the management plane, because Claudie installs itself into one. Before trying it, read the prerequisites, since cert-manager has to be installed and the management cluster holds the state of the infrastructure Claudie creates. The last push was on 2026-10-22 and the current release is v0.16.2 from 2026-10-16.

## FAQ

### What is Claudie?

Claudie is a platform for managing multi cloud, hybrid cloud and on-premises Kubernetes clusters, with node pools that mix cloud providers and your own bare-metal or co-located servers. It builds the clusters from a single InputManifest and is licensed under Apache-2.0.

### What does Claudie need before it can run?

It has to be installed on an existing Kubernetes cluster, the Management Cluster, which it uses to manage the clusters it provisions and which holds the state of the infrastructure. The README suggests Minikube or Kind for testing and a more resilient cluster for production, and it requires cert-manager to be installed as well.

### Which cloud providers does Claudie support?

The provider table covers AWS, Azure, GCP, OCI, Exoscale, Hetzner, CloudRift, Verda and VastAI, with columns for node pools, DNS, DNS healthchecks, GPU and Spot. AWS, Azure, GCP and OCI have every capability marked, while the smaller providers have fewer.

### How is Claudie built and what are its services?

It is a Go project on go 1.27.1 with a Makefile that starts each service separately, including the manager API server on port 50055, the terraformer on 50052, the ansibler on 50053, kube-eleven on 50054, the kuber on 50057 and the claudie-operator, with NATS for messaging and MongoDB for state. The build also generates protobuf code with a pinned protoc version.

## Sources

- [berops/claudie on GitHub](https://github.com/berops/claudie)
- [License: Apache-2.0](https://github.com/berops/claudie/blob/master/LICENSE)
- [Project website](https://docs.claudie.io/)
- [README](https://github.com/berops/claudie/blob/master/README.md)
- [Releases](https://github.com/berops/claudie/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/berops-claudie