psviderski

>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.

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.

Yep, the latest release embeds the install script in the CLI binary instead of using curl | sh, so it's versioned together with the CLI.

Why would you want to use K8s for one or two beefy servers? It's designed for solving a different problem at a large scale.

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/

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.

> In fact could you not just cron the cli deployment command on the nodes and get an effective poor man's declarative layer to guard against node failures if your ok with a 1 min or 1 sec recovery objective?

Yeah, you absolutely could and someone on our Discord has written a 30-line bash script that essentially runs a reconciliation loop with the CLI.

Thanks for the point on underselling by calling it imperative rather than declarative!

No, and this is out of scope at least for now. Please see another reply: https://news.ycombinator.com/item?id=46146434

Haha the K8s knowledge will definitely pay off. But Uncloud did exist three months ago. Clearly my marketing needs work :D

On the bright side, you can always use both

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?

How was your Swarm experience so far? It's so disappointing that Docker seems to slowly but steadily abandoning it. There is only a couple dozen mainly maintenance commits in the swarmkit repo for the entire 2025 year :sigh:

As I mentioned in the sibling comment, please note that in this case you only get round-robin, not failover. If one of the addresses is down, the DNS record will continue returning it and users will hit a dead end.

A proper load balancer or Cloudflare DNS proxy would handle this.

Thanks! If you're running the ucloud cluster in AWS, service containers should be able to access RDS the same way the underlying EC2 instances can (assuming RDS is in the same VPC or reachable via VPC peering).

The private container IPs will get NATed to the underlying EC2 IPs so requests to RDS will appear as coming from those instances. The appropriate Security Group(s) need to be configured as well. The limitation is that you can't segregate access at the service level, only at the EC2 instance level.

Great setup! Where Uncloud helps is when you need containers across multiple machines to talk to each other.

Your setup sounds like single-node or nodes that don't need to discover each other. If you ever need multi-node with service-to-service communication, that's where stitching together Ansible + Terraform + quadlets + some networking layer starts to get tedious. Uncloud tries to make that part simple out of the box.

You also get the reverse proxy (Caddy) that automatically reconfigures depending on what containers are running on machines. You just deploy containers and it auto-discovers them. If a container crashes, the configuration is auto-updated to remove the faulty container from the list of upstreams.

Plus a single CLI you run locally or on CI to manage everything, distribute images, stream logs. A lot of convenience that I'm putting together to make the user experience more enjoyable.

But if you don't need that, keep doing what works.

>A normal person wouldn't think 'hey lets use k8s for the low stakes deployment over here'.

I'm afraid I have to disappoint you

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.

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.

See short deploy demo: https://uncloud.run/docs/guides/deployments/deploy-app

This is exactly how it works now. The Compose file is the declarative specification of your services you want to run.

When you run 'uc deploy' command:

- it reads the spec from your compose.yaml

- inspects the current state of the services in the cluster

- computes the diff and deployment plan to reconcile it

- executes the plan after the confirmation

Please see the docs and demo: https://uncloud.run/docs/guides/deployments/deploy-app

The main difference with Docker Swarm is that the reconciliation process is run on your local/CI machine as part of the 'uc deploy' CLI command execution, not on the control plane nodes in the cluster.

And it's not running in the loop automatically. If the command fails, you get an instant feedback with the errors you can address or rerun the command again.

It should be pretty straightforward to wrap the CLI logic in a Terraform or Pulumi provider. The design principals are very similar and it's written in Go.

For the public cluster with multiple ingress (caddy) nodes you'd need a load balancer in front of them to properly handle routing and outage of any of them. You'd use the IP of the load balancer on the DNS side.

Note that a DNS A record with multiple IPs doesn't provide failover, only round robin. But you can use the Cloudflare DNS proxy feature as a poor man's LB. Just add 2+ proxied A records (orange cloud) pointing to different machines. If one goes down with a 52x error, Cloudflare automatically fails over to the healthy one.

I don't know what the specific requirements for the distributed erlang/elixir but I believe the networking should support it. Containers get unique IPs on a WireGuard mesh with direct connectivity and DNS-based service discovery.

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.

Also another community member shared his homelab with a couple dozen services migrated from Docker Compose to Uncloud: https://github.com/dasunsrule32/docker-compose-configs/tree/...

Totally valid concern. That was a shortcut to iterate quickly in early development. It’s time to do it properly now. Appreciate the feedback. This is exactly the kind of thing I need to hear before more people try it.

Thank you! That's actually the trade off.

There is no automatic rescheduling in uncloud by design. At least for now. We will see how far we can get without it.

If you want your service to tolerate a host going down, you should deploy multiple replicas for that service on multiple machines in advance. 'uc scale' command can be used to run more replicas for an already deployed service.

Longer term, I'm thinking we can have a concept of primary/standby replicas for services that can only have one running replica, e.g. databases. Something similar to how Fly.io does this: https://fly.io/docs/apps/app-availability/#standby-machines-...

Regarding deploying on the less filled machine first is doable but not supported right now. By default, it picks the first machine randomly and tries to distributes replicas evenly among all available machines. You can also manually specify what target machine(s) each service should run on in your Compose file.

I want to avoid recreating the complexity with placement constraints, (anti-)affinity, etc. that makes K8s hard to reason about. There is a huge class of apps that need more or less static infra, manual placement, and a certain level of redundancy. That's what I'm targeting with Uncloud.

For CI/CD, check out this GitHub Action: https://github.com/thatskyapplication/uncloud-action.

You can either specify one of the machine SSH target in the config.yaml or pass it directly to the 'uc' CLI command, e.g.

uc --connect user@host deploy

I think there are two different cases here. Not sure which one you’re talking about.

1. External requests, e.g. from the internet via the reverse proxy (Caddy) running in the cluster.

The rollout works on the container, not the server level. Each container registers itself in Caddy so it knows which containers to forward and distribute requests to.

When doing a rollout, a new version of container is started first, registers in caddy, then the old one is removed. This is repeated for each service container. This way, at any time there are running containers that serve requests.

It doesn’t say any server that requests shouldn’t go there. It just updates upstreams in the caddy config to send requests to the containers that are up and healthy.

2. Service to service requests within the cluster. In this case, a service DNS name is resolved to a list of IP addresses (running containers). And the client decides which one to send a request to or whether to distribute requests among them.

When the service is updated, the client needs to resolve the name again to get the up-to-date list of IPs. Many http clients handle this automatically so using http://service-name as an endpoint typically just works. But zero downtime should still be handled by the client in this case.

Awesome, will reach out!

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.

Thank you for the suggestion!

I’m working full time on this, yes. Funding from my savings at the moment and don’t have plans for any external funding or VC.

For monetisation, considering building a self-hosted and managed (SaaS) webUI for managing remote clusters and apps on them with value-added PaaS-like features.