psviderski

5 ms·

1.
by psviderski 3mo ago
>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
2.
You Don't Need Kubernetes(green.spacedino.net)
6 points by psviderski 4mo ago|2 comments
3.
by psviderski 5mo ago
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. Ther
4.
by psviderski 5mo ago
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.
5.
by psviderski 5mo ago
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.
6.
by psviderski 5mo ago
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, Cadd
7.
by psviderski 5mo ago
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
8.
by psviderski 9mo ago
> 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 cou
9.
by psviderski 10mo ago
No, and this is out of scope at least for now. Please see another reply: https://news.ycombinator.com/item?id=46146434
10.
by psviderski 10mo ago
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
11.
by psviderski 10mo ago
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 co
12.
by psviderski 10mo ago
>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/ht
13.
by psviderski 10mo ago
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:
14.
by psviderski 10mo ago
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
15.
by psviderski 10mo ago
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 IP
16.
by psviderski 10mo ago
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-t
17.
by psviderski 10mo ago
>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
18.
by psviderski 10mo ago
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 V
19.
by psviderski 10mo ago
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&#x27
20.
by psviderski 10mo ago
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
21.
by psviderski 10mo ago
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
22.
by psviderski 10mo ago
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.
23.
by psviderski 10mo ago
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 s
24.
by psviderski 10mo ago
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.
25.
by psviderski 10mo ago
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 m
26.
by psviderski 10mo ago
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
27.
by psviderski 10mo ago
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
28.
by psviderski 10mo ago
Awesome, will reach out!
29.
by psviderski 10mo ago
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 on
30.
by psviderski 10mo ago
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 m

More ›