Run Kubernetes YAML on a handful of machines. One binary, no Kubernetes.
Clustro is one binary that turns a handful of Linux machines into a cluster: pods spread across nodes, an encrypted network between them, and Services with cluster DNS. Built for small teams running 22 nodes or fewer.
What is Clustro?
Small teams get stuck between options that don't fit. Docker Compose is simple but runs on one host. Docker Swarm supports multi-node clusters, but its ecosystem is shrinking and its future is uncertain. Kubernetes scales to thousands of nodes, but on a cluster of 22 nodes or fewer most of it is overhead you still have to learn, run and debug.
Clustro sits in the gap. It keeps the part of Kubernetes teams already know, the YAML, and runs it on the containerd that Docker already installs, with a control plane that is a single process.
Why use it
One binary
The same executable is the CLI, the leader and the worker. Small enough for one engineer to understand in a week.
Kubernetes YAML
Standard Pod manifests run unchanged. Unsupported fields fail with a clear error, never silently.
Nothing new on the node
Runs on the containerd that comes with Docker. Containers in a pod share one IP and localhost, as in Kubernetes, with no extra images to pull.
No etcd
Cluster state lives in one embedded database file. Backup is a file copy.
Zero-config discovery
Machines on the same network find the leader on their own. Join with a single token.
Networking built in
Every pod gets its own IP. Nodes connect over an encrypted WireGuard mesh, even across offices and clouds. Services and *.svc.cluster.local names work as in Kubernetes.
Who it's for
| A good fit | Use Kubernetes instead |
|---|---|
| Teams of 3–20 engineers with no dedicated platform team, running 3–22 Linux nodes: SaaS startups, agencies, SMBs, edge and branch sites. | 100+ nodes, multiple regions, a service mesh, or a dependency on the wider Kubernetes API and operator ecosystem. |
Early adopter program
We're opening Clustro to 5 small teams before general release.
You get a direct line to the people building it, a real say in what ships next, and help getting your first cluster running.
We ask that you run it on a real small cluster and tell us what breaks.
Clustro is in Phase 1, and we are rebuilding it as v2: Pods on containerd, restarts, liveness and readiness probes, logs, a WireGuard pod network across sites, Services (ClusterIP and NodePort) with cluster DNS, TLS on every connection, and backup and restore. Worker nodes run Linux; macOS runs the CLI. Deployments, ConfigMaps and Secrets come in Phase 2.
Frequently asked questions
What is Clustro?
Clustro is a single-binary container orchestrator that runs standard Kubernetes YAML on clusters of 22 Linux nodes or fewer, without running Kubernetes. One process with one state file replaces the API server, etcd, kubelet, CNI, CoreDNS and kube-proxy, and pod networking, Services and cluster DNS are built in.
How is Clustro different from Kubernetes and it's offsprings distributions?
Kubernetes and it's offsprings distributions: they make Kubernetes smaller to install, but you still learn and operate the same control plane and concepts. Clustro is not Kubernetes. It accepts Kubernetes YAML and runs it with its own small control plane, so there is no Kubernetes to operate.
Can I use kubectl, Helm charts or operators with Clustro?
No. Clustro speaks Kubernetes YAML, not the Kubernetes API, so tools that talk to the API (kubectl, Helm, ArgoCD, Lens), operators and CRDs don't work with it. You manage the cluster with the clustroctl CLI. If you depend on those tools, a lightweight distribution such as k3s is the better fit.
What happens when we outgrow Clustro?
You move to any Kubernetes cluster with the same files. YAML that Clustro accepts runs on Kubernetes unchanged, because Clustro rejects unsupported fields with their exact path instead of ignoring them.
Which Kubernetes objects does Clustro support?
Phase 1 supports Pods, with restarts, liveness and readiness probes, logs and node and pod affinity, and Services of type ClusterIP and NodePort with *.svc.cluster.local DNS names. Deployments, ConfigMaps and Secrets are planned for Phase 2.
Do I need Docker to run Clustro?
No, but it works with it. Clustro runs containers on containerd 1.7 or later: either the containerd that every Docker install already includes, or a standalone containerd. It adds no extra images to the node.
What operating systems and hardware does Clustro run on?
Worker nodes run Linux on amd64 or arm64, with kernel 5.6 or later and containerd 1.7 or later. macOS can run the clustroctl CLI and a leader that doesn't run pods.
Why is Clustro limited to 22 nodes?
Clustro is built for small teams, and designing for 22 nodes or fewer keeps it simple: a full-mesh pod network, the complete desired state in every worker heartbeat, and cluster state in a single file. Above that scale, Kubernetes starts to pay for its complexity, and Clustro says so.
Can a Clustro cluster span offices and clouds?
Yes. Every pod gets its own IP, and nodes connect over an encrypted WireGuard mesh that works across offices, data centres and clouds. Encryption is on by default.
Where does Clustro store cluster state, and how do I back it up?
Cluster state lives in one embedded BoltDB database file on the leader; there is no etcd. A backup is a consistent snapshot of that file, taken while the leader keeps running. You restore it on the leader while the leader is stopped.
Is Clustro highly available?
Not yet. Phase 1 runs a single leader; if it goes down, running pods keep running but the cluster can't be changed until it's back. A highly available leader is planned for Phase 3.
Is Clustro ready for production?
Not yet. Clustro is in Phase 1 of development. We're working with a small group of early adopters who run it on real clusters and tell us what breaks. Join the early adopter program to be one of them.