Show HN: Uncloud – Uncomplicated container orchestration without control plane | Hacker News Reader

Show HN: Uncloud – Uncomplicated container orchestration without control plane

github.com

30 pointspsviderski8 comments

Hey HN,

I'm building Uncloud — a lightweight clustering and container orchestration tool that lets you deploy and manage web apps across cloud VMs and bare metal with minimal cluster management overhead.

After several years of managing and extending Kubernetes at a unicorn, I realised that I desperately needed a change. All those abstraction layers, unnecessary complexity, boilerplate… I wanted container orchestration to bring me joy again, the way Ansible did when I first tried it a decade ago, or Docker after that.

That’s when I decided to start an experiment that is now called Uncloud. The core design principles I’ve focused on intentionally differ from the traditional container orchestrators like Kubernetes or Docker Swarm:

- No control plane or master nodes – all machines are equal

- P2P state synchronisation

- Imperative operations over state reconciliation (fast feedback, easier troubleshooting)

- Graceful handling of network partitions at the cost of eventual consistency

- No advanced auto-healing or auto-scaling magic – predictable behavior instead

I want well-designed building blocks that just work together. When a service needs high availability, I should be able to scale it across machines and know that if any machine goes down the remaining ones will continue serving traffic. When I deploy, I want immediate feedback, not wondering whether the reconciliation loop will eventually catch up.

GitHub with more technical details and a demo: https://github.com/psviderski/uncloud

It's not ready for production use yet, and I'd really love your feedback:

1. Am I alone in wanting a middle ground: something more sophisticated than basic Docker/Compose but without the operational complexity of Kubernetes?

2. If you've moved from platforms like EKS/Heroku/Render/Fly to self-hosting: what was the breaking point and what did you lose or gain in the transition?

3. If you're using tools like Kamal, Dokku, Coolify, or Dokploy, what are your biggest pain points?

Open articleView on HN

I don’t understand the storage story, imo different apps deal differently with replication and there’s no « one size fits all ». How are compose volumes replicated? Is split brain handled by corrosion or is it up to the uncloud user to set up stuff right in the docker compose?

ps: I self host and have moved from compose to k8s on single node, kustomize helps keep app configs as DRY as possible

I agree there is no one-size-fits-all for data replication. Currently Uncloud doesn't handle volume replication. Moreover it doesn't support regular Docker volumes yet, only mounting a host path. The reason is I didn't have time to give it proper thought on how to design volumes in a cluster context without getting into the full-blown PV support like in K8s.

I suspect that I will implement support for regular local Docker volumes such that each service container will use its own volume on the machine it runs on. Uncloud won't automatically replicate data between volumes as storage replication adds significant complexity and potential failure modes. Apps that need HA such as databases can handle their own replication. I'm getting inspiration from Fly for this: https://fly.io/docs/volumes/overview/. Maybe it would make sense to implement handy commands for cloning, moving, and backing up volumes between machines, not sure yet.

Corrosion (the embedded CRDT SQLite) is only used for Uncloud's internal state management, not for application data.

I see, so off the top of my head I’m thinking if uncloud could host some of my containers: nextcloud, plex, radarr, transmission, listmonk, linkding. And it seems its no better than my single node k8s, i.e they all have either sqlite or filesystems state, and no clear way for HA replication… mind you this isnt a problem of uncloud, moreso of the apps themselves

Yep agreed, but on the other hand do you really need HA for them when you're perhaps a single user? I wonder, what motivated you to migrate to single-node K8s from Compose for your self-hosted setup?

No I don’t really need HA, for most of my services high availability comes last. I moved to k8s for learning purposes, I stayed because I like it. When I decide to move some services to HA I have a much more powerful base with k8s than compose.

Loved this project. I hoe this project gets enough traction

Thanks for the encouragement! I'm working on it steadily and feedback like yours helps keep me motivated

BTW, is there something specific that caught your attention?

Reply on news.ycombinator.com