Jack K

The Nix logo (snowflake made of 6 lamdas alternating between dark and light blue) with the GitHub organisation and repository "NixOS/nix" and the description "Nix, the purely functional package manager".

So You've Heard of Nix

August 1, 2025 ◦ 7 min ◦

Nix is a tool that's rapidly gaining popularity; it's something you may have heard of in passing conversation, or seen in threads and blogs online.

But what actually is Nix? Like what does it actually do? How might it benefit your workflow; your day-to-day needs?

I'd like to address some of the immediate benefits it can offer you as a new user, and also some aspirational cool things it can do which you may go on to use.

Table of Contents:

Quick Wins

Package Availability

Fundamentally nix is a package manager so the first aspect I'll focus on is the package availability.

Using nix (and its package repository nixpkgs) you gain access to an enormous selection of packages. As tracked by https://repology.org as of writing there are over 107k "packaged projects" available.

That number alone isn't much use, so to put it in perspective: Arch with the AUR has 90k, Debian 39k, Fedora 24k, and Arch without the AUR has 11k.

Now these raw numbers are interesting but it's also useful to look at the number of "non-unique packaged projects" too. By filtering out packages that are only seen in one repository we can track projects which multiple distributions have considered useful. This can be particularly important to avoid cases where additional packages are just a side-effect of correctly packaging a program.

Nix is still in the lead with 85k (-20%), Arch with the AUR on 51k (-43%), Debian 29K (-27%) Fedora 22k (-10%), and Arch without the AUR still on 11K (-4%)

Below is a graph of total packages on the X-Axis and "fresh" packages on the Y-Axis showing not only the amount of packages but also how up-to-date they are. Ideally you want a package repository that's not only far on the X-Axis for coverage, but as close to the Y-Axis (close to the darker grey area) as possible denoting how up-to-date it is. The nixpkgs repository quite literally sits in its own section of the graph.

I'd also like to emphasise pure package availability and freshness isn't everything. Distributions like Debian with a lower package count benefit from being a curated list, wide user testing, and stability. But I'd also like to add as a nixpkgs maintainer I think it also has good measures in place to test packages such as running their unit-tests when building and even featuring End-to-End style tests with NixOS VMs for important packages.

Platform Coverage

Nix can be used on almost any Linux environment and even on MacOS (Darwin), some usage on BSD and even minor usage on Windows.

This wide coverage also extends to architectures. "x86_64-linux" is the best supported architecture but unlike many repositories "i686-linux" (aka 32bit machines) also receives support and cached builds. Then for SBC or Raspberry Pi fans there's also support for various ARM linux platforms like "aarch64-linux".

For MacOS the new Apple silicon "aarch64-darwin" is supported for many packages but so is the older intel based "x86_64-darwin" allowing you to extend the life of your devices.

There's also community work on more exotic platforms like "riscv64-linux".

Teams Use the same tools

Building upon the large package availability and the strong platform coverage when working with others you can all leverage the same tooling.

For teams across Linux and MacOS there's the benefit of most tools being available to both platforms.

Let's say we have a team of 4 using: Arch, Debian, MacOS, and NixOS and they're interested in using buf for managing protobuf files.

buf is available for Arch in the official repos, MacOS in homebrew, and NixOS in nixpkgs. However it's not available in the Debian repos. Now in the case of buf it's not too big a problem since go install is quite easy to use so that can be the method for Debian.

Your next concern might be that you're all on separate versions, updating at different rates.

The plan might be to move everyone to using go install to fetch the exact same version of buf. This works quite well and you can even fix a version within your Makefile or scripts to ensure it's all matching.

This is easy enough but there are still some drawbacks. You have a minor wait for some quick go builds, there are sometimes additional steps beyond go install for version information when you run --version, additional libraries, etc. And this is purely looking at go based projects. The moment you also need a python project like pre-commit, a node/npm based project like prettier, or a haskell based project like hadolint you have to make all these decisions again.

Another thought may be to use containers but you'll still be making the same decisions for which base distro, where to fetch the package from, whether to fetch the binary yourself (and of course check the sha256sum!).

By just leveraging nix the package maintainers will see to updates and following the correct build instructions. And for Libre and Open Source projects you get to leverage the cache for pre-built packages.

Trying Nix

If you're thinking nix could help you simplify your work the next question is probably how to get access to nix.

I'd firstly recommend just playing with nix inside of a container. It's published to the Docker Hub @ nixos/nix and by mounting a directory or just trying things inside the container you can get an initial feel before installing it to your system.

For what to try I'd recommend using the Search on NixOS.org to find packages you're interested in.

From there you can:

  • Immediately run it
    • Original nix-shell syntax: nix-shell --run <PACKAGE>
    • Newer syntax with flakes: nix run nixpkgs#<PACKAGE>
  • Make it available in a temporary shell
    • Original nix-shell syntax: nix-shell -p <PACKAGE>
    • Newer syntax with flakes: nix shell nixpkgs#<PACKAGE>
  • Make its dependencies available if you have its source you want to build
    • Original nix-shell syntax: nix-shell -A <PACKAGE>
    • Newer syntax with flakes: nix develop nixpkgs#<PACKAGE>
  • Add it to a list of packages you'd like as a "dev shell" for your project

(If you're wondering whether you should use the original or newer syntax it's totally up to you! There are some out-of-the-box benefits to the flakes method but these can be replicated with additional tooling.)

Installing Nix

Once you're happy there are 3 main install methods:

The first two options are both good and have their pros and cons. The third option I personally don't use but it's up to you.

Anyway, welcome to the fold and thanks for reading! I plan to do a series on creating your own packages either for personal use, for your team, or to submit upstream to nixpkgs!