17 ms·

Uncloud - Tool for deploying containerised apps across servers without k8s

403 points by rgun 10mo ago

psviderski 10mo ago
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 other project unregistry [1]) - imperative CLI (like Docker) rather than declarative reconciliation. Easier mental model and debugging - works across cloud VMs, bare metal, even a Raspberry Pi at home behind NAT (all connected together) - minimal resource footprint (<150MB ram) [0]: https://github.com/psviderski/uncloud https://github.com/psviderski/uncloud [1]: https://github.com/psviderski/unregistry https://github.com/psviderski/unregistry
- olegp 10mo ago
  How's this similar to and different from Kamal? https://kamal-deploy.org/ https://kamal-deploy.org/
  - psviderski 10mo ago
    I took some inspiration from Kamal, e.g. the imperative model but kamal is more a deployment tool. In addition to deployments, uncloud handles clustering - connects machines and containers together. Service containers can discover other services via internal DNS and communicate directly over the secure overlay network without opening any ports on the hosts. As far as I know kamal doesn’t provide an easy way for services to communicate across machines. Services can also be scaled to multiple replicas across machines.
    - olegp 10mo ago
      Thanks! I noticed afterwards that you mention Kamal in your readme, but you may want to add a comparison section that you link to where you compare your solution to others. Are you working on this full time and if so, how are you funding it? Are you looking to monetize this somehow?
      - 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 managing remote clusters and apps on them with value-added PaaS-like features.
        olegp 10mo ago
        That sounds interesting, maybe I could help on the business side of things somehow. I'll email you my calendar link.
        psviderski 10mo ago
        Awesome, will reach out!
    - cpursley 10mo ago
      This is neat, regarding clustering - can this work with distributed erlang/elixir?
      - 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.
      - jabr 10mo ago
- topspin 10mo ago
  "I keep seeing teams reach for K8s when they really just need to run a bunch of containers across a few machines" Since k8s is very effective at running a bunch of containers across a few machines, it would appear to be exactly the correct thing to reach for. At this point, running a small k8s operation, with k3s or similar, has become so easy that I can't find a rational reason to look elsewhere for container "orchestration".
  - nullpoint420 10mo ago
    100%. I’m really not sure why K8S has become the complexity boogeyman. I’ve seen CDK apps or docker compose files that are way more difficult to understand than the equivalent K8S manifests.
    - esseph 10mo ago
      Managing hundreds or thousands of containers across hundreds or thousands of k8s nodes has a lot of operational challenges. Especially in-house on bare metal.
      - sceptic123 10mo ago
        I don't think that argument matches with they "just need to run a bunch of containers across a few machines"
      - lnenad 10mo ago
        But that's not what anyone is arguing here, nor what (to me it seems at least) uncloud is about. It's about simpler HA multinode setup with a single/low double digit containers.
        esseph 10mo ago
        > I’m really not sure why K8S has become the complexity boogeyman. Was what i was responding to. It's not the app management that becomes a pain, it's the cluster management, lifecycle, platform API deprecations, etc.
- mosselman 10mo ago
  You have a graph that shows a multi provider setup for a domain. Where would routing to either machine happen? As in which ip would you use on the dns side?
  - calgoo 10mo ago
    Not OP, but you could do "simple" dns load balancing between both endpoints.
    - 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 Cloudflare DNS proxy would handle this.
  - 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 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.
    - snthpy 10mo ago
      I looked into this yesterday for making Caddy HA on my Proxmox cluster and stumbled upon keepalivd. It will provide you with a virtual IP and failover but not load balancing so you'd need to still point that at something like HAProxy for that. Could be something interesting to integrate though.
