←back to thread

152 points rgun | 2 comments | | HN request time: 0.001s | source
Show context
psviderski ◴[] No.46144570[source]
Hey, creator here. Thanks for sharing this!

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

replies(11): >>46144726 #>>46144768 #>>46144784 #>>46144846 #>>46144978 #>>46145074 #>>46145335 #>>46145652 #>>46145808 #>>46146155 #>>46146244 #
1. mosselman ◴[] No.46144784[source]
You have a graph that shows a multi provider setup for a domain. Where would routing to either machine happen? As in which ip would you use on the dns side?
replies(1): >>46145223 #
2. calgoo ◴[] No.46145223[source]
Not OP, but you could do "simple" dns load balancing between both endpoints.