# Nyx: A Nix Flake for the Packages NixOS Won't Ship Yet

> Nyx, from the Chaotic LUG, provides a Nix flake for unreleased and "too much bleeding-edge" packages like mesa_git and linux_cachyos, plus experimental NixOS modules. It is a direct answer for users who want the newest code without waiting for nixpkgs, but it comes with trade-offs in stability and support.

**chaotic-cx/nyx** — Nix flake for "too much bleeding-edge" and unreleased packages (e.g., mesa_git, linux_cachyos, firefox_nightly, sway_git, gamescope_git). And experimental modules (e.g., HDR, duckdns).

- Repository: https://github.com/chaotic-cx/nyx
- Website: https://nyx.chaotic.cx
- Stars: 789 · Forks: 83
- Language: Nix
- License: MIT
- Published: 2026-08-21 · Updated: 2026-08-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/chaotic-cx-nyx

## What Nyx Actually Solves

NixOS users who want the absolute latest software face a waiting game. nixpkgs, the main package repository, favors stability and testing, so a new mesa release or a kernel git snapshot can take weeks to appear. Nyx, from the Chaotic Linux User Group, fills that gap. It is a Nix flake that packages "too much bleeding-edge" and unreleased software, like mesa_git, linux_cachyos, firefox_nightly, sway_git, and gamescope_git. The target audience is clear: enthusiasts and developers on NixOS unstable who want to run code that is still in active development. The same group maintains Chaotic-AUR, a similar service for Arch Linux, so they have experience in this niche. Nyx is not for everyone. It is for people who understand that a nightly Firefox or a git version of a graphics driver might break, and who are willing to troubleshoot. The project's README even includes a section titled "Why am I building a kernel? Basic cache troubleshooting," which signals that users often hit build issues and need to know why their system is compiling instead of downloading prebuilt binaries.

## How the Flake Is Structured

Nyx is a Nix flake with multiple outputs. The most important is the default module, which you add to your NixOS configuration. This module does two things: it enables the overlay that provides the bleeding-edge packages, and it automatically configures the binary cache. The README shows that on NixOS unstable, you add `chaotic.nixosModules.default` to your modules list. This single module is the recommended path. For NixOS stable, the situation is different. You cannot use the default module because modules are "prone to breaking due to the divergence between the channels." Instead, you add three separate modules: `nyx-cache`, `nyx-overlay`, and `nyx-registry`. This split lets stable users get packages and the cache without the experimental module options. The flake also provides a home-manager module for setups without NixOS, and you can run packages directly with `nix run github:chaotic-cx/nyx/nyxpkgs-unstable#firefox_nightly`. The branch name `nyxpkgs-unstable` is important; the README marks it with "IMPORTANT" in the flake input URL.

## Getting It Running: Commands and Config Keys

The README gives concrete examples. For NixOS unstable, you add a flake input: `chaotic.url = "github:chaotic-cx/nyx/nyxpkgs-unstable"`. Then in your configuration.nix, you enable packages and modules. The example shows `environment.systemPackages = [ pkgs.lan-mouse_git ];` and `chaotic.mesa-git.enable = true;`. The `chaotic` namespace is the module's option prefix. For NixOS stable, you use the same flake input but add the three separate modules. In configuration.nix, you can set `boot.kernelPackages = pkgs.linuxPackages_cachyos;` to use the CachyOS kernel. For home-manager without NixOS, you add `chaotic.homeModules.default` to your modules and set `nix.package = pkgs.nix;` in your home configuration. The README also mentions that you can disable the automatic binary cache with `chaotic.nyx.cache.enable = false`. A key warning: you must enable the module and rebuild your system before adding Nyx packages to your configuration. If you do not, you may end up building derivations from source instead of pulling from the cache.

## The Binary Cache: Convenience With a Catch

Nyx automatically adds its binary cache to your NixOS configuration when you enable the default module. The README states this is done "so we can gracefully update the cache's address and keys without prompting you for manual work." That is a pragmatic choice, but it also means the project controls part of your system configuration. If you dislike that behavior, you can turn it off with `chaotic.nyx.cache.enable = false`. The cache is essential for the project's usability. Compiling mesa_git or a custom kernel from source can take hours. The cache lets you download prebuilt binaries. However, the README's troubleshooting section hints that the cache does not always cover every derivation. Users will sometimes see a kernel build starting locally, even with the cache enabled. The documentation does not explain all the reasons for this, but it is likely that some derivations are too new or too rarely used to be cached. The project's own advice is to check the cache status, but the README does not provide a specific command for that. This is a point where users may need to rely on the Telegram or Matrix channels for help.