- woile 10mo ago
  does it support ipv6?
  - psviderski 10mo ago
    There is an open issue that confirms enabling ipv6 for containers works: https://github.com/psviderski/uncloud/issues/126 https://github.com/psviderski/uncloud/issues/126 But this hasn’t been enabled by default. What specifically do you mean by ipv6 support?
    - miyuru 10mo ago
      > What specifically do you mean by ipv6 support? This question does not make sense. This is equivalent to asking "What specifically do you mean by ipv4 support" These days both protocols must be supported, and if there is a blocker it should be clearly mentioned.
      - justincormack 10mo ago
        How do you want to allocate ipv6 addresses to containers? Turns out there are lots of answers. Some people even want to do ipv6 NAT.
        lifty 10mo ago
        A really cool way to do it is how Yggdrasil project does it (https://yggdrasil-network.github.io/implementation.html#how-are-nodes-identified https://yggdrasil-network.github.io/implementation.html#how-...). They basically use public keys as identities and they deterministically create an IPv6 address from the public key. This is beautiful and works for private networks, as well as for their global overlay IPv6 network. What do you think about the general approach in Uncloud? It almost feels like a cousin of Swarm. Would love to get your take on it.
        GoblinSlayer 10mo ago
        Like docker? --fixed-cidr-v6=2001:db8:1::/64
- zbuttram 10mo ago
  Very cool! I think I'll have some opportunity soon to give it a shot, I have just the set of projects that have been needing a tool like this. One thing I think I'm missing after perusing the docs however is, how does one onboard other engineers to the cluster after it has been set up? And similarly, how does deployment from a CI/CD runner work? I don't see anything about how to connect to an existing cluster from a new machine, or at least not that I'm recognizing.
  - jabr 10mo ago
    There isn't a cli function for adding a connection (independently of adding a new machine/node) yet, but they are in a simple config file (`~/.config/uncloud/config.yaml`) that you can copy or easily create manually for now. It looks like this: current_context: default contexts: default: connections: - ssh: admin@192.168.0.10 ssh_key_file: ~/.ssh/uncloud - ssh: admin@192.168.0.11 ssh_key_file: ~/.ssh/uncloud - ssh: administrator@93.x.x.x ssh_key_file: ~/.ssh/uncloud - ssh: sysadmin@65.x.x.x ssh_key_file: ~/.ssh/uncloud And you really just need one entry for typical use. The subsequent entries are only used if the previous node(s) are down.
    - psviderski 10mo ago
      For CI/CD, check out this GitHub Action: https://github.com/thatskyapplication/uncloud-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
- utopiah 10mo ago
  Neat, as you include quite a few tool for services to be reachable together (not necessarily to the outside), do you also have tooling to make those services more interoperable?
  - jabr 10mo ago
    Do you have an example of what you mean? I'm not entirely clear on your question.
    - utopiah 10mo ago
      Sure, let's imagine image I get Jitsi Meet and CopyParty running via uncloud, is there a way to e.g save Jitsi Meet chat log of a session to CopyParty?
- unixfox 10mo ago
  Awesome tool! Does it provide some basic features that you would get from running a control plane. Like rescheduling automatically a container on another server if a server is down? Deploying on the less filled server first if you have set limits in your containers?
  - 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 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-for-process-groups-without-services 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.
- avan1 10mo ago
  Thanks for the both great tools. just i didn't understand one thing ? the request flow, imaging we have 10 servers where we choose this request goes to server 1 and the other goes to 7 for example. and since its zero down time, how it says server 5 is updating so till it gets up no request should go there.
  - 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. 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.
- doctorpangloss 10mo ago
  haha, uncloud does have a control plane: the mind of the person running "uc" CLI commands > I’m building Uncloud after years of managing Kubernetes did you manage Kubernetes, or did you make the fateful mistake of managing microk8s?
- oulipo2 10mo ago
  So it's a kind of better Docker Swarm? It's interesting, but honestly I'd rather have something declarative, so I can use it with Pulumi, would it be complicated to add a declarative engine on top of the tool? Which discovers what services are already up, do a diff with the new declaration, and handles changes?
  - 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 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 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.
    - snthpy 10mo ago
      That's really interesting and cool. In that case calling it imperative rather than declarative is underselling it imho. I haven't worked that much with Terraform but in my usage from the cli, that is how it works too and I consider that declarative. I get that putting the declarative spec in the control plane and having the service autoreconcile continuously is another layer but this is great as a start. 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?
      - jabr 10mo ago
        > In fact could you not just cron the cli deployment command on the nodes and get an effective poor man's declarative layer In the project discord, a user recently experimented with a custom setup that sounds very similar to what you describe. In fact, a big part of uncloud’s appeal to me is that it also provides powerful building blocks for more complex, custom systems like this, not just the streamlined workflow for simpler, standard cases.
- tex0 10mo ago
  This is a cool tool, I like the idea. But the way `uc machine init` works under the hood is really scary. Lot's of `curl | bash` run as root. While I would love to test this tool, this is not something I would run on any machine :/
  - redrove 10mo ago
    +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/ebd4622592bcecedbc51ad653513d91f43ef124e/internal/cli/machine.go#L45 https://github.com/psviderski/uncloud/blob/ebd4622592bcecedb...
  - 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.
  - tontony 10mo ago
    Curious, what would be an ideal (secure) approach for you to install this (or similar) tool?
    - rovr138 10mo ago
      It's deploying a script, which then downloads uncloud using curl. The alternative is, deploying the script and with it have the uncloud files it needs.
    - yabones 10mo ago
      The correct way would be to publish packages on a proper registry/repository and install them with a package manager. For example, create a 3rd party Debian repository, and import the config & signing key on install. It's more work, sure, but it's been the best practice for decades and I don't see that changing any time soon.
- Glemkloksdjf 10mo ago
  So you build an insecure version of nomad/kubernetes and co? If you do anything professional, you better choose proven software like kubernetes or managed kubernetes or whatever else all the hyperscalers provide. And the complexity you are solving now or have to solve, k8s solved. IaC for example, Cloud Provider Support for provisioning a LB out of the box, cert-manager, all the helm charts for observability, logging, a ecosystem to fall back to (operators), ArgoCD <3, storage provisioning, proper high availability, kind for e2e testing on cicd, etc. I'm also aways lost why people think k8s is so hard to operate. Just take a managed k8s. There are so many options out there and they are all compatible with the whole k8s ecosystem. Look if you don't get kubernetes, its use casees, advantages etc. fine absolutly fine but your solution is not an alternative to k8s. Its another container orchestrator like nomad and k8s and co. with it own advantages and disadvantages.
  - mgaunard 10mo ago
    Those are all sub-par cloud technologies which perform very badly and do not scale at all. Some people would rather build their own solutions to do these things with fine-grain control and the ability to handle workloads more complex that a shopping cart website.
    - Glemkloksdjf 10mo ago
      [dead]
    - RyanHamilton 10mo ago
      I've tried to refrain from commenting but your comment pushed me over the edge. I either want to dismiss your comment as ignorant that amazon is just a shopping cart or ignorant that you even need cloud technologies until you have 1000s of customers. But I must concede there's a chance you fall in that middle area and I'm wrong. It's < 5 percent. But yeah sure.. we have a scale problem and you're right you've identified the nonsense cloud technologies that won't fix it. I'm glad you chimed in to convince us but to build our own for 5000 customers.
      - 10mo ago
- 11mariom 10mo ago
  > - uses the familiar Docker Compose spec, no new DSL to learn But this goes with assumption that one already know docker compose spec. For exact same reason I'm in love for `podman kube play` to just use k8s manifests to quickly test run on local machine - and not bother with some "legacy" compose. (I never liked Docker Inc. so I never learned THEIR tooling, it's not needed to build/run containers)
  - TingPing 10mo ago
    podman-compose works fine. It’s a very simple format.
- sam-cop-vimes 10mo ago
  I really like what is on offer here - thank you for building it. Re the private network it builds with Wireguard, how are services running within this private network supposed to access AWS services such as RDS securely? Tailscale has this: https://tailscale.com/kb/1141/aws-rds https://tailscale.com/kb/1141/aws-rds
  - 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 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.
- knowitnone3 10mo ago
  but if they already know how to use k8s, then they should use it. Now they have to know k8s AND know this tool?
