Uncloud[0] is a container orchestrator without a control plane. Think multi-machine Docker Compose with automatic WireGuard mesh, service discovery, and HTTPS via Caddy. Each machine just keeps a p2p-synced copy of cluster state (using Fly.io's Corrosion), so there's no quorum to maintain.

I’m building Uncloud after years of managing Kubernetes in small envs and at a unicorn. I keep seeing teams reach for K8s when they really just need to run a bunch of containers across a few machines with decent networking, rollouts, and HTTPS. The operational overhead of k8s is brutal for what they actually need.

A few things that make it unique:

- uses the familiar Docker Compose spec, no new DSL to learn

- builds and pushes your Docker images directly to your machines without an external registry (via my other project unregistry [1])

- imperative CLI (like Docker) rather than declarative reconciliation. Easier mental model and debugging

- works across cloud VMs, bare metal, even a Raspberry Pi at home behind NAT (all connected together)

- minimal resource footprint (<150MB ram)

[0]: https://github.com/psviderski/uncloud

[1]: https://github.com/psviderski/unregistry

To me, the control plane is the primary feature of kubernetes and one I would not want to go without.

I know this describes operational overhead as a reason, but how it relates to the control plane is not clear to me. even managing a few hundred nodes and maybe 10,000 containers, relatively small - I update once a year and the managed cluster updates machine images and versions automatically. Are people trying to self host kubernetes for production cases, and that’s where this pain comes from?

Sorry if it is a rude question.

If you want something even simpler, something that doesn't run on your servers at all, you can look at Kamal: https://kamal-deploy.org

What I like about Kamal is that it's backed by a company that actually fully moved out of K8s and cloud, so every release is battle-tested first.

Some questions I have based on my swarm usage:

- do you plan to support secrets?

- with swarm and traefik, I can define url rewrite rules as container labels. Is something equivalent available?

- if I deploy 2 compose 'stacks', do all containers have access to all other containers, even in the other stack?

I am wondering how state replication works on the backend. The design mentions using crdt and a gossip proto, but I'm not sure what is actually implemented as it is a tad vague. I haven't dug into the code so forgive me if it is obvious or explained elsewhere.

BTW just looking at other variations on the theme:

- https://dokploy.com/

- https://coolify.io/

- https://demo.kubero.dev/

Feel free to add more.

https://github.com/mudler/edgevpn https://www.iroh.computer/

Looks like the docs assume the management of a single cluster. What if you want to manage multiple/distinct clusters from the same uc client/management env?

This would have been my choice had it existed three months ago. Now it feels like I learned kubernetes in vain xD

Even coolify lets you add as many machines as you want and then manage docker containers in all machines from one coolify installation.

Gonna burn bridges with this lack of transparency. I love the intent but the implementation is so bad that I probably wont look back.

But, as a lead for implementations, I just couldn’t in good conscience permit something that is not an industry standard and not supported by my cloud provider. First from a self interested standpoint, it looks a lot better on their resume to say “I did $x using K8s”.

From an onboarding standpoint, just telling a new employee “we use K8s -here you go” means nothing new to learn.

If you are part of the industry, just suck it up and learn Kubernetes. Your future self won’t regret it - coming from someone who in fact has not learn K8s.

This is a challenge any new framework is going to have.