# NixOS/nixos-hardware: device profiles for machines that need more than defaults

> A CC0-1.0 collection of NixOS modules and profiles that adjust kernel, firmware and device settings for specific laptops, desktops and single-board computers. It is for NixOS users whose hardware does not behave correctly on a plain install, and it is not a driver repository.

**NixOS/nixos-hardware** — A collection of NixOS modules covering hardware quirks.

- Repository: https://github.com/NixOS/nixos-hardware
- Stars: 3,314 · Forks: 982
- Language: Nix
- License: CC0-1.0
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/nixos-nixos-hardware

## The gap nixos-hardware fills between nixpkgs and your laptop

A stock NixOS install gives you a kernel, firmware packages and sensible defaults. It does not know that a particular ThinkPad needs a specific trackpoint setting, that an Apple T2 machine needs extra handling, or that a single-board computer boots with a non-default device tree. Those details live in forum posts, wikis and personal configuration files, and every owner rediscovers them.

nixos-hardware collects them as NixOS modules. The README describes the repository as "NixOS profiles to optimize settings for different hardware". Each profile is a directory under a vendor tree (lenovo/thinkpad/x220, apple/t2, raspberry-pi, and dozens more), and importing that directory applies the settings it declares. The audience is narrow but real: people already running NixOS who have hardware that misbehaves out of the box, and who would rather write one import line than maintain a patch set.

It is not a driver project. The repository is Nix expressions, not kernel code, and the README makes no claim to replace nixpkgs. If your device has no profile, the repository has nothing to say about it.

## How profiles, channels and flake modules relate

The unit of reuse is a directory of Nix modules. A profile can import other profiles: a specific ThinkPad model directory typically pulls in shared settings from common/ and from its vendor tree, then adds its own. That layering is why the README says to import the model path rather than copying its contents.

The repository exposes the same profiles through three consumption paths. The channel path treats the repository as a tarball fetched by nix-channel, so profiles are referenced as paths such as <nixos-hardware/lenovo/thinkpad/x220>. The flake path exposes named modules, so the same ThinkPad appears as nixos-hardware.nixosModules.dell-xps-13-9380 style attributes, one per model. The fetchGit path builds a store path from a git revision at evaluation time.

The difference between them is update behaviour, and the README is explicit about it. Channel and flake inputs update when you update the channel or the flake lock. The fetchGit form, in the README's words, "will update the git repository on a rebuild", which means an unpinned fetchGit import can change your system on any rebuild. Pinning to a revision is the documented way to avoid that.

## Installing nixos-hardware with channels and a first import

The channel route needs two commands. The first adds the repository as a channel named nixos-hardware, the second fetches it. After that, the channel is available to your configuration under the <nixos-hardware/...> prefix.

```bash
sudo nix-channel --add https://github.com/NixOS/nixos-hardware/archive/master.tar.gz nixos-hardware
sudo nix-channel --update
```

With the channel present, add the profile path to the imports list in /etc/nixos/configuration.nix. The README uses the ThinkPad X220 as its example. Keep ./hardware-configuration.nix in the list, since that file holds the disk and filesystem settings generated at install time.

```nix
imports = [
  <nixos-hardware/lenovo/thinkpad/x220>
  ./hardware-configuration.nix
];
```

Rebuild with nixos-rebuild switch. What you should see is the profile's settings merged into the system configuration; the README does not enumerate which options each profile sets, so the way to confirm is to read the profile directory in the channel or compare the generated configuration. The README points to the profile table for the full list of model paths and, for the flake form, to flake.nix in the repository.

## Flake setup and the follow-the-nixpkgs input

The flake route is described in the README as experimental. The input block pins nixos-hardware from GitHub and, importantly, sets inputs.nixpkgs.follows = "nixpkgs" so the hardware modules evaluate against the same nixpkgs revision as the rest of your system. Without that line you can end up with two nixpkgs instances in one evaluation.

```nix
{
  description = "NixOS configuration with flakes";

  inputs = {
    nixpkgs.url = "https://channels.nixos.org/nixos-unstable/nixexprs.tar.xz";
    nixos-hardware = {
      url = "github:NixOS/nixos-hardware";
      inputs.nixpkgs.follows = "nixpkgs";
    };
  };

  outputs = { self, nixpkgs, nixos-hardware }: {
    # replace <your-hostname> with your actual hostname
    nixosConfigurations.<your-hostname> = nixpkgs.lib.nixosSystem {
      # ...
      modules = [
        # ...
        # add your model from this list: https://github.com/NixOS/nixos-hardware/blob/master/flake.nix
        nixos-hardware.nixosModules.dell-xps-13-9380
      ];
    };
  };
}
```

The README's own comment inside the module list is the authoritative pointer: the flake module names are defined in flake.nix, and the profile table in the README lists the corresponding attribute for each model. The third option, fetchGit, skips both and interpolates a store path directly into imports, which the README notes updates on every rebuild unless you pin a revision.

## Where nixos-hardware stops helping

The most obvious limit is coverage. The profile table is long, but it is a finite list of named models and boards. If your machine is not in it, there is no generic profile to fall back on, and the repository offers no instructions for deriving one beyond CONTRIBUTING.md. Writing a profile means understanding both the hardware and the Nix module system.

