NUR — The Distributed Package Registry Nix Deserves

If you come from Arch, the AUR feels like the obvious model for community packaging: one big shared repository, everyone submits PKGBUILDs, and the collective package count turns into a kind of ecosystem scoreboard.

NUR takes a different path, and I think it is the better one.

NUR is not a monorepo of user packages. It is a registry of user repositories. Each contributor owns their own repo, publishes whatever packages, modules, and overlays they want, and NUR indexes the result. At the time of writing, the NUR package index shows 5,944 packages across 369 user repositories. That is a lot of ecosystem hiding in plain sight.

If you have not explored it yet, you are probably underestimating what the Nix community has already packaged.

What NUR actually is

The important mental model is this:

• AUR is a shared submission queue
• NUR is a federated directory

That difference sounds subtle until you use it.

With AUR, the package lives inside the central repo. With NUR, the package lives in the maintainer’s repo, and NUR points you to it. The registry is the index, not the home.

That makes NUR feel much more like the rest of the Nix ecosystem. You are already used to composing inputs, pinning revisions, wiring overlays together, and deciding exactly what enters your system closure. NUR fits that model naturally.

Why this architecture is better

The simplest comparison looks like this:

That last point matters more than it first appears.

In NUR, you do not have to think in all-or-nothing terms. You can consume the whole registry via the NUR overlay if you want the giant package namespace, but you can also pull in one maintainer’s repo directly, pin it to a commit, and use only the parts you care about. That is a better fit for how serious Nix users already manage risk and reproducibility.

It is not that AUR is bad. The AUR is one of Arch’s best ideas. But NUR solves the same community-packaging problem in a way that feels much more native to Nix.

Discoverability is much better than people assume

One of the classic arguments for a monorepo is discoverability: if everything lives in one place, surely it is easier to find.

But NUR already gives you the searchable index people actually need. nur.nix-community.org lets you search across the full registry, browse repositories, and inspect what maintainers are publishing. You get the discovery benefits of aggregation without forcing everyone into one git history and one submission model.

That turns out to be a very good trade.

You can stumble across exactly the kind of wonderfully niche packaging work that thrives in Nix:

• Prometheus exporters that are too specific for nixpkgs
• Firefox extension collections packaged as reproducible derivations
• SDDM themes that become one declarative option instead of manual file copying
• Small infrastructure tools, IRC bots, relay daemons, and odd little utilities that absolutely belong somewhere even if they are not mainstream enough for nixpkgs

That is where NUR shines. It is the long tail of the Nix ecosystem, but with structure.

It is not just packages

This is the real differentiator.

AUR gives you install recipes. NUR repos can give you full Nix building blocks: packages, overlays, NixOS modules, Home Manager modules, helper libraries, and flake outputs.

That means the thing you discover is often not just “here is a binary.” It is “here is a binary, plus a module, plus sane service wiring, plus options, plus a reusable overlay if you want to patch it.”

That is a much richer packaging story.

For example, if you consume a NUR repo directly as a flake input, you can wire its modules straight into your system:

{
  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    nur-ijohanne.url = "github:ijohanne/nur-packages";
  };

  outputs = { nixpkgs, nur-ijohanne, ... }: {
    nixosConfigurations.myhost = nixpkgs.lib.nixosSystem {
      system = "x86_64-linux";
      modules = [
        nur-ijohanne.nixosModules.prometheus-hue-exporter
        {
          services.prometheus-hue-exporter.enable = true;
        }
      ];
    };
  };
}

And if you want the big shared namespace instead, the upstream NUR overlay works too:

{
  inputs.nur.url = "github:nix-community/NUR";

  outputs = { nixpkgs, nur, ... }: {
    nixosConfigurations.myhost = nixpkgs.lib.nixosSystem {
      system = "x86_64-linux";
      modules = [
        nur.modules.nixos.default
        ({ pkgs, ... }: {
          environment.systemPackages = [
            pkgs.nur.repos.mic92.goatcounter
            pkgs.nur.repos.ijohanne.zot
          ];
        })
      ];
    };
  };
}

That flexibility is the point. You can browse globally and consume locally.

A concrete case study: my own NUR repo

My repository at ijohanne/nur-packages is exactly why I like this model.

It contains a mix of things that would be awkward to pitch as one giant upstream contribution story:

• Prometheus exporters for Hue, Netatmo, nftables, TeamSpeak3, Ecowitt, TP-Link P110, and PostgreSQL
• NixOS modules for those exporters, not just package derivations
• A hardened Firefox profile and curated Firefox addon packaging
• Fish and Vim plugin sets
• SDDM themes
• zot, multicast-relay, and other niche infrastructure tools
• agent-skills-cli

That is a coherent repo because it is my repo. It reflects what I run, maintain, and care about. And that is precisely why the federated model works: each maintainer can publish a package universe that makes sense for them without asking a central project to absorb the whole identity of it.

NUR turns that into something discoverable and reusable for everybody else.

The trust model is nicer

In practice, NUR gives you a more granular trust decision than a central community repo.

You can decide:

• which repos you want to use
• which commits you want to pin
• whether you want the full overlay or a single upstream
• whether you want only packages or also modules and overlays

That maps directly to how Nix users already think. Reproducibility is not just about exact builds. It is also about being explicit about your inputs.

With NUR, the social layer and the technical layer line up more cleanly. You can say “I trust this maintainer’s repo for this host” in an actual, concrete, pin-able way.

How to create your own NUR repo

The official NUR repository expects each upstream to expose a top-level default.nix. In practice, many repos also expose a flake so they are easy to consume directly outside the shared overlay.

At the minimum, your package repo can look like this:

{ pkgs }:
{
  hello-nur = pkgs.callPackage ./pkgs/hello-nur { };
}

If you want a flake interface too, you can layer that on top:

{
  description = "My NUR packages";

  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";

  outputs = { self, nixpkgs }:
    let
      system = "x86_64-linux";
      pkgs = import nixpkgs { inherit system; };
    in {
      legacyPackages.${system} = import ./default.nix { inherit pkgs; };
    };
}

Once the repo exists, you add it to repos.json in nix-community/NUR, open a PR, and your repo becomes part of the index. If you want updates to show up faster than the normal refresh cycle, NUR also exposes the nur-update.nix-community.org hook described in the upstream docs.

That onboarding path is refreshingly lightweight. You own your repo. NUR just helps people find it.

Why this matters

The deeper story here is not “look, another package collection.”

The deeper story is that Nix packaging is already more composable than most ecosystems, and NUR preserves that composability instead of flattening it into one central contribution queue. It lets community packaging stay decentralized without becoming undiscoverable.

That is exactly the shape this ecosystem wants.

If you have only used nixpkgs plus the occasional flake input, spend half an hour browsing NUR. You will find packages you did not know existed, modules you did not realize someone had already written, and repos maintained by people solving the same weird little problems you are solving.

That is what a healthy package ecosystem looks like.