nix-cachyos-kernel: CachyOS kernels packaged for NixOS

What the flake actually packages

The nix-cachyos-kernel repository describes itself as Nix packages for the CachyOS kernel, and the README is precise about the three things it brings in.

First, CachyOS patches, taken from the CachyOS kernel-patches repository. Second, CachyOS tunings, from the CachyOS linux-cachyos repository. Third, a CachyOS patched ZFS module, from the CachyOS zfs repository. The project is licensed GPL-2.0, the primary language is Nix, and the homepage is a Hydra CI jobset rather than a documentation site.

That combination is the reason the project exists. CachyOS maintains a patched and tuned kernel with a set of non-default schedulers, and NixOS users who want that kernel have a problem: the kernel is not in nixpkgs, and building one on your own machine is a long compile that also means you own the patching and the update process. This flake turns the upstream CachyOS artefacts into Nix packages, which means the kernel is a declarative input rather than something you install and forget.

The trade is that you are now dependent on two things you do not control: the CachyOS patch set and the person maintaining this packaging. The first is upstream and public. The second is one repository, and the README's own wording, that the release branch contains what the maintainer's Hydra CI has built, makes the dependency on that one build setup explicit.

The variant matrix and why there are forty of them

The package list in the README is long, and the shape of it is the design. The tree shows one directory, packages, containing x86_64-linux, and inside that a set of kernel names that vary along two axes.

One axis is the kernel line: latest, lts, bore, bmq, deckify, eevdf, hardened, rc, rt-bore and server. The other is the build and microarchitecture level, with plain, -lto, -x86_64-v2, -x86_64-v3, -x86_64-v4 and -zen4. The excerpt below shows the latest group, where each name is a separate package:

        ├───linux-cachyos-latest
        ├───linux-cachyos-latest-x86_64-v2
        ├───linux-cachyos-latest-x86_64-v3
        ├───linux-cachyos-latest-x86_64-v4
        ├───linux-cachyos-latest-zen4
        ├───linux-cachyos-latest-lto
        ├───linux-cachyos-latest-lto-x86_64-v2
        ├───linux-cachyos-latest-lto-x86_64-v3
        ├───linux-cachyos-latest-lto-x86_64-v4
        ├───linux-cachyos-latest-lto-zen4

The scheduler names are the CachyOS ones: BORE, BMQ, EEVDF, the BORE real-time variant and the deckify scheduler. The x86_64-v2, v3 and v4 levels are the x86-64 microarchitecture baselines, which is how a single package set serves processors from old Haswell to Zen 4, and the zen4 entries target that specific microarchitecture.

The LTO suffix has a defined meaning: the README states that the kernels ending in -lto have Clang plus ThinLTO enabled. That is a build-level choice, not a feature, but it is baked into the package name because the resulting binary differs.

One detail is easy to miss and expensive to ignore. Several of the LTO variants are annotated as having no binary cache, and the annotations cover the bmQ, deckify, eevdf, hardened, rc, rt-bore and server LTO packages, plus several of the ZFS ones. A package without a cached binary means Nix has to build it locally, which for a kernel means a long compile on your own machine.

release branch versus master, and the daily sync job

The repository has two branches that matter, and the difference is about cache hits rather than about versions.

The release branch contains the latest kernel that has been built by the maintainer's Hydra CI and is present in the binary cache. The master branch, which is the default, is for people who want the absolute latest version with or without a binary cache. The way to see what is currently effective is:

nix flake show github:xddxdd/nix-cachyos-kernel/release

Keeping the two apart is the interesting engineering decision in the project. A flake input that points at a commit where the kernel has not been built yet is a configuration that compiles a kernel on the user's machine, which is exactly the experience this packaging is meant to remove.

The versions themselves are kept current by automation. The README states that the kernel versions are automatically kept in sync with upstream CachyOS releases via a daily GitHub Action, implemented in update.py, so once CachyOS updates their kernels the repository catches up on its own. The update job therefore decides what exists, while the Hydra build decides what is actually available as a binary.

That division explains why a repository with no GitHub releases still gives you reasonably current kernels. The release history that matters is not a tag list but the daily job and the build server, and both of them are outside the repository.

The ZFS modules follow the same pattern, with packages named zfs-cachyos, zfs-cachyos-lto, zfs-cachyos-lts, zfs-cachyos-lts-lto, zfs-cachyos-hardened, zfs-cachyos-hardened-lto, zfs-cachyos-rc and zfs-cachyos-rc-lto, each of which matches a specific kernel.

The pinned overlay is the part that decides your experience

The README is unusually insistent about one configuration choice, and the reason is entirely about the binary cache.

