You’ve been able to do download/upload progress using the Streams API with fetch for more than seven years now. https://developer.mozilla.org/en-US/docs/Web/API/Streams_API

on the FE?

The streams API exists on the FE, you can pipe an upload or download through a TransformStream to monitor progress

State replication is currently based on corrosion: https://github.com/superfly/corrosion

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

I haven't tried it, but EPMD with DNS discovery should work just fine, and should be similar to this NATS example: https://github.com/psviderski/uncloud-recipes/blob/main/nats...

Basically just configure it with `{service-name}.internal` to find other instances of the service.

There is a `--no-install` flag on both `uc machine init` and `uc machine add` that skips that `curl | bash` install step.

You need to prepare the machine some other way first then, but it's just installing docker and the uncloud service.

I use the `--no-install` option with my own cluster, as I have my own pre-provisioning process that includes some additional setup beyond the docker/uncloud elements.

Do you have an example of what you mean? I'm not entirely clear on your question.

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?

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.

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.

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

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

uc --connect user@host deploy

I can only speak for myself, but I considered a few options, including "simple k8s" like [Skate](https://skateco.github.io/), and ultimately decided to build on uncloud.

It was as much personal "taste" than anything, and I would describe the choice as similar to preferring JSON over XML.

For whatever reason, kubernetes just irritates me. I find it unpleasant to use. And I don't think I'm unique in that regard.

> For whatever reason, kubernetes just irritates me. I find it unpleasant to use. And I don't think I'm unique in that regard.

I feel the same. I feel like it's a me problem. I was able to build and run massive systems at scale and never used kubernetes. Then, all of a sudden, around 2020, any time I wanted to build or run or do anything at scale, everywhere said I should just use kubernetes. And then when I wanted to do anything with docker in production, not even at scale, everywhere said I should just use kubernetes.

Then there was a brief period around 2021 where everyone - even kubernetes fans - realised it was being used everywhere, even when it didn't need to be. "You don't need k8s" became a meme.

And now, here we are, again, lots of people saying "just use k8s for everything".

I've learned it enough to know how to use it and what I can do with it. I still prefer to use literally anything else apart from k8s when building, and the only time I've ever felt k8s has been really needed to solve a problem is when the business has said "we're using k8s, deal with it".

It's like the Javascript or WordPress of the infrastructure engineering world - it became the lazy answer, IMO. Or the me problem angle: I'm just an aged engineer moaning at having to learn new solutions to old problems.

It’s a nice portable target, with very well defined interfaces. It’s easy to start with and pretty easy to manage if you don’t try to abuse it.

I mean the real answer it is got easily to deploy k8s so the justification for not using it kinda vanished.

How many flawless, painless major version upgrades have you had with literally any flavor of k8s? Because in my experience, that’s always a science experiment that results in such pain people end up just sticking at their original deployed version while praying they don’t hit any critical bugs or security vulnerabilities.

I’ve run Kubernetes since 2018 and I can count on one hand the times there were major issues with an upgrade. Have sensible change management and read the release notes for breaking changes. The amount of breaking changes has also gone way down in recent years.

Same. I think maybe twice in that time frame we've had a breaking change, and those did warn us for several versions. Typically the only "fix" we need to apply is changing the API version on objects that have matured beyond beta.

I applaud you for having a specific complaint. 'You might not need it' 'its complex' and 'for some reason it bothers me' are all these vibes based winges that are so abundant. But with nothing specific, nothing contestable.

My home lab has grown over the years, now consisting of a physical Proxmox cluster, and a handful of servers (RaspPi and micro hosts). A couple years back I got tired of failures related to host-level Docker issues, so I got a NAS and started using NAS storage for everything I could.

I also re-investigated containerization - weighing Docker Swarm vs K3s - and settled on Docker Swarm.

I’ve hated it ever since. Swarm is a PITA to use and has all kinds of failure modes that are different than regular old Docker Compose.

I’ve considered migrating again - either to Kubernetes, or just back to plain Docker - but haven’t done it. Maybe I should look at Uncloud?

How does this compare to https://www.mooncake.dev/pgmooncake? It seems there are several projects like this now, with each taking a slightly different approach optimized for different use cases?

Definitely similar goals, from the Mooncake author: https://news.ycombinator.com/item?id=43298145

I think pg_mooncake is still relatively early stage.

There's a degree of maturity to pg_lake resulting from our team's experience working on extensions like Citus, pg_documentdb, pg_cron, and many others in the past.

For instance, in pg_lake all SQL features and transactions just work, the hybrid query engine can delegate different fragments of the query into DuckDB if the whole query cannot be handled, and having a robust DuckDB integration with a single DuckDB instance (rather than 1 per session) in a separate server process helps make it production-ready. It is used in heavy production workloads already.

No compromise on Postgres features is especially hard to achieve, but after a decade of trying to get there with Citus, we knew we had to get that right from day 1.

Basically, we could speed run this thing into a comprehensive, production-ready solution. I think others will catch up, but we're not sitting still either. :)

FYI the mooncake team was acquired by Databricks so it's basically vendors trying to compete on features now :)