- INTPenis 10mo ago
  We have similar backgrounds, and I totally agree with your k8s sentiment. But I wonder what this solves? Because I stopped abusing k8s and started using more container hosts with quadlets instead, using Ansible or Terraform depending on what the situation calls for. It works just fine imho. The CI/CD pipeline triggers a podman auto-update command, and just like that all containers are running the latest version. So what does uncloud add to this setup?
  - lifty 10mo ago
    Uncloud seems much easier to manage than writing your own ansible or terraform.
  - 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-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.
    - INTPenis 10mo ago
      It's starting to sound a lot like k8s to me. :D Technically I could allow my web proxy to discover my services today already, but I refuse to have Traefik (in my case) running as the same user as my services. I prefer to only let them talk over TCP/IP and configure them dynamically with Ansible instead. It always amazed me that people used that feature in Traefik or Caddy, because it essentially requires your web proxy to have container access to all your other services. It seems a bit intimate to me, but maybe I'm old school.
- snthpy 10mo ago
  Wow, this sounds very cool. I share the same concern as top comments on security but going to check out out in more detail. I wonder if you integrated some decentralized identity layer with DIDs, if this could be turned into some distributed compute platform? Also, what is your thinking on high availability and fail failovers?
nake89 10mo ago
How does this compare to k3s?
- tontony 10mo ago
  Uncloud is not a Kubernetes distribution and doesn't use K8s primitives (although there are of course some similarities). It's closer to Compose/Swarm in how you declare and manage your services. Which has pros and cons depending on what you need and what your (or your team's) experience with Kubernetes is.
JohnMakin 10mo ago
Having spent most of my career in kubernetes (usually managed by cloud), I always wonder when I see things like this, what is the use case or benefit of not having a control plane? To me, the control plane is the primary feature of kubernetes and one I would not want to go without. I know this describes operational overhead as a reason, but how it relates to the control plane is not clear to me. even managing a few hundred nodes and maybe 10,000 containers, relatively small - I update once a year and the managed cluster updates machine images and versions automatically. Are people trying to self host kubernetes for production cases, and that’s where this pain comes from? Sorry if it is a rude question.
- baq 10mo ago
  > Are people trying to self host kubernetes Of course they are…? That’s half the point of k8s - if you want to self host, you can, but it’s just like backups: if you never try it, you should assume you can’t do it when you need to
- 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 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.
  - _joel 10mo ago
    k3s uses sqlite, so not etcd.
    - 10mo ago
fuckinpuppers 10mo ago
Does it support a way to bundle things close to each other, for example, not having a database container hosted in a different datacenter than the web app?
- jabr 10mo ago
  The `compose.yaml` spec for services let's you specify which machines to deploy it on, so you could target the database and web app to the same machine (or subset of machines). There is also an internal DNS for service discovery and it supports a `nearest.` prefix, which will preferentially use instances of a service running on the same machine. For example, I run a globally replicated NATS service and then connect to it from other services using the `nearest.nats.internal` address to connect to the machine-local NATS node.
stevefan1999 10mo ago
If not K8S, why not Nomad (https://github.com/hashicorp/nomad https://github.com/hashicorp/nomad)?
- m1keil 10mo ago
  Nomad is great, but you will still end up with a control plane.
  - sgt 10mo ago
    Isn't Nomad pretty much dead now?
    - m1keil 10mo ago
      They had quite a few release in the last year so it's not dead that's for sure, but unclear how many new customers they are able to sign up. And with IBM in charge, it's also unclear at what moment they will loose interest.
- tontony 10mo ago
  Nomad still has a tangible learning curve, which (in my very biased opinion) is almost non-existent with Uncloud assuming the user has already heard about Docker and Compose.
- weitendorf 10mo ago
  Their license does not allow you to modify it and then offer it as a service to others: https://github.com/hashicorp/nomad/blob/main/LICENSE https://github.com/hashicorp/nomad/blob/main/LICENSE You can't really do anything with it except work for Hashicorp for free, or create a fork that nobody is allowed to use unless they self-host it.
  - stevefan1999 10mo ago
    well you can always fork the version before the license change
m1keil 10mo ago
Looks lovely.. I'll definitely will give it a try when time comes.
sergioisidoro 10mo ago
This is extremely interesting to me. I've been using docker swarm, but there is this growing feeling of staleness. Dokku feels a bit too light, K8 absolutely too heavy. This proposition strikes my sweet spot - especially the part where I keep my existing docker compose declarations
- psviderski 10mo ago
  Come join our cozy Discord server https://uncloud.run/discord 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/feat%2Funcloud/uncloud https://github.com/dasunsrule32/docker-compose-configs/tree/...
- josegonzalez 10mo ago
  Dokku Maintainer here. Would love to hear about what you think is "light" about Dokku if you have some time for feedback. Regardless, hope you find a tool you're happy with :)
deleted 10mo ago
[deleted]
scottydelta 10mo ago
As a happy user of coolify, what’s the difference between these two? Even coolify lets you add as many machines as you want and then manage docker containers in all machines from one coolify installation.
- lillecarl 10mo ago
  Vendor lock-in, Kubernetes is future proof.
  - rc_mob 10mo ago
    No we're looking for comparisons of coolify vs uncloud
- 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 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.
throwaway77385 10mo ago
How does this compare to something like Dokku?
- Cwizard 10mo ago
  Is dokku multi node?
  - throwaway77385 10mo ago
    It supports docker swarm, but I've never used it like that. As I may need multi node in the future, I was asking the question to see if it would make it 'easy' to orchestrate multiple containers. The simplicity of Dokku is hard to beat, however. edit: Well, it would appear that the very maintainer of Dokku himself replied to the parent comment. My information is clearly outdated and I'd only look at this comment[0] to get the proper info. [0] https://news.ycombinator.com/item?id=46144275#46145919 https://news.ycombinator.com/item?id=46144275#46145919
  - josegonzalez 10mo ago
    Dokku is multi node. It supports docker-local (single node) and k3s (multi-node) as schedulers, with most features implemented as expected when deploying to k3s.
apexalpha 10mo ago
Wow this looks really cool. Congratulations!
oulipo2 10mo ago
I'm using Dokploy, would that be very similar, or quite different?
- 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'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 https://uncloud.run/docs/guides/deployments/deploy-app
nextchainxio 10mo ago
[dead]
raw_anon_1111 10mo ago
I know just enough about Kubernetes to not sound like an idiot when I’m in the room and mostly I deploy Docker containers to various managed services on AWS - Lambda, ECS, etc. But, as a lead for implementations, I just couldn’t in good conscience permit something that is not an industry standard and not supported by my cloud provider. First from a self interested standpoint, it looks a lot better on their resume to say “I did $x using K8s”. From an onboarding standpoint, just telling a new employee “we use K8s -here you go” means nothing new to learn. If you are part of the industry, just suck it up and learn Kubernetes. Your future self won’t regret it - coming from someone who in fact has not learn K8s. This is a challenge any new framework is going to have.
- 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 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.
  - raw_anon_1111 10mo ago
    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.
indigodaddy 10mo ago
Very cool, so sort of like Dokku but simpler/easier to use? Looks like the docs assume the management of a single cluster. What if you want to manage multiple/distinct clusters from the same uc client/management env?
- tontony 10mo ago
  > What if you want to manage multiple/distinct clusters Uncloud supports having multiple contexts (think - clusters) in the same configuration file, or you can also use separate config files (via --uncloud-config attribute). https://uncloud.run/docs/cli-reference/uc_ctx https://uncloud.run/docs/cli-reference/uc_ctx
HisNameIsTor 10mo ago
Very nice! This would have been my choice had it existed three months ago. Now it feels like I learned kubernetes in vain xD
- 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
sigmonsays 10mo ago
really need to disclose the status of this application. It's ridiculous to pipe curl | bash in the actual code. Gonna burn bridges with this lack of transparency. I love the intent but the implementation is so bad that I probably wont look back.
chuckadams 10mo ago
I'm pretty happy with k3s, but I'm also happy to see some development happening in the space between docker compose and full-blown kubernetes. The wireguard integration in particular intrigues me.
raphinou 10mo ago
I'm a docker swarm user, and this is the first alternative that looks interesting to me! Some questions I have based on my swarm usage: - do you plan to support secrets? - with swarm and traefik, I can define url rewrite rules as container labels. Is something equivalent available? - if I deploy 2 compose 'stacks', do all containers have access to all other containers, even in the other stack?
- tontony 10mo ago
  Secrets -- yes, it's being tracked here: https://github.com/psviderski/uncloud/issues/75 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 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"?
  - raphinou 10mo ago
    Swarm is not far from my dream deploy solution, but here are some points that might be better, some of them being already better in uncloud I think: - energy in the community is low, it's hard to find an active discussion channel of swarm users - swarm does not support the complete compose file format. This is really annoying - sometimes, deploys fail for unclear reasons (eg a network was not found, but why as it's defined in the compose file?) and work the next try. This is never lead to problems, but doesn't feel right - working with authenticate/custom registries is somewhat cumbersome - having to work with registries to have the same image deployed on all nodes is sometimes annoying. It could be cool to have images spreading across nodes. - there's no contact between devs and users. I've just discovered uncloud and I've had more contact with its devs here than in years of using swarm! - the firewalling is not always clear/clean - logs accessibility (service vs container) and containers identification: when a container fails to start, it's sometimes harder than needed to debug (esp when it is because the image is not available)
wg0 10mo ago
This look really neat and great! Amazing job! BTW just looking at other variations on the theme: - https://dokploy.com/ https://dokploy.com/ - https://coolify.io/ https://coolify.io/ - https://demo.kubero.dev/ https://demo.kubero.dev/ Feel free to add more.
- dewey 10mo ago
  There's a good list here: https://dbohdan.com/self-hosted-paas https://dbohdan.com/self-hosted-paas I'm always looking for new alternatives there, I've recently tried Coolify but it didn't feel very polished and mostly clunky. I'm still happy with Dokku at this point but would love to have a better UI for managing databases etc.
  - wg0 10mo ago
    Okay could you please share your thoughts as a user: - What databases you want to work with? - What functionality you want from such a UI? - What database size we are talking here? Asking because I am tinkering with a similar idea.
    - dewey 10mo ago
      Thanks for asking. I think one barrier with self-hosting is still that setting up a database isn't as easy as on DigitalOcean / Supabase. I'm an experienced self-hoster but running my own database still sometimes makes me a bit anxious as I have to set up scripts to do backups, set up scripts to see if my backups are being done correctly, set up metrics to see backups sizes, database sizes etc. I just wrote this up here, in case someone else can point me to an existing project I'm not aware of: https://blog.notmyhostna.me/posts/what-i-wish-existed-for-self-hosted-databases https://blog.notmyhostna.me/posts/what-i-wish-existed-for-se...
DeathArrow 10mo ago
Does Uncloud have auto scaling?
- 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 https://news.ycombinator.com/item?id=46146434
vanillax 10mo ago
Kubernetes is not hard. Taking the time to read the manual seems to be hard for most people.
Ey7NFZ3P0nzAe 10mo ago
Linking 2 interesting p2p building blocks just in case: https://github.com/mudler/edgevpn https://github.com/mudler/edgevpn https://www.iroh.computer/ https://www.iroh.computer/
strzibny 10mo ago
I think this is pretty cool. Congrats on the project, might play with it later. If you want something even simpler, something that doesn't run on your servers at all, you can look at Kamal: https://kamal-deploy.org https://kamal-deploy.org What I like about Kamal is that it's backed by a company that actually fully moved out of K8s and cloud, so every release is battle-tested first.
nrki 10mo ago
Very neat tool. Thank you for your efforts! I am wondering how state replication works on the backend. The design mentions using crdt and a gossip proto, but I'm not sure what is actually implemented as it is a tad vague. I haven't dug into the code so forgive me if it is obvious or explained elsewhere.
- jabr 10mo ago
  State replication is currently based on corrosion: https://github.com/superfly/corrosion https://github.com/superfly/corrosion
Nelkins 10mo ago
Does this do any level of server hardening for you when you point it at a server?
c0_0p_ 10mo ago
Very cool, I have spent the past week cobbling together something very similar from docker swarm and tailscale but something all in one would be amazing.

403 points by rgun 10mo ago

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 other project unregistry [1]) - imperative CLI (like Docker) rather than declarative reconciliation. Easier mental model and debugging - works across cloud VMs, bare metal, even a Raspberry Pi at home behind NAT (all connected together) - minimal resource footprint (<150MB ram) [0]: https://github.com/psviderski/uncloud https://github.com/psviderski/uncloud [1]: https://github.com/psviderski/unregistry https://github.com/psviderski/unregistry

