Compose is too little. Kubernetes is too much.
Why we started building a smaller orchestrator for small teams.
Picture a six-person team moving their product off a single Docker Compose host to "something that can survive a dead server". They have four machines, a dozen services, and nobody whose job title includes the word platform.
They choose Kubernetes, because that's what everyone chooses. A few months later they have a working cluster, a better understanding of certificate rotation than they ever wanted, and an unwritten rule that only one person touches the cluster.
That team isn't doing anything wrong. They're stuck between two options that don't fit.
The gap
On one side is Docker Compose. It's simple, everyone knows it, and it runs on one host. When that host dies, so does the product. Docker Swarm adds clustering, but it has its own manifest format and a shrinking ecosystem.
On the other side is Kubernetes, and the lighter distributions built from it: k3s, k0s, MicroK8s. They're excellent software. They also bring etcd, a container runtime interface, network plugins, storage plugins, RBAC, admission control and a family of controllers. The concepts are all still there, and so are the ways they fail.
When you list what a team of five engineers with eight machines actually uses from all of that, the list is short:
- put this container on a healthy machine
- restart it if it dies
- describe it in a YAML file I can review
- show me its logs
- move it if a machine goes away
Everything else is still there, waiting to break on a Friday.
The YAML is the valuable part
The part of Kubernetes small teams like isn't the control plane. It's the manifest format. A Pod spec is a decent, widely understood way to say "run this image, with these ports, this much memory, these environment variables". Engineers already know it. Every tutorial uses it. Every new hire has seen it.
So we asked: what if you kept the YAML and dropped everything underneath that a small cluster doesn't need?
That question became Clustro: one binary, Docker underneath, standard Kubernetes Pod YAML on top. The whole control plane is a single process with an embedded database. No etcd, no CRI layer, no network plugins.
The rules we hold ourselves to
If a feature doesn't make running a cluster of 22 nodes or fewer easier, it doesn't ship. We keep an explicit "never" list: no CRDs or operator framework, no attempt at the full Kubernetes API, no built-in service mesh. If Clustro's complexity ever starts to approach Kubernetes, it has failed.
Understandable in a week. One engineer should be able to understand the whole system, end to end, in a week. That settles a lot of arguments. A pluggable runtime layer? Not yet: Docker is what our users run. A scheduler that scores nodes on ten factors? No: at 22 nodes, "filter out nodes that can't fit the pod, then round-robin" is predictable and you can work it out by hand.
And the targets you'd expect: install a node in under five minutes, deploy the first workload five minutes after that, and keep the control plane under half a CPU core and 512 MB of RAM. These are targets, not measurements yet.
Who it isn't for
Clustro isn't for everyone. If you run 100+ nodes, multiple regions or a service mesh, or you depend on the wider Kubernetes API and operator ecosystem, run Kubernetes. It's the right tool for that job, and we'll say so to anyone who asks.
Where it stands
Clustro is in Phase 1. Today it can form a cluster on a local network with clustroctl init and clustroctl join, schedule Pods across nodes, restart them with backoff, run liveness probes, stream logs, and back up and restore cluster state. Deployments, Services, ConfigMaps and Secrets come in Phase 2, and high availability in Phase 3.
Clustro should not be a smaller Kubernetes. It should be the simplest production-grade orchestrator that feels familiar to Kubernetes users.
If this sounds like your team
If you run containers on a handful of machines and you've felt that Compose is too little and Kubernetes too much, we'd like to hear from you. We're looking for a few small teams (3–22 nodes) to run Clustro as design partners.