![\"nixos-is-making-me-less-afraid.jpg\"](\"https://entropicthoughts.com/image/banner/nixos-is-making-me-less-afraid.jpg\")
by kqr, published 2026-10-20
\nTags:
\n\nSomething funny happened a little while ago: I read about FreshRSS, and it\nsounded nice, so I installed it on a server and started using it. That would\nnot have happened a year ago, but then again, a year ago I didn’t have any NixOS\nservers.
\nFor the past few years, my rss feeds have lived locally on my phone only.\nThere was a good idea behind that[^1], but it never quite worked in practice. For one,\nmany things are easier to read on a larger screen. But it was also brittle to\ntrust a phone app to manage the read/unread status of thousands of articles\nacross a hundred feeds.[^2] What I really wanted was a server-side feed aggregator. This is software\nthat runs on a server, manages rss feeds, and then I can read the rss feeds\neither through a web interface, or through client applications. I’ve wanted that\nfor a while, but I’ve never taken the step, because it would be yet another side\nproject to maintain the deployment of.
\nBut now, with some NixOS experience, adding a working FreshRSS configuration\n(including backups) took 9 lines of Nix code[^3]. That installation has\njust hands-off worked for the past few months. If or when that server breaks, I\ncan spin up a new one running the exact same configuration, probably in\nsomething like 15 minutes. When we can do something like that, there is\nliterally no reason to not just try the new software.
\nContrast this against how FreshRSS is installed outside of NixOS. Then we’d
\nhopefully remember how to do all the above if something breaks and we need to
reinstall FreshRSS on a new or upgraded server later.
Of course, the FreshRSS project provides a container image which would shorten\nthe process a little bit. It purports to set up Apache with mod_php and\nconfigure them the right way. Then we’d only need to configure backups, create a\nsystemd service that runs the container, and manage nginx as a tls terminating\nreverse proxy in front of that, because the container image reasonably does not\ncome with tls support. This is still stuff to remember, and there’s also no\nguarantee the same thing works six months down the line when reinstalling,\nunless we wrote down which exact container image we downloaded.[^4]
\nI have mentioned before how much I dislike maintaining side projects. That\nincludes my own code, but also self-hosted services developed by someone else.\nI’m okay with a few minutes of maintenance here and there, but having to\nschedule hours of uninterrupted work to upgrade something, or spending any\namount of time at all on emergency maintenance, really kills my desire to work\nwith computers.
\nYou’d think someone of my disposition would be deep into configuration\nmanagement, container orchestration, or both, but no. I have made honest\nattempts with CFEngine, Ansible, podman, and k3s but none of them improved my\ninstallation/configuration/deployment experience significantly over (a)\ncarefully writing things down, and sometimes (b) turning those careful notes\ninto a shell script performing a sequence of ssh commands.[^5] The drawback of the shell script is that it\noften ends up relying on assumptions that become invalid with time, or when it\nis used in a different environment. A NixOS configuration reads a lot like the\ncareful instructions to myself, except they’re executable and they produce the\nsame result every time.
[^1]: I can mostly take time to read when I’m away from my computer anyway.
\n[^2]: In particular, when I switched to a different phone I could migrate all feeds to it, but the read/unread status was lost along the way.
\n[^3]: Plus a dozen more lines for the nginx reverse proxy configuration. It got a little complicated because I wanted to proxy_pass from a specific location block which required rewriting cookie paths. But that’s a me problem, not a NixOS problem.
[^4]: It does not help to build the container image from source, because two builds from the same Dockerfile separated by time can result in rather different container images.
\n[^5]: Yes, this is essentially reinventing Ansible – but less brittle. It won’t break the next time someone glances sideways at pip.