birkeyWhy I love NixOS
What I like most about nixos is that you can have deterministically cached packages you don't need to rebuild every time in your ci.
It's also simple to setup dev environments with nix.
Nix in CI seems like a really excellent match. I don’t care much about the ATproto space - but Tangled has built their CI system on Nix and I find that really compelling. CI Caching is just awful with GitHub actions - so it made me disappointed that Forgejo went that route.
This is exactly why I made https://nix-ci.com/
And it supports Forgejo, GitHub, and GitLab.
And it supports Forgejo, GitHub, and GitLab.
I'd love NixOS more if they had any decent documentation.
Everything seems scattered around a dozen forums, a hundred old blog posts, and a thousand issues of "this work on my machine (3 releases ago)".
A lot of us use NixOS/nix yet haven't read any documentation nor hand-written nix ourself. That's Claude Code's job.
If only.
Claude Code has to be actively steered, because while it knows some nixpkgs it surely doesn’t know it enough. E.g. it was absolutely incapable of fixing lldap settings after system upgrade from 25.05 to 25.11. It just prodded around blindly, producing meaningless configs instead learning how the module works.
NixOS docs work for me, but I tend to just go for the nixpkgs source instead. Manuals document options but not how those are actually plumbed through, nor what remains behind the scenes like all systemd unit settings). Claude can do this too, but it goes quite weird roundabout ways with a lot of weird `find /nix/store` and `nix eval`s to get to it, slow and token-hungry (and not always accurate).
This said, Claude is very helpful at checking logs and providing a picture of what’s going on - saves ton of time this way. Plus it can speed up iterating on changes after it’s fed enough knowledge (but don’t expect it to do things right, that’s still on you). It has breadth of it, but not the depth, and that shows at almost any non-trivial task.
You don't have Claude Code git clone nixpkgs and home-manager for local reference?
I feel you on the nix store + nix eval death loop, though it gleans real info. If I weren't on the Claude Max plan I'd probably feel more of the pain. And context is now 1MM tokens which means you're not running out just as it's starting to piece things together, heh.
I do, but it somehow tends to forget how to do things right now and then - despite having notes in memories system - and starts to do them in its own weird ways.
I’m going to experiment with skills next, or maybe make it build a few helper scripts for itself to quickly get some module source from nixpkgs matching flake.lock without having to think of it all. I’m positive about Claude for nix management, merely saying it’s not something that “just works” for now and reading nix code is still on the human part of the tandem.
This said, to be fair - when it gets the approach right, it excels. I was setting up Ente for photos backup and sharing, and it produced a nice overlay with custom patches for my needs from just “figure out why /shared-albums/ redirects wrong and fix”. Found the module, the package, pulled source, analyzed it, proposed a patch (settings weren’t enough), did it - I only had to test, and only because I haven’t provided it with a browser. Felt amazing.
I would have never become a power user of Linux were I used LLM to do the installation of Gentoo once upon a time. :( So do you guys not know much about the distro you are using, or how does this work? I honestly thought your comment was sarcasm, but apparently it is not.
NixOS is high-level declarative, so you're reading high-level config diffs when the AI agent is pitching changes.
Unless you're brand new to Linux or computing, it's not a mystery what a given nix config change is ever doing.
You can probably guess what this does:
networking.firewall.allowedTCPPorts = [ 8080, 9000 ];
The things to know about the OS are high level things. The rest of its idiosyncrasies you learn just in time through daily exposure like anything else.
Well, there's layers. When I started using nixOS I read through the guide and wiki but I also used LLM assistance to help create a stable starting point. Then over time I've incrementally added new things to my configuration through a mix of LLM assistance and reading online material.
I think the initial migration towards nixOS is the hardest point, since it requires learning a bunch of new things all at once in order to get the system into a usable state that matches your expectations and preferences. The key benefit of using an LLM is that it makes it really easy to get your system into a useful initial state, and then you can safely learn and experiment incrementally with a mix of tools.
When I started off I didn't understand everything, but at this point I feel I have a very good understanding of everything in my configuration file.
Kind of an interesting thing here where if this is how you view it, it kind shows in itself why you don't actually need it.
Like what is ultimately the difference here for you vs a non-nix user who, as author says, is just dealing with some big ambiguous pile of state? It kind of takes away any upside to using nix, and probably just creates more friction for your AI than just running ubuntu/apt stuff.
The idea is you can keep configuration "in your head" such that you can reason and iterate and fully know what your system is like at any moment. If you actually don't care about that, you aren't getting anything out of it!
The upside of Nix config is that it's the state of my system in a declarative config file.
I have these packages installed and these firewall settings and these users with these permissions and this folder served over Samba and these hotkeys that do these things and these Obsidian vaults synced over SyncThing and these devices in my SyncThing network and Neovim installed with these plugins and ...
This is difference between me and a non-nix user, not whether we can rattle off the exact state of our live system from memory.
The non-nix user has to query live system state, if such query tools even exist for their question, and I get to read a config file. And I get to maintain my system config in git, and I get to deploy my config on all of my machines.
So relying on closed source code using a closed model to configure a free OS. That's a step back.
[delayed]
It doesn't help that there are two NixOS wikis. nixos.wiki and wiki.nixos.org.
wiki.nixos.org claims that nixos.wiki is outdated and unofficial. But both appear to receive updates, and which one wins the SEO game is a coinflip whenever i google a nixos question.
I switched over to Nix about a year ago. I was a Windows user before that for 30 years and tried Linux a couple of times, but it never stuck. Now I know I will never touch Windows again. With NixOS I've finally found a system that actually works for me — and the full OS configuration is in a repo. My god, I love it so much.
Sometimes I even prefer nix-shells over uv for quick one-off Python scripts.
I cannot sufficiently convey how absolutely barbaric everything else feels in comparison. Not having Nix would be like having to work on code without Git — absolutely unacceptable.
And it really isn't that much work — you do it once. The next time you set up a new system, without Nix, you'll have to do the full configuration all over again.
Sometimes I even prefer nix-shells over uv for quick one-off Python scripts.
I cannot sufficiently convey how absolutely barbaric everything else feels in comparison. Not having Nix would be like having to work on code without Git — absolutely unacceptable.
And it really isn't that much work — you do it once. The next time you set up a new system, without Nix, you'll have to do the full configuration all over again.
Have you heard of any good projects for running isolated containers in NixOS that are cheaply derived from your own NixOS config? Because that is what I want. I want a computer where I can basically install every non stock app in its own little world, where it thinks "huh, that is interesting, I seem to be the only app installed on this system".
Basically, I want to be able to run completely unverified code off of the internet on my local machine, and know that the worst thing it can possibly due is trash its own container.
I feel like NixOS, is one path toward getting to that future.
sounds like you want qubes os https://www.qubes-os.org/
depends whether you consider rootless Docker "cheap". I tried running ZeroClaw in a Nix-derived Docker (spoiler - it was a bad idea to use ZeroClaw at all since the harness is very buggy) and there is still a potential for container escape zero-days, but that's the best I've found. also, Nix's own containerization is not as hermetic as Docker; they warn about that in docs
If containers are safe enough for ur use case then just use nixos containers they just a few more lines to setup in a regular nixos config
If it isn't enough
there's microvm.nix which is pretty much the same in difficulty /complexity, but runs inside a very slim and lightweight VM with stronger isolation than a container
You mean like https://wiki.nixos.org/wiki/NixOS_Containers ?
There is also https://microvm-nix.github.io/microvm.nix/ if you want increased isolation.
That's hard given most apps have dependencies and often share them.
It will always look like curl is available or bash or something
What's wrong with another user account for such isolation?
They can be isolated to namespaces and cgroups. Docker and Nix are just wrappers around a lot of OS functionality with their own semantics attempting to describe how their abstraction works.
Every OS already ships with tools for control users access to memory, disk, cpu and network.
Nix is just another chef, ansible, cfengine, apt, pacman
Building ones own distro isn't hard anymore. If you want ultimate control have a bot read and build the LFS documentation to your needs.
Nothing more powerful than the raw git log and source. Nix and everything else are layers of indirection we don't need
> Nix is just another chef, ansible, cfengine, apt, pacman
No, because Nix code is actually composable. These other tools aren't.
The author almost touches on the one more topic that I adore about Nix, but ends up just so missing it: NixOS is absolutely incredible for its ability to be configured through AI tooling. And I don't mean that it's better than other operating systems, I mean that it's the only game in town.
I've been using Nix, both the package manager and the operating system, for years by now. I agree with all of the author's points, it really does deliver, the declarative nature is superb, and there's this constant sense of "hey my stuff is not breaking by itself" when working on it. And it's that declarative, rollback-able, file-based foundation, that makes it the perfect operating system for telling a coding agent to go to town on.
Would I trust Claude to switch my audio stack from Pulseaudio to Pipewire on Ubuntu? Would I trust Codex to install Hyprland on Fedora so I can test out the session? No, in fact I would not trust any agent to do any of those things on any other operating system. But I would trust even goddamn Grok to do that on NixOS, because I can 1) audit the changes before anything is done, and 2) rollback, rollforward, roll-whatever-the-way-I-want-even-on-the-floor-if-I-want-to because of the years of built up confidence proving that IT JUST WORKS.
I concede that this is turning into an unhinged loveletter to Nix, but really, it's the only operating system that lets one operate with this level of confidence. And I know most people don't care about that, since most people don't usually bother to tweak their OSes or switch out window managers, but as someone that does that, I'm never going back to mutable distros. This security is my table-stakes now, and the others aren't willing to pay up.
So for the developers out there on the lookout for their "Year of the Linux Desktop 2026" -distribution, if you're already using AI assistants, give NixOS a try. Maybe start with this in an empty Git repository: "Hey Claude, I wanna try NixOS. Make me a Flake-based starter config using Gnome that I can demo in a virtual machine. If nix isn't yet installed, install it via determinate-systems installer. Include a "vm" target in the flake for building the image, and a small bash script that builds and launches the VM using whatever virtualization is available on my platform."
I've recently switched to nix as a way to encode my environment across my server and work / private devices a bit more than just having some Brewfiles. I know it's not worth it for the computer switch every few years but having a somewhat opinionated place to centralize my config is worth it over regular dot files.
My first impression after a week of using:
- I really dislike the complexity of terraform, and this is very similar
- The UX is pretty bad, the commands and flags are hard to memorize and you basically need a shell alias for any regular commands to clean them up
- The commands you run regularly like applying your nix config to the system after adding some new packages or config options look like: "nix run nix-darwin -- switch --flake /Users/philipp/repos/github.com/dewey/nix#private"". The output is a mix between expected warnings and way to verbose for something that should essentially be the equivalent of "brew update / brew upgrade".
I'll stick with it as I didn't find anything better and LLMs are great for building up the config over time, but there's definitely room for some improvements.