I Finally Adopted Nix on Fedora 44 (Without Compromising SELinux)

• Sat, May 9, 2026
• 5-minute read

I am very particular about what gets to touch my base system - for both system stability and security reasons.

Over the years, this approach evolved into a simple, non-negotiable policy: the OS and its low-level plumbing come from rpm, because I want those components blessed, tested, and SELinux-aware. Graphical apps, on the other hand, come from Flatpak - because a browser or a document viewer is the part of my desktop most likely to meet something hostile, and Flatpak wraps each one in a bubblewrap sandbox. Everything stays in its lane, and the lanes rarely cross.

But there was always one stubborn gap: developer tooling.

Dev tools aren’t really the OS, but also never ship at Flatpak. I am always uneasy seeing them dropped system-wide as RPMs, where they’d age in place and force me to pin versions by hand. And they aren’t GUI apps either. For a long time, I papered over the gap with whatever was convenient - pip install --user - or now the better uvx - manual tarballs, the occasional dnf copr enable - and lived with the mess. It worked, but it was never right.

Then three things happened that made the gap impossible to ignore.

Building the Case for Nix

Security and Trust: AI Agents and Supply Chain Risks

The first was the rise of AI coding agents - Claude Code, Vibe, Codex, OpenCode - pick your favorite. These tools iterate at a pace no distribution can responsibly match, arriving via curl | sh or secondary package managers, bypassing SELinux entirely. At the same time, supply chain attacks have been surging, with threat actors targeting dependencies in major tools — including some AI agents — compromising systems at build time or runtime. Installing system-wide from shell scripts or dropping binaries without a proper package manager means no easy way to track, update, or patch vulnerabilities. If a tool is powerful enough to write code on my behalf, it’s powerful enough to do damage if it misbehaves - or if its dependencies are compromised. I needed a way to contain them, and to keep my system auditable and up-to-date.

The Dev Environment Struggle

The second was a growing frustration with the friction of managing dev environments. Projects needed different versions of Python, Node, Ansible, Terraforn. I grew tired of juggling venv or nvm in my shell profile, or worse, polluting /usr/local/bin with manually installed binaries. I wanted isolation, reproducibility, and the ability to nuke an environment and start fresh without touching my base system.

Jupiter Broadcasting’s Nix Evangelism

Then there was the non-stop evangelism from the team at Jupiter Broadcasting — the guys behind Linux Unplugged. They talked about Nix and NixOS so often that listeners started daring them to mention it less. I won’t rehash what they’ve already covered in their episodes (and if you’re curious about Nix, past episodes on Nix are worth a listen). They’re usually ahead of the curve and as a long-time listener, I knew it was only a matter of time before I’d have to try it myself.

Nix Officially Lands in Fedora 44

The final push - I guess that’s four points now. Historically, Nix didn’t ship with Fedora and clashed with SELinux. That changed with Fedora 43, which approved the /nix directory and laid the groundwork for proper SELinux integration. Fedora 44 then made it official, packaging Nix 2.34 in its repos with a Fedora-policy build, so you can now install it with a simple dnf install nix.

That’s when I finally took a serious look at Nix.

Why Nix?

Nix promised everything I wanted:

• Isolation: Every package lives in its own directory in /nix/store, with no files scattered across /usr, /usr/local, or /opt.
• Reproducibility: A shell.nix or flake.nix file pins exact versions of every dependency. Share the file, and anyone - or any CI system - can reproduce the exact same environment.
• But the real clincher was cross-platform consistency. My daily driver is Linux, but client work sometimes demands macOS (and, as a last resort, Windows via WSL). Homebrew on macOS suffers from the same systemic issues as RPM. With Nix, I could now manage my flakes and dotfiles (via Chezmoi) in a single repo, then deploy uniformly across Fedora, Ubuntu, RHEL, macOS, or even WSL. One configuration, one workflow, everywhere.

Nix also has a reputation. It’s complex. It’s different. It rewrites the rules of how a package manager should work. So here’s the opinionated account of how I made it work.

First Dilemma - Multi-User Daemon or Single-User?

And Why I Chose the Daemon

The Nix community often recommends single-user installs for non-NixOS systems. The reasoning is it’s easier to set up, doesn’t require root, and avoids the complexity of a system-wide daemon. But for me, the trade-offs weren’t worth it.

The Case for Single-User:

• Simpler setup: No systemd service, no daemon, no /etc/nix configuration.
• Portable: Your Nix environment lives entirely in your home directory, making it easy to sync across machines.

But here’s what you lose:

• Weaker build sandbox - builds run as your own UID instead of isolated nixbld users. A misbehaving or malicious build process runs as you, with access to everything you have access to.
• You’re off the recommended path - single-user is the less-tested, less-seamless setup on Fedora. You lose the alignment with what the distro and upstream actually validate.

In either cases:

• You’ll loose nothing on daily ergonomics. nix profile install and nix develop are equally sudo-free in both modes. So if that was your reason for leaning single-user, it wasn’t a real reason.

So in the end, the demon won and this is the path for out setup.

In the next post

With the rationale clear, the next step is putting it into practice. In the next post, I’ll walk through the actual setup of Nix on Fedora 44 so you can try it yourself.