A second limit is scope. The repository adjusts settings; it does not ship out-of-tree drivers or firmware that nixpkgs lacks. If a device needs a driver that is not in nixpkgs, importing a profile will not conjure it. The README does not present the project as a driver source, and treating it as one leads to confusion when a profile enables an option whose backing package lives elsewhere.

A third issue is that profiles are only as current as their last edit. The repository's most recent release entry is mnt-reform2-nitrogen8m-v1 from 2021-05-29, and the second entry is literally named not-a-release. Releases are not how this project ships; profiles change on the master branch. The last push to the repository was on 2026-09-21, so the tree is being touched, but that says nothing about whether the profile for your specific model has been revisited since the hardware was current. A profile for a 2011 laptop that nobody maintains will still evaluate, and may still apply settings that no longer match the kernel in your nixpkgs.

## Doing it by hand, and what that costs

The honest alternative is to write the settings yourself in configuration.nix. That is what the profiles are: a set of boot kernel parameters, module lists, firmware packages and service tweaks, expressed as Nix. If you only need one or two options, hand-writing them is less machinery than adding a channel or a flake input, and it keeps the reasoning visible in your own file.

The difference in approach matters over time. A hand-written block is yours to update when the kernel changes; a profile is someone else's block that you inherit and update by bumping a channel or a flake lock. The repository's value is that many of those blocks already exist and are shared, and that a fix for one model can be reviewed by the people who own the tree. The cost is that you are now tracking a second input, and for the fetchGit form, one that can move on every rebuild.

A middle path the README supports is fetchGit pinned to a revision. You get the profile contents without the channel, and you decide when the revision changes. It is more verbose than the channel import and less integrated than a flake input, but it makes the update moment explicit.

## Licence, maintenance and what to check before importing

The repository is licensed CC0-1.0. That is a public-domain-style dedication rather than a software licence with patent language, and it is unusual for a code repository. For a user importing profiles into a personal NixOS configuration, the practical effect is that there are no attribution or copyleft obligations attached to the expressions. It is not legal advice, and if you plan to redistribute the profiles inside a product you should read the licence text itself rather than rely on this summary.

Maintenance is community-shaped. The README points to CONTRIBUTING.md for adding a device profile, to a Matrix room for questions, and to a recurring community meeting: the NixOS hardware team meets on the third Friday of each month at 18:00 UTC in a Jitsi room, with hardware@nixos.org as the contact. CODEOWNERS and a .mergify.yml file are present at the top level, which indicates review ownership and automated merge rules, though the README does not describe how either is configured. The last push was on 2026-09-21.

The upgrade cost is tied to how you consume it. Channel users pay it when they run nix-channel --update. Flake users pay it when the lock file moves. fetchGit users pay it on every rebuild unless they pin. In all three cases the thing that can break is a profile whose assumptions no longer match your nixpkgs or your kernel, and the README does not document a rollback procedure specific to the profiles; you fall back to your previous NixOS generation.

## Conclusion

Adopt it if you run NixOS on a machine that appears in the profile table and you want the vendor-specific settings applied declaratively instead of by hand. Do not adopt it if your hardware is not listed, or if you expect it to supply drivers, firmware blobs or kernel patches that nixpkgs does not already carry. Before importing anything, check that the path or flake module name you intend to use exists in the current tree, and verify that your configuration.nix or flake.nix already pulls in ./hardware-configuration.nix so the two sets of settings do not conflict.

## FAQ

### What are the hardware requirements for NixOS with nixos-hardware?

nixos-hardware does not change NixOS's own hardware requirements; it adds per-model settings on top. Coverage is limited to the models and boards listed in the README's profile table, so the practical requirement is that your machine appears there.

### How do I use nixos-hardware on NixOS?

Add the repository as a channel, a flake input, or a fetchGit import, then import the profile path or flake module for your model. The README gives the ThinkPad X220 as the channel example and dell-xps-13-9380 as the flake example.

### Does nixos-hardware replace the hardware-configuration.nix file?

No. The README's channel example keeps ./hardware-configuration.nix in the imports list alongside the profile path. The profile supplies model-specific settings; hardware-configuration.nix still carries the disk and filesystem configuration.

### Which nixos-hardware profile path should I import for my machine?

The README's profile table lists each model with its channel path and its flake module name. For flake users the README also points to flake.nix in the repository as the list of available module attributes.

### What licence does nixos-hardware use?

The repository is licensed CC0-1.0, a public-domain-style dedication. The README does not discuss licence implications, so read the licence text if redistribution matters to you.

## Sources

- [Issues](https://github.com/NixOS/nixos-hardware/issues)
- [License: CC0-1.0](https://github.com/NixOS/nixos-hardware/blob/master/LICENSE)
- [NixOS/nixos-hardware on GitHub](https://github.com/NixOS/nixos-hardware)
- [README](https://github.com/NixOS/nixos-hardware/blob/master/README.md)
- [Releases](https://github.com/NixOS/nixos-hardware/releases)

---

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