Recently, I’ve found myself walking several friends through what is essentially the same basic setup:
- Install Ubuntu server
- Install Docker
- Configure Tailscale
- Configure Dockge
- Set up automatic updates on Ubuntu/Apt and Dockge/Docker
- Self-host a few web apps, some publicly available, some on the Tailnet.
After realizing that this setup is generally pretty good for relative newcomers to self-hosting and is pretty stable (in the sense that it runs for a while and remains up-to-date without much human interference) I decided that I should write a few blog posts about how it works so that other people can set it up for themselves.
As of right now, there’s:
- An introduction (with Ubuntu basics)
- Tailscale setup
- Optional Docker Explainer
- Dockge setup with watchtower for automatic updates
- MicroBin as a first self-hosted webapp
Coming soon:
- Immich
- Backups with Syncthing
- Jellyfin
- Elementary monitoring with Homepage
- Cloudflare Tunnels
Constructive feedback is always appreciated.
EDIT: Forgot to mention that I am planning a backups article
My experience after 35 years in IT: I’ve had 10x more outages caused by automatic updates than everything else combined.
Also after 35 years of running my own stuff at home, and practically never updating anything, I’ve never had an outage caused by a lack of updates.
Let’s not act like auto updates is without risk. Just look at how often Microsoft has to roll out a fix for something an update broke. Inexperienced users are going to be clueless when an update breaks something.
We should be teaching new people how to manage systems, this includes proper update checks on a cycle, with appropriate validation that everything works afterwards, and the ability to roll back if there’s an issue.
This isn’t an Enterprise where you simply can’t manually manage updates across hundreds or thousands of servers, and tens of thousands of workstations - this is a single admin, small environment.
I do monthly update checks, update where I feel it’s warranted, and verify systems afterwards.
Well, you just saved me a bunch of time trying to figure out how to auto-update my humble little server. Granted, I only have Plex and Samba Share right now, but I like the principle. Hell, an update once blanked my smb config file for whatever reason
Now auto-backups are another thing; because I would like to use a .tar file, but then it leads me down a rabbit hole because I don’t know how to repair Grub if needed for a restore, or what Grub really even is vs Bios… I’ve just been learning as I go
I’m a few weeks away from getting a couple parts for an upgrade, and then it’ll be some fun. I want to redo it from scratch and maybe set up proxmox and change my file system to zfs, then start looking at docker, figure out Jellyfin and look at some ARR stuff… maybe tailscale or headscale. Idk, it’s just fun cause it’s a hobby. I just haven’t had the storage or ram really, but soon
I don’t disagree with any of that, I’m merely making a different value judgement - namely that a breach that could’ve been prevented by automatic updates is worse than an outage caused by the same.
I will however make this choice more explicit in the articles and outline the risks.
Don’t expose anything outside of the tailnet and 99% of the potential problems are gone. Noobs should not expose services across a firewall. Period.
with properly limited access the breach is much, much less likely, and an update bringing down an important service at the bad moment does not need to be a thing
This is really the truth. Auto-updating is really bad form when you are getting into server management. The first admin position I had back in the day had the rule that no automatic updates are to run, a manual update can only be run after 1 month of that update being released, and it had to accompanying documentation confirmed before it could be approved. The one time we did not follow that we ended up having to re-image the server in question from backup (as that was the quickest solution to getting it back online).