There are two overlays. The pinned overlay uses the exact nixpkgs revision defined in this flake, matching what was used to build the cached kernels. The default overlay uses nixpkgs from your own environment, and the README notes that this may not hit the binary cache and that the kernel will need to be built locally even if a cached kernel is available.

The cause is that a kernel package is built against a specific nixpkgs revision. Change the revision and the derivation hashes change, so the cached artefact no longer matches what your system asks for, and Nix falls back to building locally.

The README recommends pinned if you want to ensure you can fetch the kernel from the binary cache and that the kernel can be built successfully. It suggests default if you want to avoid initialising multiple instances of nixpkgs, if you want the latest kernel modules that have just been merged or updated in nixpkgs, or if you want to customise nixpkgs.config options.

The binary cache itself is configured through nixConfig in the flake, so Nix will prompt you to accept it on first use. That is a deliberate trust decision by the user: your kernel comes from a third party cache, and the prompt is the point at which you agree to it.

For most people the pinned overlay is the right choice, and the cost of the alternative is a kernel build on first boot.

Wiring it into a flake

Using it in a flake takes two edits. First, add the release branch as an input, and the README attaches a warning to that line:

{
  inputs = {
    nix-cachyos-kernel.url = "github:xddxdd/nix-cachyos-kernel/release";
    # Do not override its nixpkgs input, otherwise there can be mismatch between patches and kernel version
  }
}

The warning is the same issue as the overlay choice in a different place. The kernel patches are written against a kernel version, and the nixpkgs input determines which kernel version you build, so overriding it can produce a combination that does not apply cleanly.

Second, add the overlay to your NixOS configuration. The README's example wires the overlay into a nixosSystem:

            nixpkgs.overlays = [
              # Use the exact nixpkgs revision as defined in this repo to ensure binary cache hits.
              nix-cachyos-kernel.overlays.pinned
            ];

After that you set boot.kernelPackages to the variant you want, for example pkgs.cachyosKernels.linuxPackages-cachyos-latest, and the packages are exposed under pkgs.cachyosKernels.

For convenience, every linux kernel entry under packages has a corresponding linuxPackages entry under legacyPackages, so the README gives the mapping as inputs.nix-cachyos-kernel.legacyPackages.x86_64-linux.linuxPackages-cachyos-latest for the latest kernel and the same pattern with the variant name changed. That legacyPackages path is what most configurations will use, since it plugs straight into boot.kernelPackages.

Non-flakes users and the ZFS module pairing

Not everyone uses flakes, and the README covers that case with npins. The commands are short:

npins init
npins add github xddxdd nix-cachyos-kernel

The generated default.nix is then imported, and the kernel is selected from the legacyPackages path in the same way:

let
  sources = import ./npins/default.nix;
  cachy-source = import sources.nix-cachyos-kernel;
  cachy-kernel =
    cachy-source.outputs.legacyPackages.x86_64-linux.linuxPackages-cachyos-bore-lto-x86_64-v3;
in
{
  boot.kernelPackages = cachy-kernel;
}

The README also mentions that you can fetch the flakes directly with fetchFromGitHub, but notes that you then have to update the revision and the hash manually every time you want a new kernel, which it describes as tedious. That is the real cost of not using a flake or npins: kernel updates become a manual edit rather than a lock file bump.

The ZFS side deserves its own attention because it is where a mismatch causes a boot failure. The zfs-cachyos packages exist for the plain, lto, lts, hardened and rc kernel lines, and the naming makes the pairing explicit: zfs-cachyos-lts goes with the lts kernel, zfs-cachyos-rc with the rc kernel. A ZFS module built for a different kernel version than the one you boot will not load, and there is no partial credit for guessing which combination was meant.

On scope, everything in this repository targets x86_64-linux. There is no arm64 package set here, so anyone on an Apple Silicon or ARM server is not served by this flake.

Editorial conclusion

Use this flake if you are on NixOS and specifically want the CachyOS kernel line, its scheduler variants or its ZFS module, and you are willing to follow a third party overlay rather than track upstream Linux yourself. Do not use it if the stock nixpkgs kernel is enough, because every CachyOS patch and tuning is extra surface to track, and do not use the default overlay if you care about binary cache hits. Before you switch, read the pinned overlay note, check that your CPU is covered by the x86_64-v2, v3, v4 or zen4 variants, and confirm that the ZFS module you pick matches the kernel you boot, noting that the last push was on 2026-10-19 and that the repository publishes no GitHub releases.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. Project website
4. README
5. xddxdd/nix-cachyos-kernel on GitHub