psviderski

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.

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

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.

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.