olegp 10mo ago
How's this similar to and different from Kamal? https://kamal-deploy.org/ https://kamal-deploy.org/
- psviderski 10mo ago
  I took some inspiration from Kamal, e.g. the imperative model but kamal is more a deployment tool. In addition to deployments, uncloud handles clustering - connects machines and containers together. Service containers can discover other services via internal DNS and communicate directly over the secure overlay network without opening any ports on the hosts. As far as I know kamal doesn’t provide an easy way for services to communicate across machines. Services can also be scaled to multiple replicas across machines.
  - olegp 10mo ago
    Thanks! I noticed afterwards that you mention Kamal in your readme, but you may want to add a comparison section that you link to where you compare your solution to others. Are you working on this full time and if so, how are you funding it? Are you looking to monetize this somehow?
    - 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 managing remote clusters and apps on them with value-added PaaS-like features.
      - olegp 10mo ago
        That sounds interesting, maybe I could help on the business side of things somehow. I'll email you my calendar link.
        psviderski 10mo ago
        Awesome, will reach out!
  - cpursley 10mo ago
    This is neat, regarding clustering - can this work with distributed erlang/elixir?
    - 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.
    - jabr 10mo ago
topspin 10mo ago
"I keep seeing teams reach for K8s when they really just need to run a bunch of containers across a few machines" Since k8s is very effective at running a bunch of containers across a few machines, it would appear to be exactly the correct thing to reach for. At this point, running a small k8s operation, with k3s or similar, has become so easy that I can't find a rational reason to look elsewhere for container "orchestration".
- nullpoint420 10mo ago
  100%. I’m really not sure why K8S has become the complexity boogeyman. I’ve seen CDK apps or docker compose files that are way more difficult to understand than the equivalent K8S manifests.
  - esseph 10mo ago
    Managing hundreds or thousands of containers across hundreds or thousands of k8s nodes has a lot of operational challenges. Especially in-house on bare metal.
    - sceptic123 10mo ago
      I don't think that argument matches with they "just need to run a bunch of containers across a few machines"
    - lnenad 10mo ago
      But that's not what anyone is arguing here, nor what (to me it seems at least) uncloud is about. It's about simpler HA multinode setup with a single/low double digit containers.
      - esseph 10mo ago
        > I’m really not sure why K8S has become the complexity boogeyman. Was what i was responding to. It's not the app management that becomes a pain, it's the cluster management, lifecycle, platform API deprecations, etc.
