For security there are these scanners:
https://github.com/flyingcircusio/vulnix
https://github.com/andir/nix-vulnerability-scanner
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.
https://github.com/MatthewCroughan/nixcfg
https://github.com/hlissner/dotfiles
https://github.com/georgewhewell/nixos-host
https://github.com/ipetkov/dotfiles
There's also the DevOS project, which is an attempt to create a base of boilerplate than anyone can use as a start to build a system:
Recommendations:
* Definitely use flakes
* 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.
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.
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.
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.