>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.
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.
Wow, that's very similar to my set up. Their diagram even shows off this staging/production pattern which is nearly identical to my own projects!
I use ansible to set up my hosts, and from there each app just brings it's own caddy & compose file. A bit of scripting and SOPS wraps the lint / build / deploy steps. Compared to my past life which was all k8s infra projects in helm... it is SO NICE to use these lightweight files instead.
If you have an app and you want to run a single app yeah silly to look for K8s.
If you have a beefy server or two you want to utilize fully and put as many apps on it without clashing dependencies you want to use K8s or docker or other containers. Where K8s enables you to go further.
I think automatic scaling is useful to utilize server fully - apps that don't need resources automatically scale down, apps that need resources can auto scale up.
I bet you can do it in some other way but that's built in feature of k8s.
There is very little reason to need auto-scaling when you run on pre-purchased VMs/servers. You've paid for all the compute so you can run as many replicas as it can fit and you need to handle the projected amount of traffic.
There are no benefits to scaling down in this case. And scaling up won't help handle more load if you've already allocated all resources to running replicas. You need more machines, not more replicas on the existing machine(s).
It all comes down to simple, boring capacity planning and static resource allocation. Fewer moving parts results in fewer failure modes, hence more robust infra and less ops and maintenance work.
Your response seems like you are talking about a single product / single application.
You have apps A, B and C (you have N teams and N products) each developed by different teams - that you want to run on that one server, when app A doesn't have much traffic apps B and C can use more of compute. Then having deployment management aligned for all teams/products.
Yes but at small scale. Myself and a handful of others from our Discord run it in production. The core build/push/deploy workflows are stable and most of the heavy lifting at runtime is done by battle-tested projects: Docker, Caddy, WireGuard, Corrosion from Fly.io.
Radboud University recently announced they're rolling it out for managing containers across the faculty which is the most "serious install" I know about, but there could be other: https://cncz.science.ru.nl/en/news/2026-04-15_uncloud/
TBF, the documentation says you can download and review the script, then run it. Or use other methods like a homebrew or (unofficial) Debian package, or you can just install the binary where you want it, which is all the install.sh script (107 lines, 407 words) does.
Uncloud is a bit lower-level, CLI-only (for now), with no central server. If some nodes go offline, the rest keep working and stay manageable.
It also has the WireGuard overlay networking built in so containers across machines get direct connectivity without having to map ports to the host. For example, securely access a database running on another machine. This also allows you to horizontally scale your services to multiple replicas on different machines and distribute traffic between them with minimal configuration.
The current state of Uncloud is the primitives and foundation that could be used to build a more higher-level PaaS-like solution such as Coolify.
>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 want this to behave?
I like that I can put my containers to be exposed on the traefik-public network, and keep others like databases unreachable from traefik. This organisation of networks is very useful, allowing to make containers reachable across stacks, but also to keep some containers in a stack reachable only from other containers on the same network in that same stack.
Fair points on the career and onboarding angle. It’s hard to argue against "everyone knows it".
But with that mentality, we'd never challenge anything. COBOL was the industry standard once. So were bare metal servers or fat VMs without containers. Someone had to say "this is more painful than it needs to be and I want to try something different because I can".
I know how to use k8s but I really don't enjoy it. It feels so distasteful to me that it triggered me to make an attempt at designing a nicer experience, because why not. I remember how much fun I had trying Docker when it first came out. That inspires me to at least try. It doesn't seem like the k8s community is even trying unfortunately.
The enterprise equivalent of COBOL today is Java and to a much lesser extent C#. Those were both championed by large corporations - Sun and Microsoft.
The move to VMs at first and then to the cloud were also marketed by existing companies with huge budgets where people who made decisions had the “No one ever got fired for choosing $LargeWellknownCompany that is in the upper right corner of Gartner’s Magic Square”.
I love Docker. I think everyone going to EKS before they need to is dumb. There are dozens of services out there that let you give it a Docker container and just run it.
And I think that spending energy avoiding “cloud lock-in” is dumb. Choose your infrastructure and build. Migrations are going to be a pain at any decent scale anyway and you are optimizing for the wrong thing if you are worried about lock in.
As an individual especially in today’s market, it’s foolish (not referring to you - any developer or adjacent) not to always be thinking of what keeps you the most employable if the rug gets pulled from under you.
As a decision maker who is held accountable for architecture and when things go wrong they look at or when the next person has to come along to maintain it, they are going to look at me like I am crazy if I choose a non industry standard solution just because I was too lazy to choose the industry standard.
Again I don’t mean that you are being “lazy”. That’s how people think.
But if I were hiring someone - and I’m often interviewing people for cloudy/devOps type roles. Why would I hire someone with experience with a Docker orchestration framework I never heard of over someone who knew K8s?
And the final question you should ask yourself is why are you really doing this?
Is it to scratch an itch out of passion and it’s something that you feel the world should have? If so in all sincerity, I wish you luck on your endeavor. You might get lucky like Bun just did. I had effusive praise for them doing something out of passion instead of as VC bait.
Are you doing it for financial gain? If so, you have to come up with a strategy to overcome resistance from people like Ive outlined.
Uncloud is lower-level. Dokploy seems to be positioning as a PaaS with a web UI using Docker Swarm under the hood for multi-node container management. Uncloud operates at that same layer as Swarm but with a simpler operating model that's friendlier for troubleshooting, WireGuard mesh networking built in, and the ability to connect nodes from different clouds or locations.
No UI yet (planned) so if that's critical, Dokploy is likely a better choice for now.
However, some unique features like building and pushing images directly to your nodes without an external registry give Uncloud a PaaS-like feel, just CLI-first. Really depends on what you're hosting and what you're optimising for.
Come join our cozy Discord server https://uncloud.run/discord. There is one guy joined recently who is migrating his homelab setup from Swarm right now.
Not rude at all. The benefit is a much simpler model where you simply connect machines in a network where every machine is equal. You can add more, remove some. No need to worry about an HA 3-node centralised “cluster brain”. There isn’t one.
It’s a similar experience when a cloud provider manages the control plane for you. But you have to worry about the availability when you host everything yourself. Losing etcd quorum results in an unusable cluster.
Many people want to avoid this, especially when running at a smaller scale like a handful of machines.
The cluster network can even partition and each partition continues to operate allowing to deploy/update apps individually.
That’s essentially what we all did in a pre-k8s era with chef and ansible but without the boilerplate and reinventing the wheel, and using the learnings from k8s and friends.
If you are a small operation and trying to self host k3s or k8s or any number of out of the box installations that are probably at least as complex as docker compose swarms, for any non trivial production case, presents similar problems in monitoring and availability as ones you’d get with off the shelf cloud provider managed services, except the managed solutions come without the pain in the ass. Except you don’t have a control plane.
I have managed custom server clusters in a self hosted situation. the problems are hard, but if you’re small, why would you reach for such a solution in the first place? you’d be better off paying for a managed service. What situation forces so many people to reach to self hosted kubernetes?
Yes, not everyone is allowed to use cloud services. There's also the cost. I haven't spent a cent on infrastructure in 5 years (other than my time). Using cloud services comes with extra costs and meetings to justify those costs. Plus, not everyone is in the USA or 1st world country where those costs are negligible. Necessity is the mother of invention.
This thread is about using multi-machine clusters, and sqlite cannot be used for multi-machine clusters in k3s. etcd is the default when starting k3s in cluster mode [1].
No, this thread is about multiple containers across machines. What you describe is multi-master for the server. You can run multple agents across serveral nodes therefore clustering the container workload across multiple container hosting servers. Multi-master is something different.
The very first paragraph of the first comment you replied to is about multi-master HA. The second sentence in that comment is about “every machine is equal”. k3s with sqlite is awesome, but it cannot do that.
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.