## Limitations: Stable Channels and Module Breakage

The most significant limitation is that Nyx is designed for NixOS unstable. The README is explicit: the section on unstable usage "does not apply for users using NixOS stable channels." On stable, you get packages and the cache, but not the experimental modules. Even on unstable, modules are experimental. The README describes them as "experimental modules (e.g., HDR, duckdns)." That means they can change or break without notice. The project's own documentation warns that modules are "prone to breaking due to the divergence between the channels." This is not a tool for a production server. It is for a desktop or development machine where a broken graphics stack is an inconvenience, not a catastrophe. Another limitation is the support model. The README explicitly asks users to avoid posting issues in NixOS's official channels. Instead, you must use the project's GitHub issues, a Telegram group, or a Matrix channel. That is a smaller support community than nixpkgs. If you are not comfortable with that, Nyx may not be for you.

## Alternatives: nixpkgs Unstable and Chaotic-AUR

The obvious alternative is to simply use nixpkgs unstable without Nyx. That channel already has recent versions of most software, and it is maintained by the NixOS community with a much larger testing base. The trade-off is that you will not get git snapshots or unreleased builds. If you need mesa_git specifically, nixpkgs unstable will not have it. For Arch Linux users, Chaotic-AUR is the direct equivalent. It provides prebuilt binaries for AUR packages, including git versions. Nyx is essentially a translation of that concept to Nix. The difference in approach is that Chaotic-AUR works with pacman and the AUR, while Nyx works with Nix flakes and overlays. The update cadence and package selection may differ, but the philosophy is the same: deliver the newest code, even if it is not stable. For a NixOS user, the choice is between waiting for nixpkgs or adopting Nyx. The latter is faster but riskier.

## Maintenance and Licensing

The project is licensed under MIT, which is permissive and imposes few restrictions on use or redistribution. The repository is not archived, and the README's announcement "WE'RE BACK FROM THE DEAD" suggests that the project has had periods of inactivity. That is a maintenance risk. If the maintainers stop updating the flake, the packages will drift from upstream and the cache may become stale. The README does not provide a formal maintenance policy or a schedule for updates. It does point to a Telegram news channel, which is the only official source for announcements. Upgrading Nyx is tied to your flake inputs. If you use a flake lock, you will update it with `nix flake update chaotic` or a similar command. The project's own documentation does not give a specific upgrade command, but the standard Nix flake workflow applies. Given the project's history, users should check the news channel before upgrading to see if there are known breakages. The MIT license means you can fork the project if maintenance stops, but you would then be responsible for keeping the packages working, which is a substantial effort.

## Conclusion

Adopt Nyx if you are on NixOS unstable, you crave the latest mesa or kernel git builds, and you accept that some modules may break between channel updates. Do not use it for a production system or if you need stable, well-tested packages. Before integrating, verify that the specific package you want exists in the flake, check the Telegram or Matrix channel for known breakages, and decide whether you are comfortable with the automatic binary cache configuration. If you are on NixOS stable, expect only packages, not modules, and be ready for potential API drift. The project is actively maintained by the Chaotic LUG, but its own documentation warns about breakage, so treat it as an enthusiast tool, not a foundation.

## FAQ

### How do I add Nyx to a NixOS stable flake?

Add the input chaotic.url = "github:chaotic-cx/nyx/nyxpkgs-unstable" and then list three modules by name: chaotic.nixosModules.nyx-cache, chaotic.nixosModules.nyx-overlay and chaotic.nixosModules.nyx-registry. Stable users do not get the single default module that unstable users add.

### How do I stop Nyx from adding its binary cache to my configuration?

Set chaotic.nyx.cache.enable = false. By default the cache is added as soon as you enable the module, so the project can update the cache address and keys without asking you to edit anything.

### What order do I have to enable the Nyx module and use its packages in?

Enable the module and rebuild your system before adding the derivations to your configuration. The page marks this with a row of exclamation marks and offers another option for using the cache right away.

### Can I run a Nyx package without installing it?

Yes, with nix run github:chaotic-cx/nyx/nyxpkgs-unstable#firefox_nightly, which runs the package straight from the flake reference instead of adding it to your system packages.

### Does Nyx have versioned releases I can pin?

No. The repository has no GitHub releases, and every documented input points at the branch named nyxpkgs-unstable rather than at a tag, so the lock file is what pins the package set.

## Sources

- [Official documentation](https://nyx.chaotic.cx)
- [Official README](https://github.com/chaotic-cx/nyx#readme)
- [Project repository](https://github.com/chaotic-cx/nyx)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/chaotic-cx-nyx