nix builds are now available in fedora updates repos. (edited: Dec 13)
There is also an initial test package of nix-2.24 for epel10 now in my copr repo if anyone wants to try that.
edit: epel9 looks tricky (RHEL9 seems to have sqlite version incompatible with nix-2.12 at runtime). If someone can recommend an older working nix version I can try with that (maybe worst case could be 2.3, which I think is considered insecure by now).
Just out of interest, are there any plans on dealing with the SELinux? From my experience it was the major issue for nixpkg CentOS-based OSs 
Or are you going with the single-user mode in this case, as it is the least painful way?
There is a possibly related bug open - letâs see what comes out of it and is possible. Help is welcome.
A build of nix-2.24 is now in epel10 (edited Jan 3rd).
It hasnât seen that much testing: the version is still really from the âautotools eraâ of nix, so it is somewhat different to the new meson builds in fedora.
Announced also now on Nix Discourse:
This concept adds incredible flexibility to Fedora. It was discussed for a bit last summer (2025), and then that discussion died out. It work, though. See the other thread and the associated project. For clarity, that other discussion was about using bootable Fedora containers and âNix-toolboxâ as an extension of Fedora toolbox.
As to working on a containerized host, no problem. There are some configurations to make under /etc and everything else goes into the home environment. Yes, one could simply run the Nix package manager. That is crude, IMHO; instead, run with the toolbox and home manager to abstract away some of that manual editing which would otherwise be necessaryâŚ
I aware of GitHub - thrix/nix-toolbox: Fedora toolbox with nix. (though the last build was for f42). Is that close to what you have in mind?
(I experimented a little with trying to make a nixos toolbox last year but didnât really get what I wanted so far.)
Thatâs what Iâm thinking of - cloning thrixâs work and trying to set it up to run on custom images from the Universal Blue ecosystem. I see you have Nix running in Silverblue, so it ought to be configurable for single user mode Origami Linux or some of the other niche images. If this can be made to just work in a generic sense, it really cracks package access wide open.
One last question: will there be any issues with a need to access directories under opt or usrlocal?
I think the basics should work (within the limitations of rootless nix (SB) or toolbox).
I am certainly interested to hear how this goes. 
So far my gui testing has been fairly limited: I think some things work and others may not.
If you are in a toolbox then /opt and /usr should be owned by the container and so shouldnât be a problem in that sense. Or do you mean accessing the host directories? that may be more tricky, though there is /run/host of course.
If you want to run full nix on Silverblue I think yes you need a custom image with /nix.
I spent some time working on a bind mount /var/nix â /nix but it is not pushed to fedora yet (though you can test my copr repo - feedback is welcome): I hope to get back to finishing that this month.
Yeah, working it out: ci: build container images for all active Fedora releases by thrix ¡ Pull Request #29 ¡ thrix/nix-toolbox ¡ GitHub
A bit delayed.
Would love to hear what you wanted to do and did not work for you?
To throw in my experience, in case it is helpful: thus far Iâve found it easy enough to run single-user Nix in uBlueâs Toolbox container. A simple Distrobox config lets you install Nix via an init hook. It would be straightforward to try other uBlue images in a container with this setup.
This has been the easiest setup I could come up with for now. Spawning a Nix terminal is ergonomic enough, since Distrobox creates a desktop entry for the container. Home Manager works in the container as well, but you have to install it interactively. Havenât encountered any major issues.
A solution like Nix Toolbox is probably more robust in the long term, but for now this has worked well for me.
Thatâs cool - I want to try nix-toolbox and the ublue stuff too, thanks.
(Well I was trying something different: to make an actual nixos toolbox container image using nix, but in the end I came to conclusion that the official nix container may be close enough for now. I think a couple of problems I hit included getting su/sudo to work and also legacy nix commands. Maybe I will try again at some point.)
I had some luck with nixGL today, e.g.:
$ nix profile add nixpkgs#goxel
$ nix run --impure github:nix-community/nixGL -- goxel
(or say glmark2) works for me. (This really requires /nix (ie nix-filesystem). The --impure option allows gpu autodetection to work, otherwise one needs to use specific nix run github:nix-community/nixGL#nixGLIntel (for intel or amd) or #nixGLNvidia). For Vulkan there are corresponding #nixVulkanIntel or #nixVulkanNvidia outputs. (Note the above will download quite a bit: mesa is big⌠Also this even works from inside a toolbox container as one might hope.)
Also: we now have a matrix channel #fedora-nix room on matrix btw for those who want to get involved with improving and testing the fedora nix package.
(I had added this info to the fedora nix README file.)
Thanks for sharing, sounds similar indeed. One thing I am doing in nix-toolbox is bind mounting the nix store from home to /nix, so I can share the store between multiple nix-toolbox invocations. That way move to next fedora version does not need to download all the things.
Anyway, glad to see people experimenting on similar things
That was actually also what I was trying to do (build a nixos based toolbox container image), but ended up to be a dead end for me and not worth the effort. I cannot now recall exactly what issues I run into, but there were a few quite hard to resolve. Also I somehow like this blend of fedora toolbox with nix, I can use what I want from Fedora and from Nix pkgs. Did not even run into too many issues, except maybe the Python stack, which is better to be used from Fedora.