Hello!
I have been playing around with Nix+home-manager on Arch before fully commiting to NixOS. I recently had a thought where when you “nix-ify” everything, it creates a situation where it becomes very hard to leave Nix.
Compared to tools like GNU Stow or Chezmoi, Nix only works well on certain distros. This creates a problem where you do get the promise of a consistent and declaritive home configuration, but at the cost of being trapped in a ecosystem. Sure you can use home.file or mkOutOfStoreSymlink. However, the former requires a constant rebuild & switch. The ladder justs ends up being messy; especially if you compare to Stow.
What do people do about this? If I just want to run NixOS on a couple of machines (eg. servers) and normal linux distros on my workstation, what is an ideal way to share dotfiles across both systems while still integrating with the system level tools (like pacman or apt)?
Maybe there is a major point I am missing about home-manager compared to other tools. I do like the declaritive side of things, but I don’t know how I would feel about commiting to Nix fully. For example, Nix is pretty hard to run on distros like Fedora Silverblue, but other dotfile managers work great.
Yeah. Nix is pretty much a blackhole because it becomes inconvinient to not use it for everything.
My personal solution is to use GitHub - andsens/homeshick: git dotfiles synchronizer written in bash for the actual dotfiles and than nix/home-manager becomes the cherry on-top with homeshick. This allows me to get comfortable in operating system/cpu architectures that do not support nix.
I manage all the system on my laptop with Nix but it is not NixOS, I have Nix-on-Mobian on PinePhone and Nix-on-Debian on a VPS (can’t be bothered thinking about the boot on either machine), and I definitely have all kinds of mixes in terms of how configuration is managed (me-managed symlinks to VCS for config, Nix-managed symlinks to config, Nix-managed copies of basically ready config files with a bit of search-replace applied, Nix-managed full generation of config files.)
On the other hand, once you have anything depending on calling library-version-incompatible executables in the same environment (won’t even notice with Nix, needs lots of careful work elsewhere — except Guix of course), you are stuck.
So, while I think the title has been answered sufficiently (yes and no, but why would you want anything else?), there is some tangential discussion to be had about dotfile philosophy:
That’s the neat thing, you don’t! If you deploy servers with nix, there’s absolutely no reason to ever log into them by hand, at least not for long enough that lack of dotfiles would be meaningful.
Test your deployments in VMs, deploy them with nix. Use your dev system with all its conveniences at all times.
In general, I argue that if you’re putting dotfiles on servers you’re probably doing it wrong in 2025. End-user facing software should never make it onto servers, if only to reduce attack surfaces.
Don’t use the latter. Doing constant rebuild & switch is per design - you’re supposed to deploy your dotfiles that way. I had inhibitions at first, too, but really, the design of home-manager is vastly superior.
Give it a shot, you’ll see that after the first week or two you barely ever have to update anything; The overhead becomes utterly negligible and it has significant benefits over stow (e.g. templating, per-host logic, etc.).
If it weren’t for nix I’d be using ansible these days. stow is just not great if your dotfiles are remotely complex.
I am curious about this, why would nix be particularly hard to run on silverblue? Is it because silverblue doesn’t like you having a /nix?
That isn’t what I’d call a “server”, sounds more like a personal workstation you have running elsewhere for one reason or another. You should have significantly different security practices and risk assessment for that type of machine than your average web-facing “server”.
There are many things servers can do besides hosting web pages, too, obviously, but I don’t think many of them warrant having any text editor installed if you can deploy actual config and such via nix (or kubernetes, or ansible, or…). If you actually want to store text files on a server, just serve a git forge or something.
Dunno specifically! But the point is to reduce your attack surface, not prevent a specific attack. The less cruft you have present the less likely some pathway you didn’t expect leads to an exploit.
I’m aware of various CVEs in emacs, for example. If you open emacs on random servers, chances are much higher that you run into some of these in a context where they can have a significant impact. Say your dotfiles include some config to read RSS with gnus; there are emacs versions where simply opening it could have caused arbitrary RCE with your admin user. This is even more likely if you share your config between workstation and server users with something like stow, since you’re not distinguishing between use cases.
It’s much better to just not use emacs outside of your dev machines, and at that point, why even have it installed and tempt yourself?
You can of course be far more paranoid too, if you consider completely arbitrary, unknown bugs in kernel code.
Correct. Fedora and RHEL-based distros use SELinux which means anything that is outside the usual system paths triggers a lot of warnings. Nix has been approved by Fedora, but I have not seen it in the stable versions of Fedora yet.
Chezmoi already has per-host logic and templating. I’d argue it is better for security as the actual packages can be confined with SELinux or Apparmor, while Nix supports none of these. Of course, it isn’t really declaritive unlike home-manager as the best you can replicate it, is with Ansible and Bash. That is why I am kind of on the fence on both sides (again the ecosystem is what I don’t really like).
I’ve never felt particularly locked in by NixOS or Home Manager. It’s not like they are doing anything magic. If I would like to move away from managing a particular program or service through these I would simply copy the generated configuration files and replace references to the Nix store with whatever works in my new setup.
I’ve occasionally thought about implementing something like home-manager eject -o {output dir} which would attempt to spit out all home.file entries to the given directory but with Nix store references replaced by some fancy heuristic. Although it is pretty far down my list since it seems unlikely that I’ll have a need for such a thing myself
Yes and mostly no. It’s up to you. You’re talking about config files. Most don’t have to be tied to NixOS. You can hook them into Home manager, flakes, etc… if you want.
Right now, mine are in .config and I can just upload them to github, like I did on Ubuntu.
I personally use outOfStoreSymlink for change heavy config files and I dont feel like it complicates anything. For other config files I suppose I can just copy paste the generated files if I ever move away from nix
Maybe you’d be interested in github.com/rmst/jix/. It’s declarative and it avoids the “Nix black hole problem” because its more flexible but it has only one user so far, afaik (me). I’m using it on a Macbook and NixOS servers.
