Nix in GitHub Actions

I just created an issue (Add Nix package manager · Issue #1579 · actions/virtual-environments · GitHub) to request Nix support from within GitHub Actions VMs. Please go show it some love if you have GitHub :+1:s to spare!

This is something I personally need but I also suspect that this is a promising approach for expanding Nix’s impact and reaching more users. If Nix can become the “go to” method for installing X package in someone’s CI workflow they’ll come to discover Nix automatically. People are also going to be far more willing to try out some new package manager in CI before they install it on their personal machines.


I wonder how much disk space curl -L | sh takes up

Good question, I just ran a test:

Looks like the answer is a little under 300Mb. That’s actually quite a bit higher than I was expecting for an empty install…

we could probably inspect the runtime closure to slim that down future. IIRC, parts of it still rely on perl and a few other utilities.

Yeah, I’m all for going on a campaign to rid Nix of perl haha

I looked into this further, apparently the biggest culprit is that you get a top-level checkout of the nixpkgs repo. And that’s 190MB out of the 270MB for a base install.

glibc is 32MB
nixexprs is 15MB

everything else is under 10MB and seems necessary for nix to work correctly.

If we wanted to improve this, we would have to “trim some fat” from the repo.

1 Like

If the Nix commands could be taught to read .nix.gz files then the repo shinks to about 105 MiB (33 MiB apparent size)…

1 Like

Would it be possible to just do a shallow checkout instead?

that’s what it’s doing, even the tarball version of the repo is still massive. After all, it has some 50-60k+ packages on it

Yeah I just tried git clone --depth 1 -b master and it’s 169Mb. Damn…

1 Like

It seems to me that the download will grow arbitrarily large as nixpkgs and nix gain in popularity. I wonder if some ideas from the Unison project ( and might be worth considering as nix is inevitably forced to scale.

The gist of it is that code is content-addressed along with everything else. For nixpkgs this could mean that users only need to download the AST version of all-packages.nix to start and then lazily download the Nix expressions for packages that all-packages.nix points to as necessary. Because everything is content-addressed this means just-enough downloads for the user and a very easy storage/replication for hosting the nixpkgs data.

1 Like

some package are being removed, but definitely not at the rate in which they are being added.

I think eventually many things will be transferred over to flakes, in which you can opt-in to different ecosystems. And maybe nixpkgs will be slimmed down in size


For people reading this thread, it might be interesting to know there are (at least) two actions for installing Nix on the GitHub Actions Marketplace:

1 Like

How does your action compare to GitHub - cachix/install-nix-action: Installs Nix on GitHub Actions for the supported platforms: Linux and macOS.?

The first of those is install-nix-action–it’s just a link to its marketplace page.

Yes I know. I was asking @rickynils since he’s one of the dev of the other one, and I was wondering if his has some nice features that the cachix one doesn’t have.

1 Like

I’d really like to get to a point where we can have an official GitHub Action to install Nix, or better yet just get Nix into the VM images. That way we can avoid this headache of figuring out the differences between a bunch of unofficial options.

1 Like

From the action page:

The main motivation behind this action is to install Nix as quickly as possible in your GitHub workflow. If that isn’t important, you should probably use the Install Nix action instead, which sets up Nix in multi-user mode (daemon mode) using the official Nix installer.

1 Like

It’d be interesting to find out, if anyone knows someone, what criteria GH uses, here.

I think it’s also good to know who does the work and how it would be maintained. And game out a bit what would need to happen if they weren’t keeping up with it.

Some context on why I think these are important: I’m picking at an unofficial replacement for the community-maintained Travis-CI Nix support (aside: I could use a little help here on well-defined small tasks–message if interested), which should be a stepping stone to asking Travis-CI to remove the semi-official support (and hoping they comply, and hoping the deprecation is smooth…). I’m doing this because the update process is so clunky that no one really seems to want to deal with it, but I think it’s a community-/dev-relations problem to just let the semi-official support rot (and it does, unless your project pins Nixpkgs).

Having Nix in the images would be great, as long as it’s going to keep working. If we have serious questions about that, though, there are advantages to having some form of ownership.

I don’t see it as bad, yet, but I am a little worried about ending up with too many CI flows with too much feature drift between them. Features are great, and experimenting to find improvements is also great, but choices also make it harder to onboard people, and feature drift also increases the switching costs.


The process is quite straightforward, and I think they might be open to it if someone went ahead and just submitted a PR: Add Nix package manager · Issue #1579 · actions/virtual-environments · GitHub. I think there was some misconception there that the cachix action is official.

1 Like