mosselman 10mo ago
You have a graph that shows a multi provider setup for a domain. Where would routing to either machine happen? As in which ip would you use on the dns side?
- calgoo 10mo ago
  Not OP, but you could do "simple" dns load balancing between both endpoints.
  - 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 Cloudflare DNS proxy would handle this.
- 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 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.
  - snthpy 10mo ago
    I looked into this yesterday for making Caddy HA on my Proxmox cluster and stumbled upon keepalivd. It will provide you with a virtual IP and failover but not load balancing so you'd need to still point that at something like HAProxy for that. Could be something interesting to integrate though.
woile 10mo ago
does it support ipv6?
- psviderski 10mo ago
  There is an open issue that confirms enabling ipv6 for containers works: https://github.com/psviderski/uncloud/issues/126 https://github.com/psviderski/uncloud/issues/126 But this hasn’t been enabled by default. What specifically do you mean by ipv6 support?
  - miyuru 10mo ago
    > What specifically do you mean by ipv6 support? This question does not make sense. This is equivalent to asking "What specifically do you mean by ipv4 support" These days both protocols must be supported, and if there is a blocker it should be clearly mentioned.
    - justincormack 10mo ago
      How do you want to allocate ipv6 addresses to containers? Turns out there are lots of answers. Some people even want to do ipv6 NAT.
      - lifty 10mo ago
        A really cool way to do it is how Yggdrasil project does it (https://yggdrasil-network.github.io/implementation.html#how-are-nodes-identified https://yggdrasil-network.github.io/implementation.html#how-...). They basically use public keys as identities and they deterministically create an IPv6 address from the public key. This is beautiful and works for private networks, as well as for their global overlay IPv6 network. What do you think about the general approach in Uncloud? It almost feels like a cousin of Swarm. Would love to get your take on it.
      - GoblinSlayer 10mo ago
        Like docker? --fixed-cidr-v6=2001:db8:1::/64
zbuttram 10mo ago
Very cool! I think I'll have some opportunity soon to give it a shot, I have just the set of projects that have been needing a tool like this. One thing I think I'm missing after perusing the docs however is, how does one onboard other engineers to the cluster after it has been set up? And similarly, how does deployment from a CI/CD runner work? I don't see anything about how to connect to an existing cluster from a new machine, or at least not that I'm recognizing.
- jabr 10mo ago
  There isn't a cli function for adding a connection (independently of adding a new machine/node) yet, but they are in a simple config file (`~/.config/uncloud/config.yaml`) that you can copy or easily create manually for now. It looks like this: current_context: default contexts: default: connections: - ssh: admin@192.168.0.10 ssh_key_file: ~/.ssh/uncloud - ssh: admin@192.168.0.11 ssh_key_file: ~/.ssh/uncloud - ssh: administrator@93.x.x.x ssh_key_file: ~/.ssh/uncloud - ssh: sysadmin@65.x.x.x ssh_key_file: ~/.ssh/uncloud And you really just need one entry for typical use. The subsequent entries are only used if the previous node(s) are down.
  - psviderski 10mo ago
    For CI/CD, check out this GitHub Action: https://github.com/thatskyapplication/uncloud-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
utopiah 10mo ago
Neat, as you include quite a few tool for services to be reachable together (not necessarily to the outside), do you also have tooling to make those services more interoperable?
- jabr 10mo ago
  Do you have an example of what you mean? I'm not entirely clear on your question.
  - utopiah 10mo ago
    Sure, let's imagine image I get Jitsi Meet and CopyParty running via uncloud, is there a way to e.g save Jitsi Meet chat log of a session to CopyParty?
unixfox 10mo ago
Awesome tool! Does it provide some basic features that you would get from running a control plane. Like rescheduling automatically a container on another server if a server is down? Deploying on the less filled server first if you have set limits in your containers?
- 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 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-for-process-groups-without-services 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.
avan1 10mo ago
Thanks for the both great tools. just i didn't understand one thing ? the request flow, imaging we have 10 servers where we choose this request goes to server 1 and the other goes to 7 for example. and since its zero down time, how it says server 5 is updating so till it gets up no request should go there.
- 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. 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.
doctorpangloss 10mo ago
haha, uncloud does have a control plane: the mind of the person running "uc" CLI commands > I’m building Uncloud after years of managing Kubernetes did you manage Kubernetes, or did you make the fateful mistake of managing microk8s?
oulipo2 10mo ago
So it's a kind of better Docker Swarm? It's interesting, but honestly I'd rather have something declarative, so I can use it with Pulumi, would it be complicated to add a declarative engine on top of the tool? Which discovers what services are already up, do a diff with the new declaration, and handles changes?
- 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 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 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.
  - snthpy 10mo ago
    That's really interesting and cool. In that case calling it imperative rather than declarative is underselling it imho. I haven't worked that much with Terraform but in my usage from the cli, that is how it works too and I consider that declarative. I get that putting the declarative spec in the control plane and having the service autoreconcile continuously is another layer but this is great as a start. 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?
    - jabr 10mo ago
      > In fact could you not just cron the cli deployment command on the nodes and get an effective poor man's declarative layer In the project discord, a user recently experimented with a custom setup that sounds very similar to what you describe. In fact, a big part of uncloud’s appeal to me is that it also provides powerful building blocks for more complex, custom systems like this, not just the streamlined workflow for simpler, standard cases.
tex0 10mo ago
This is a cool tool, I like the idea. But the way `uc machine init` works under the hood is really scary. Lot's of `curl | bash` run as root. While I would love to test this tool, this is not something I would run on any machine :/
- redrove 10mo ago
  +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/ebd4622592bcecedbc51ad653513d91f43ef124e/internal/cli/machine.go#L45 https://github.com/psviderski/uncloud/blob/ebd4622592bcecedb...
- 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.
- tontony 10mo ago
  Curious, what would be an ideal (secure) approach for you to install this (or similar) tool?
  - rovr138 10mo ago
    It's deploying a script, which then downloads uncloud using curl. The alternative is, deploying the script and with it have the uncloud files it needs.
  - yabones 10mo ago
    The correct way would be to publish packages on a proper registry/repository and install them with a package manager. For example, create a 3rd party Debian repository, and import the config & signing key on install. It's more work, sure, but it's been the best practice for decades and I don't see that changing any time soon.
Glemkloksdjf 10mo ago
So you build an insecure version of nomad/kubernetes and co? If you do anything professional, you better choose proven software like kubernetes or managed kubernetes or whatever else all the hyperscalers provide. And the complexity you are solving now or have to solve, k8s solved. IaC for example, Cloud Provider Support for provisioning a LB out of the box, cert-manager, all the helm charts for observability, logging, a ecosystem to fall back to (operators), ArgoCD <3, storage provisioning, proper high availability, kind for e2e testing on cicd, etc. I'm also aways lost why people think k8s is so hard to operate. Just take a managed k8s. There are so many options out there and they are all compatible with the whole k8s ecosystem. Look if you don't get kubernetes, its use casees, advantages etc. fine absolutly fine but your solution is not an alternative to k8s. Its another container orchestrator like nomad and k8s and co. with it own advantages and disadvantages.
- mgaunard 10mo ago
  Those are all sub-par cloud technologies which perform very badly and do not scale at all. Some people would rather build their own solutions to do these things with fine-grain control and the ability to handle workloads more complex that a shopping cart website.
  - Glemkloksdjf 10mo ago
    [dead]
  - RyanHamilton 10mo ago
    I've tried to refrain from commenting but your comment pushed me over the edge. I either want to dismiss your comment as ignorant that amazon is just a shopping cart or ignorant that you even need cloud technologies until you have 1000s of customers. But I must concede there's a chance you fall in that middle area and I'm wrong. It's < 5 percent. But yeah sure.. we have a scale problem and you're right you've identified the nonsense cloud technologies that won't fix it. I'm glad you chimed in to convince us but to build our own for 5000 customers.
    - 10mo ago
11mariom 10mo ago
> - uses the familiar Docker Compose spec, no new DSL to learn But this goes with assumption that one already know docker compose spec. For exact same reason I'm in love for `podman kube play` to just use k8s manifests to quickly test run on local machine - and not bother with some "legacy" compose. (I never liked Docker Inc. so I never learned THEIR tooling, it's not needed to build/run containers)
- TingPing 10mo ago
  podman-compose works fine. It’s a very simple format.
