nix-community/NUR: a meta repository for user contributed Nix packages

Why a meta repository exists next to Nixpkgs

Nixpkgs is a single tree with a review process. A package that nobody wants to review, or that is too niche, too new, or too personal, can sit in a pull request for a long time. NUR was created to share packages from the community in a faster and more decentralized way, and the README is explicit that its packages are built from source and are not reviewed by any Nixpkgs member.

The unit of contribution is a repository, not a file. Each contributor registers a repository under a name and is responsible for its content, and the packages inside it are reached through attributes of the form nur.repos.<user>.<package>. That naming is the whole design: NUR does not host the package expressions itself, it points at repositories that do.

The audience is Nix users who already know how to write or read a derivation. If you have never built anything with nix-build or nix-shell, the failure modes here (a stale pin, a broken evaluation, a package that no longer compiles against your nixpkgs) will be hard to diagnose.

The repos.json index is the actual mechanism

The top level of the repository contains repos.json and repos.json.lock, and the README states that NUR automatically checks its list of repositories and performs evaluation checks before it propagates updates. So the data flow is: a contributor registers a repository, the index records where it lives, and CI evaluates it. If the evaluation fails, the update is not propagated.

What that check does not do is inspect intent. The README carries the warning in bold: NUR does not check the repository for malicious content on a regular basis and it is recommended to check expressions before installing them. Evaluation is a build-time correctness gate, not a security review. A repository that evaluates cleanly can still run arbitrary code at build time, because that is what a Nix derivation is allowed to do.

The index also means the attribute namespace is flat and shared. Two contributors cannot both own the name mic92, and a package you depend on can change under you when its owner pushes to their repository. Pinning is the only defence, and the README treats it as an optional convenience rather than a requirement.

Installing NUR with flakes and building a first package

With flakes enabled, NUR is added as an input whose nixpkgs follows your own, so the package set is evaluated against the same nixpkgs revision you already use. The README shows this input block:

{
  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
    nur = {
      url = "github:nix-community/NUR";
      inputs.nixpkgs.follows = "nixpkgs";
    };
  };
}

After that, either overlays.default or legacyPackages.<system> can be used. The README's own first-use example is the hello-nur package from the mic92 repository, run through nix-shell:

$ nix-shell -p nur.repos.mic92.hello-nur
nix-shell> hello
Hello, NUR!

If you are not using flakes, the older path is packageOverrides. For a single user, add this to ~/.config/nixpkgs/config.nix:

{
  packageOverrides = pkgs: {
    nur = import (builtins.fetchTarball "https://github.com/nix-community/NUR/archive/main.tar.gz") {
      inherit pkgs;
    };
  };
}

On NixOS the same block goes under nixpkgs.config.packageOverrides in /etc/nixos/configuration.nix, and the README notes that if you want to use NUR in nix-env, home-manager or nix-shell you also need the ~/.config/nixpkgs/config.nix entry. From there a package can be installed with nix-env -f '<nixpkgs>' -iA nur.repos.mic92.hello-nur, or listed in environment.systemPackages.

To find what exists, the project points at the package search at nur.nix-community.org and at the nur-combined repository, which contains all nix expressions from all users and can be searched on GitHub.

The one-hour cache and why you should pin

The non-flake path fetches a tarball of the main branch. The README states that builtins.fetchTarball without a sha256 only caches the download for one hour by default, so you need internet access almost every time you build something. That is a real operational cost on a laptop that is often offline, and it also means the expression set can move between two builds of the same configuration.

Pinning replaces the branch URL with a specific commit tarball and a sha256, which the README shows as a commented example with the url pointing at a commit archive and the hash obtained by running nix-prefetch-url --unpack on that url. There is no documented rollback procedure and no documented way to pin a single repository's contents independently of the NUR index; the README does not discuss either. If a repository you depend on breaks, your options are to pin NUR to an older commit or to stop using that attribute.

NixOS modules and Home Manager modules from a user repository

NUR is not only packages. The README shows a NixOS configuration importing nur.modules.nixos.default to add the overlay, and importing a repository's own module directly as nur.repos.iopq.modules.nixos.xraya. Home Manager works the same way: imports can be set to lib.attrValues nur.repos.moredhel.modules.homeManager, after which the services declared by that repository behave like any other Home Manager option.

For a standalone Home Manager build, through home-manager.lib.homeManagerConfiguration, the overlay is added with nur.modules.homeManager.default in the modules list. The README's example is truncated at that point, so the full standalone wiring is not documented in the file as given.

This is the most useful part of NUR for people who want an integrated service rather than a binary. It is also the part with the widest blast radius: a module from a personal repository can set system state, open ports, and write configuration files, and the NUR evaluation check will not tell you whether the option defaults are sensible. Reading the module is the review.

Where NUR is the wrong tool, and what to use instead

NUR is the wrong tool when you need a package that will still build in two years without you watching it. Nothing in the index promises that a contributor will keep their repository working, and the maintainer field in the repository metadata names one person for the NUR index itself, not for the packages inside it.

The obvious alternative is Nixpkgs itself. The difference is process, not capability: a package in Nixpkgs has been reviewed by Nixpkgs members, is built by the project's own CI on a regular schedule, and is covered by the binary cache, so installing it usually means downloading rather than compiling. A NUR package is built from source on your machine unless the contributor publishes a cache, and the README does not describe any shared binary cache for NUR packages.

A second alternative is a plain flake input pointing directly at the contributor's repository. That skips the NUR index and the evaluation check, but it also skips the indirection: you get exactly one repository, pinned by you, with no dependency on repos.json. If you only need one package from one person, that is less machinery than importing the whole meta repository.

Maintenance, licensing and what the index does not tell you

The NUR repository itself is MIT licensed, and the LICENSE file is at the top level. That licence covers the index and the tooling in bin/, lib/ and ci/. It does not automatically cover the packages in the repositories the index points at; each contributor's repository carries its own licence, and the README does not describe any licence check in the evaluation step. If you redistribute a NUR package, the licence of that package is the one that matters.

The last push date for this repository is not available in the repository metadata, so there is no basis for a statement about how recently the index has been updated. What can be said is structural: the index is a single point of failure for every attribute path, and the CI that checks repositories is what keeps broken entries out. The upgrade cost is therefore mostly your own pinning discipline. Every time you move your NUR input forward, you are moving every repository in the index forward at once, and the only signal you get is whether evaluation passes.

Editorial conclusion

Adopt NUR when you need a package that exists in someone's personal repository and you are willing to read the expression before you build it. Do not adopt it as a replacement for Nixpkgs review, and do not expect a stability guarantee from any nur.repos.<user> attribute. Before installing anything, open the repository listed in repos.json for that user, read the default.nix behind the attribute you want, and check the commit history of that repository rather than the age of the NUR index.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository