Just before Christmas, I spent an hour or so setting up uncloud on my homelab, and I am stunned at how easy it was to get working.
The motivation for doing this is because I’ve known for a long time that Swarmpit is basically abandoned. Disappointing, but true. The latest release of DietPi, my preferred distro for my Raspberry Pi and RockChip SBCs, included an update to docker and docker-compose completely broke all operability with Swarmpit. Queue panicked hunting for alternatives and a fortuitous discovery of Uncloud
Here’s what I’ve done:
- Added a wildcard DNS record pointing
*.suranyami.comto my dynamic DNS address:suranyami.duckdns.org. - Installed
tailscaleon each of the machines, and connected them to my free tailnet. This gives me a s…
Just before Christmas, I spent an hour or so setting up uncloud on my homelab, and I am stunned at how easy it was to get working.
The motivation for doing this is because I’ve known for a long time that Swarmpit is basically abandoned. Disappointing, but true. The latest release of DietPi, my preferred distro for my Raspberry Pi and RockChip SBCs, included an update to docker and docker-compose completely broke all operability with Swarmpit. Queue panicked hunting for alternatives and a fortuitous discovery of Uncloud
Here’s what I’ve done:
- Added a wildcard DNS record pointing
*.suranyami.comto my dynamic DNS address:suranyami.duckdns.org. - Installed
tailscaleon each of the machines, and connected them to my free tailnet. This gives me a stable URL for each individual machine that I can SSH into without needing to do NAT redirection on the router. For instance, my machine callednode1is available to me (and only me) atssh dietpi@node1.tailxxxxx.ts.net. - Updated my
~/.ssh/configwith entries for all the machines that look like this:
Host node1
Hostname node1.tailxxxxx.ts.net
User dietpi
- Installed uncloud on my laptop:
curl -fsS https://get.uncloud.run/install.sh | sh - Initialized the cluster by picking one of the above machines as a first server:
uc machine init dietpi@node1.tailxxxxx.ts.net --name node1 - Add other machines using
uc machine add dietpi@node2.tailxxxxx.ts.net --name node2 - Deploy services using
uc deploy -f plex.ymlwhereplex.ymlis a subset of adocker-composefile, but with minor changes. For instance, to deploy to a specific machine (which I have to do because I need to redirect port 32400 from the router to a specific machine, because plex is annoying like that), I do this:
services:
plex:
image: linuxserver/plex:arm64v8-latest
# ...
x-machines:
- node2
x-ports:
- 32400:32400@host
- plex.suranyami.com:32400/https
And that’s about it. No reverse-proxy configuration, no manual entry of IP addresses, everything is just automatically given a letsencrypt SSL certificate and load-balanced to wherever the servers are running.
I haven’t set up replicated services yet, but there are notes in the documentation on that, so that’s up next.
This is honestly the easiest way to self-host anything I’ve found.
It’s been 2 weeks or so now, and now that I’ve got the knack of the x-ports port-mapping syntax, I’ve also managed to get all my other services running everywhere.
Notable edge cases were:
Minecraft
x-ports:
- 25565:25565@host
Plex
x-ports:
- 32400:32400@host
- plex.suranyami.com:32400/https
Needed 2 mappings, one for the internal subnet for use by the AppleTV, because of some idiosyncrasy of the way the native Plex app works with behind the NAT versus over t’interwebz.
Jellyfin
x-ports:
- 1900:1900@host
- 7359:7359@host
- jellyfin.suranyami.com:8096/https
Only outages I’ve had so far were purely hardware-related: robo-vacuum somehow knocked out a power cord that was already loose… derp. That won’t happen again. And, the fan software wasn’t installed on my RockPi 4 NAS box, so it overheated and shut down. Fixed that this morning.