sam-cop-vimes 10mo ago
I really like what is on offer here - thank you for building it. Re the private network it builds with Wireguard, how are services running within this private network supposed to access AWS services such as RDS securely? Tailscale has this: https://tailscale.com/kb/1141/aws-rds https://tailscale.com/kb/1141/aws-rds
- 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 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.
knowitnone3 10mo ago
but if they already know how to use k8s, then they should use it. Now they have to know k8s AND know this tool?
INTPenis 10mo ago
We have similar backgrounds, and I totally agree with your k8s sentiment. But I wonder what this solves? Because I stopped abusing k8s and started using more container hosts with quadlets instead, using Ansible or Terraform depending on what the situation calls for. It works just fine imho. The CI/CD pipeline triggers a podman auto-update command, and just like that all containers are running the latest version. So what does uncloud add to this setup?
- lifty 10mo ago
  Uncloud seems much easier to manage than writing your own ansible or terraform.
- 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-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.
  - INTPenis 10mo ago
    It's starting to sound a lot like k8s to me. :D Technically I could allow my web proxy to discover my services today already, but I refuse to have Traefik (in my case) running as the same user as my services. I prefer to only let them talk over TCP/IP and configure them dynamically with Ansible instead. It always amazed me that people used that feature in Traefik or Caddy, because it essentially requires your web proxy to have container access to all your other services. It seems a bit intimate to me, but maybe I'm old school.
