uncloud

>I think there is a real hole in the market for a simple solution that lets you deploy some containers to some instances in a declarative fashion without all of that complexity That's how I see it as well but it's really tough to go against the grain. I have a small enthusiastic community of users around Uncloud (https://github.com/psviderski/uncloud) who went full circle - fed up with k8s and came back to simple, boring declarative Compose deployments across a handful of interconnected hosts. Uncloud is essentially a cluster version of Docker Compose without a control plane and cluster management overhead.

Compose is great, but a couple things always created friction for me when using it for non-local setups: * Lack of a user-friendly way of managing a Docker Compose installation on a remote host. SSH-forwarding the docker socket is an option, but needs wrappers and discipline. * Growing beyond one host (and not switching to something like Kubernetes) would normally mean migrating to Swarm, which is its own can of worms. * Boilerplate needed to expose your services with TLS Uncloud [1] fixed all those issues for me and is (mostly) Compose-compatible. [1] https://github.com/psviderski/uncloud/

A single VM is indeed the most pragmatic setup that most apps really need. However I still prefer to have at least two for little redundancy and peace of mind. It’s just less stressful to do any upgrades or changes knowing there is another replica in case of a failure. And I’m building and happily using Uncloud (https://github.com/psviderski/uncloud) for this (inspired by Kamal). It makes multi-machine setups as simple as a single VM. Creates a zero-config WireGuard overlay network and uses the standard Docker Compose spec to deploy to multiple VMs. There is no orchestrator or control plane complexity. Start with one VM, then add another when needed, can even mix cloud VMs and on-prem.

What's the difference with https://github.com/psviderski/uncloud ?

>with swarm and traefik, I can define url rewrite rules as container labels. Is something equivalent available? Yep, you define the mapping between the domain name and the internal container port as `x-ports: app.example.com:8000/https` in the compose file. Or you can specify a custom Caddy config for the service as `x-caddy: Caddyfile` which allows to customise it however you like. See https://uncloud.run/docs/concepts/ingress/publishing-service... >if I deploy 2 compose 'stacks', do all containers have access to all other containers, even in the other stack? Yes, there is no network isolation between containers from different services/stacks at the moment. Here is an open discussion on stack/namespace/environment/project concepts and isolation: https://github.com/psviderski/uncloud/discussions/94. What's your use case and how would you

Secrets -- yes, it's being tracked here: https://github.com/psviderski/uncloud/issues/75 Compose configs are already supported and can be used to inject secrets as well, but there'll be no encryption at rest there in that case, so might not be ideal for everyone. Regarding questions 2 and 3, the short answers are "not at the moment" and "yes, for now", here's a relevant discussion that touches on both points: https://github.com/psviderski/uncloud/discussions/94 Speaking of Swarm and your experience with it: in your opinion, is there anything that Swarm lacks or makes difficult, that tools like Uncloud could conceptually "fix"?

+1 on this I wanted to try it out but was put off by this[0]. It’s just straight up curl | bash as root from raw.githubusercontent.com. If this is the install process for a server (and not just for the CLI) I don’t want to think about security in general for the product. Sorry, I really wanted to like this, but pass. [0] https://github.com/psviderski/uncloud/blob/ebd4622592bcecedb...

There is an open issue that confirms enabling ipv6 for containers works: https://github.com/psviderski/uncloud/issues/126 But this hasn’t been enabled by default. What specifically do you mean by ipv6 support?

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 ot

Check out https://github.com/psviderski/uncloud I'm building. Multi-machine deployments and a private WireGuard network spanning locations (even behind a NAT) are its core capabilities.

Looks like uncloud has no control plane, just a CLI: https://github.com/psviderski/uncloud#-features

I got tired of the push-to-registry/pull-from-registry dance every time I needed to deploy a Docker image. In certain cases, using a full-fledged external (or even local) registry is annoying overhead. And if you think about it, there's already a form of registry present on any of your Docker-enabled hosts — the Docker's own image storage. So I built Unregistry [1] that exposes Docker's (containerd) image storage through a standard registry API. It adds a `docker pussh` command that pushes images directly to remote Docker daemons over SSH. It transfers only the missing layers, making it fast and efficient. docker pussh myapp:latest user@server Under the hood, it starts a temporary unregistry container on the remote host, pushes to it through an SSH tunnel, and cleans up when done. I've built it as a byproduct while working on Uncloud [

I'm actually building something in between Docker and Kubernetes: https://github.com/psviderski/uncloud. Like you I wanted that middle ground without the operational overhead. It's basically Docker-like CLI and Docker Compose with multi-machine and production capabilities but no control plane to maintain. Still in active development but the goal is to keep it simple enough that you can easily understand what's happening at each layer and can troubleshoot.

After a decade of professionally working with container orchestrators like Kubernetes and ECS I quit my job to build Uncloud — an open source lightweight version of those [1]. I want the tool to bring me joy when I use it, in a similar way Docker did when I first tried it in 2013. Imagine Docker Compose and Tailscale had a baby. Uncloud is the baby that allows you to deploy and manage containers across a network of Docker hosts. I feel like we forgot how to build simple tools that do the job and not a thousand other unnecessary things. I've started migrating some of my self-hosted web apps from my k8s cluster and I really enjoy it. Using the tool early on helps me better understand where the biggest pain points are and what I need to prioritise. [1]: https://github.com/psviderski/uncloud

This is a great approach which resonates with me a lot. It's really frustrating that there is no simple way to run a multi-host Docker/Podman (Docker Swarm is abandonware since 2019 unfortunately). However, in my opinion K8s has the worst API and UX possible. I find Docker Compose spec much more user friendly. So I'm experimenting with a multi-host docker-compose at the moment: https://github.com/psviderski/uncloud