How much time do you spend maintaining this stuff every month? Like upgrading versions, etc.? Do you subscribe to any security channels? Do you care what language it's built in, try to keep it all on a few languages to minimize maintenance burden, etc.? I've been considering self-hosting, but put off thus far by the above concerns.
Initially I spent a lot of time as I used it as an opportunity to learn Nix/NixOS. I used Nix intentionally as it's a rolling release and also it's declarative and intended for reproducible deployments, so I don't need to deal with an OS like Ubuntu that slowly gets crufty and out of date and needs a clean-up or upgrade or complete re-install. And if I do need to re-install, it should be mostly a one-liner.
I also run all services in docker and my network uses VLANs behind an OPNSense firewall. I use Wireguard as a pinch point into my network to access most services. So I'm not too worried about the security aspect.
Upgrading on Nix is pretty easy - just bump your lock file and it will get the latest packages, assuming you are on the unstable channel. But unstable does break on occasion. You an also use the latest stable release of Nix and selectively choose unstable packages, which is probably the way to go. I rarely need to fix anything - it's been pretty reliable - I feel like with each patch I make to my config (which is all checked into git), the system gets more reliable and reproducible - 2 steps forward, no steps back. It only starts eating time when I want to add or upgrade some element to the system, but I always make sure to never do any action that isn't captured in Nix config and backed up, so that I don't have to come back and figure out what exactly I did or how something works again. It's been fine. Nix has a pretty steep learning curve, but considering its power, I think it's absolutely worth it.
* Use Agenix to store secrets out in the open (encrypted with your SSH key)
* Use home-manager
* Keep config modular so you can selectively include it in various hosts and domains (e.g. desktop vs server).
Think of it as building software when you figure out how to organize your config. The bulletpoints above can all be a bit difficult to figure out so don't feel bad if you don't get them installed right away. Try to start with a machine that isn't your daily driver and blocking your workflow.
Any thoughts on Guix as compared with Nix? I've tinkered a bit with Nix, including running NixOS for a bit on my laptop, but quite like the lispy languages in comparison.
I found out about guix after already investing in nix. Looks great, and better in many ways, but I'm more familiar with Haskell syntax than lisp, and my understanding is that the nix ecosystem is far more developed.
Good to know, thanks! It does seem to have more packages and such for sure, and more traction among Haskell crowd I think from the bit I've seen.
Either way, I am more inclined currently to use packages on top of a base Linux distro, so suspect I can mess around more without committing to either for now.
How do you handle partition management? I've got all the mount points set up in my configs but the initial creation of partitions was still a manual process that I'd need to go back to my notes for if I ever have to redeploy things.
I wrote a script that I have in GitHub that I curl down to a new system I need to prep. It takes four or five params, e.g. UEFI vs legacy, SSD vs disk, etc, then does all the prep programmatically. This really should be part of the nix ecosystem though.
Started by getting it working on my new work laptop (Thinkpad), then putting it on my personal laptop (Dell XPS) to figure out how to split config into multiple hosts, then finally onto an HP proliant server I've got hosted at home.
100%. I did already have another laptop that I used until this one became stable. Now I feel it's more stable and useful than my previous one though. It actually helps rather than hinders when it comes to avoiding messups and catastrophic mistakes. Each time you deploy, it creates a snapshot, so you can always roll back if you mess something up. And as you update your config, your system gets progressively more stable and to your liking. And it's forever, since it's just text files stored in a repo. I feel like it achieves the same thing as Chromebooks do, except without the involvement of a centralized corp. My laptop is my data rather than the hardware itself. You do need to backup anything stateful though, but I don't have much stateful data on my machine other than some code in my home folder which is already backed up in git.
You can run this stuff using docker & then just have a cron script to `docker-compose pull && docker-compose up -d`. I run this once a week and it keeps all my software up-to-date.
Not OP but I was running a number of services with docker.
This was a major pain. Docker is fine for local development, but unless you have a full time department dedicated to babysit it, it’s not scalable for self hosting. Observing services becomes complicated and requires a whole tool chain, ditto keeping on top of new versions, etc.
What I did instead is install proxmox on my server, and run the former server (that was running all the docker stuff) as a virtual machine within proxmox.
I was then able to gradually move everything away from docker and into VMs or LXC containers (which are basically lightweight VMs, but you can use all existing tooling and treat it like a VM). I’m using ansible roles and playbooks, I can ssh into the containers, and unattended upgrades for updating, and tarsnap or borg for backups.
It’s much saner this way ad I don’t end up running versions that are several years old because of the complexity/inertia of docker.
Not OP, but I'm self-hosting for similar reasons. I don't spend very much time on maintenance - if a service is troublesome, it's not worth my time and gets the cut. I don't subscribe to any security newsletters or have any automated new version monitoring in place (yet), but I'm planning to do that at some point so that the home lab can run itself with minimal intervention beyond changing a few version numbers in docker-compose files and rerunning my "redeploy everything" script.
As for languages, it's a very marginal factor. If I have a large number of possible services in a given space, I usually gravitate towards Go, because most Go applications are closer to 12-Factor compliance and generally stability than, say, most Python applications. If I have no options or the best service in a given space is written in COBOL or something equally bad, I'll still take that. I'm quite pragmatic.
IMO, if you want to get into this, keep a few things in mind:
- Docker (Compose) will save you a lot of work
- if you want to expose stuff to the internet, you'll need to stay reasonably current with updates
- have a good system for backing up your data. Experimenting is far easier if you can back up what you've got, and start over from scratch to try a different approach. Doing this "live" is riskier.