snthpy 10mo ago
Wow, this sounds very cool. I share the same concern as top comments on security but going to check out out in more detail. I wonder if you integrated some decentralized identity layer with DIDs, if this could be turned into some distributed compute platform? Also, what is your thinking on high availability and fail failovers?

nake89 10mo ago

How does this compare to k3s?

tontony 10mo ago
Uncloud is not a Kubernetes distribution and doesn't use K8s primitives (although there are of course some similarities). It's closer to Compose/Swarm in how you declare and manage your services. Which has pros and cons depending on what you need and what your (or your team's) experience with Kubernetes is.

JohnMakin 10mo ago

Having spent most of my career in kubernetes (usually managed by cloud), I always wonder when I see things like this, what is the use case or benefit of not having a control plane? To me, the control plane is the primary feature of kubernetes and one I would not want to go without. I know this describes operational overhead as a reason, but how it relates to the control plane is not clear to me. even managing a few hundred nodes and maybe 10,000 containers, relatively small - I update once a year and the managed cluster updates machine images and versions automatically. Are people trying to self host kubernetes for production cases, and that’s where this pain comes from? Sorry if it is a rude question.

baq 10mo ago
> Are people trying to self host kubernetes Of course they are…? That’s half the point of k8s - if you want to self host, you can, but it’s just like backups: if you never try it, you should assume you can’t do it when you need to
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 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.
- _joel 10mo ago
  k3s uses sqlite, so not etcd.
  - 10mo ago

fuckinpuppers 10mo ago

Does it support a way to bundle things close to each other, for example, not having a database container hosted in a different datacenter than the web app?

jabr 10mo ago
The `compose.yaml` spec for services let's you specify which machines to deploy it on, so you could target the database and web app to the same machine (or subset of machines). There is also an internal DNS for service discovery and it supports a `nearest.` prefix, which will preferentially use instances of a service running on the same machine. For example, I run a globally replicated NATS service and then connect to it from other services using the `nearest.nats.internal` address to connect to the machine-local NATS node.

stevefan1999 10mo ago

If not K8S, why not Nomad (https://github.com/hashicorp/nomad https://github.com/hashicorp/nomad)?

m1keil 10mo ago
Nomad is great, but you will still end up with a control plane.
- sgt 10mo ago
  Isn't Nomad pretty much dead now?
  - m1keil 10mo ago
    They had quite a few release in the last year so it's not dead that's for sure, but unclear how many new customers they are able to sign up. And with IBM in charge, it's also unclear at what moment they will loose interest.
tontony 10mo ago
Nomad still has a tangible learning curve, which (in my very biased opinion) is almost non-existent with Uncloud assuming the user has already heard about Docker and Compose.
weitendorf 10mo ago
Their license does not allow you to modify it and then offer it as a service to others: https://github.com/hashicorp/nomad/blob/main/LICENSE https://github.com/hashicorp/nomad/blob/main/LICENSE You can't really do anything with it except work for Hashicorp for free, or create a fork that nobody is allowed to use unless they self-host it.
- stevefan1999 10mo ago
  well you can always fork the version before the license change

m1keil 10mo ago

Looks lovely.. I'll definitely will give it a try when time comes.

sergioisidoro 10mo ago

This is extremely interesting to me. I've been using docker swarm, but there is this growing feeling of staleness. Dokku feels a bit too light, K8 absolutely too heavy. This proposition strikes my sweet spot - especially the part where I keep my existing docker compose declarations

psviderski 10mo ago
Come join our cozy Discord server https://uncloud.run/discord 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/feat%2Funcloud/uncloud https://github.com/dasunsrule32/docker-compose-configs/tree/...
josegonzalez 10mo ago
Dokku Maintainer here. Would love to hear about what you think is "light" about Dokku if you have some time for feedback. Regardless, hope you find a tool you're happy with :)

deleted 10mo ago

[deleted]

scottydelta 10mo ago

As a happy user of coolify, what’s the difference between these two? Even coolify lets you add as many machines as you want and then manage docker containers in all machines from one coolify installation.

lillecarl 10mo ago
Vendor lock-in, Kubernetes is future proof.
- rc_mob 10mo ago
  No we're looking for comparisons of coolify vs uncloud
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 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.

throwaway77385 10mo ago

How does this compare to something like Dokku?

Cwizard 10mo ago
Is dokku multi node?
- throwaway77385 10mo ago
  It supports docker swarm, but I've never used it like that. As I may need multi node in the future, I was asking the question to see if it would make it 'easy' to orchestrate multiple containers. The simplicity of Dokku is hard to beat, however. edit: Well, it would appear that the very maintainer of Dokku himself replied to the parent comment. My information is clearly outdated and I'd only look at this comment[0] to get the proper info. [0] https://news.ycombinator.com/item?id=46144275#46145919 https://news.ycombinator.com/item?id=46144275#46145919
- josegonzalez 10mo ago
  Dokku is multi node. It supports docker-local (single node) and k3s (multi-node) as schedulers, with most features implemented as expected when deploying to k3s.

apexalpha 10mo ago

Wow this looks really cool. Congratulations!

oulipo2 10mo ago

I'm using Dokploy, would that be very similar, or quite different?

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'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 https://uncloud.run/docs/guides/deployments/deploy-app

nextchainxio 10mo ago

[dead]

raw_anon_1111 10mo ago

I know just enough about Kubernetes to not sound like an idiot when I’m in the room and mostly I deploy Docker containers to various managed services on AWS - Lambda, ECS, etc. But, as a lead for implementations, I just couldn’t in good conscience permit something that is not an industry standard and not supported by my cloud provider. First from a self interested standpoint, it looks a lot better on their resume to say “I did $x using K8s”. From an onboarding standpoint, just telling a new employee “we use K8s -here you go” means nothing new to learn. If you are part of the industry, just suck it up and learn Kubernetes. Your future self won’t regret it - coming from someone who in fact has not learn K8s. This is a challenge any new framework is going to have.

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 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.
- raw_anon_1111 10mo ago
  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.

indigodaddy 10mo ago

Very cool, so sort of like Dokku but simpler/easier to use? Looks like the docs assume the management of a single cluster. What if you want to manage multiple/distinct clusters from the same uc client/management env?

tontony 10mo ago
> What if you want to manage multiple/distinct clusters Uncloud supports having multiple contexts (think - clusters) in the same configuration file, or you can also use separate config files (via --uncloud-config attribute). https://uncloud.run/docs/cli-reference/uc_ctx https://uncloud.run/docs/cli-reference/uc_ctx

HisNameIsTor 10mo ago

Very nice! This would have been my choice had it existed three months ago. Now it feels like I learned kubernetes in vain xD

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

sigmonsays 10mo ago

really need to disclose the status of this application. It's ridiculous to pipe curl | bash in the actual code. Gonna burn bridges with this lack of transparency. I love the intent but the implementation is so bad that I probably wont look back.

chuckadams 10mo ago

I'm pretty happy with k3s, but I'm also happy to see some development happening in the space between docker compose and full-blown kubernetes. The wireguard integration in particular intrigues me.

raphinou 10mo ago

I'm a docker swarm user, and this is the first alternative that looks interesting to me! Some questions I have based on my swarm usage: - do you plan to support secrets? - with swarm and traefik, I can define url rewrite rules as container labels. Is something equivalent available? - if I deploy 2 compose 'stacks', do all containers have access to all other containers, even in the other stack?

tontony 10mo ago
Secrets -- yes, it's being tracked here: https://github.com/psviderski/uncloud/issues/75 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 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"?
- raphinou 10mo ago
  Swarm is not far from my dream deploy solution, but here are some points that might be better, some of them being already better in uncloud I think: - energy in the community is low, it's hard to find an active discussion channel of swarm users - swarm does not support the complete compose file format. This is really annoying - sometimes, deploys fail for unclear reasons (eg a network was not found, but why as it's defined in the compose file?) and work the next try. This is never lead to problems, but doesn't feel right - working with authenticate/custom registries is somewhat cumbersome - having to work with registries to have the same image deployed on all nodes is sometimes annoying. It could be cool to have images spreading across nodes. - there's no contact between devs and users. I've just discovered uncloud and I've had more contact with its devs here than in years of using swarm! - the firewalling is not always clear/clean - logs accessibility (service vs container) and containers identification: when a container fails to start, it's sometimes harder than needed to debug (esp when it is because the image is not available)

wg0 10mo ago

This look really neat and great! Amazing job! BTW just looking at other variations on the theme: - https://dokploy.com/ https://dokploy.com/ - https://coolify.io/ https://coolify.io/ - https://demo.kubero.dev/ https://demo.kubero.dev/ Feel free to add more.

dewey 10mo ago
There's a good list here: https://dbohdan.com/self-hosted-paas https://dbohdan.com/self-hosted-paas I'm always looking for new alternatives there, I've recently tried Coolify but it didn't feel very polished and mostly clunky. I'm still happy with Dokku at this point but would love to have a better UI for managing databases etc.
- wg0 10mo ago
  Okay could you please share your thoughts as a user: - What databases you want to work with? - What functionality you want from such a UI? - What database size we are talking here? Asking because I am tinkering with a similar idea.
  - dewey 10mo ago
    Thanks for asking. I think one barrier with self-hosting is still that setting up a database isn't as easy as on DigitalOcean / Supabase. I'm an experienced self-hoster but running my own database still sometimes makes me a bit anxious as I have to set up scripts to do backups, set up scripts to see if my backups are being done correctly, set up metrics to see backups sizes, database sizes etc. I just wrote this up here, in case someone else can point me to an existing project I'm not aware of: https://blog.notmyhostna.me/posts/what-i-wish-existed-for-self-hosted-databases https://blog.notmyhostna.me/posts/what-i-wish-existed-for-se...

DeathArrow 10mo ago

Does Uncloud have auto scaling?

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 https://news.ycombinator.com/item?id=46146434

vanillax 10mo ago

Kubernetes is not hard. Taking the time to read the manual seems to be hard for most people.

Ey7NFZ3P0nzAe 10mo ago

Linking 2 interesting p2p building blocks just in case: https://github.com/mudler/edgevpn https://github.com/mudler/edgevpn https://www.iroh.computer/ https://www.iroh.computer/

strzibny 10mo ago

I think this is pretty cool. Congrats on the project, might play with it later. If you want something even simpler, something that doesn't run on your servers at all, you can look at Kamal: https://kamal-deploy.org https://kamal-deploy.org What I like about Kamal is that it's backed by a company that actually fully moved out of K8s and cloud, so every release is battle-tested first.

nrki 10mo ago

Very neat tool. Thank you for your efforts! I am wondering how state replication works on the backend. The design mentions using crdt and a gossip proto, but I'm not sure what is actually implemented as it is a tad vague. I haven't dug into the code so forgive me if it is obvious or explained elsewhere.

jabr 10mo ago
State replication is currently based on corrosion: https://github.com/superfly/corrosion https://github.com/superfly/corrosion

Nelkins 10mo ago

Does this do any level of server hardening for you when you point it at a server?

c0_0p_ 10mo ago

Very cool, I have spent the past week cobbling together something very similar from docker swarm and tailscale but something all in one would be amazing.