Nothing but Nix - reclaim 130GB for Nix in GitHub runners

Announcements
1

Nothing but Nix

Here’s a tool I’ve created that might help those who build complex NixOS configurations in GitHub CI.

The problem

Standard GitHub Actions runners have only ~20GB of free disk space, or so they would have you believe. If you’ve tried to build sophisticated NixOS or Home Manager configurations in CI, you might have encountered “no space left on device” error. A comprehensive workstation or server setup can consume 10-15GB, leaving precious little headroom :pinching_hand:

This space limitation meant I couldn’t build my full configurations in CI, preventing me from properly caching complete builds. Each change to my workstations and servers required frustrating additional compilation time for things like 3rd party kernel modules, Ollama, custom package overrides, and more :disappointed:

The solution: Nothing but Nix :axe::snowflake:

Nothing but Nix is a GitHub Action that transforms standard GitHub runners from ~20GB spaces into 65-130GB Nix powerhouses :muscle:

Here’s how it works:

  1. Initial Volume Creation: Creates a large BTRFS volume from free space on /mnt
  2. Background Purge: Ruthlessly eliminates unnecessary software to reclaim even more space, while your workflow runs
  3. Dynamic Growth: Expands your Nix volume as space becomes available

Technical implementation

The action uses loop devices with sparse files and a BTRFS filesystem:

# Create a large disk image in the free space
free_space=$(df -m --output=avail /mnt | tail -n 1 | tr -d ' ')
loop_dev=$(sudo losetup --find)
sudo fallocate -l $((free_space - 1024))M "/mnt/disk0.img"
sudo losetup "${loop_dev}" "/mnt/disk0.img"

# Set up an optimized BTRFS filesystem
sudo mkfs.btrfs -L nix -d raid0 -m raid0 --nodiscard "${loop_dev}"
sudo mount LABEL=nix /nix -o noatime,nobarrier,nodiscard,compress=zstd:1,space_cache=v2,commit=120

The nodiscard mount option is essential to prevent misreported allocation sizes when using loop devices backed by sparse files.

I’ve written The Nix Space Heist: Reclaiming 130GB in GitHub Actions blog post that goes into more detail :nerd_face:

Usage :wrench:

This action requires that it runs before Nix is installed. Add it before your Nix installation like so:

- uses: actions/checkout@v4
- uses: wimpysworld/nothing-but-nix@main
- uses: DeterminateSystems/nix-installer-action@main
- run: nix flake check

Would love to hear from others who try it out or have alternative approaches to this problem! :ear:

39 Likes
2

Great work !

What I do so far is

      - name: Get more storage space
        run: |
          sudo df -h
          sudo rm -rf /usr/share/dotnet
          sudo rm -rf /usr/local
          sudo rm -rf /opt
          sudo df -h

which gives me quickly 20GB, but your solutions is much smarter :slight_smile:

1 Like
3

If you use:

- uses: wimpysworld/nothing-but-nix@main
  with:
    hatchet-protocol: 'holster'

You’ll get a 65GB /nix volume in 1 second :stopwatch: with no additional purging required :slightly_smiling_face:

2 Likes
4

That’s so creative! Is it reliable? Even more savings if zstd compressed??

5

I’ve been testing it for the last few days. In short, yes. I think it is reliable, and if you use hatchet-protocol: 'holster' to side step the rampant butchering :axe: of the underlying Ubuntu host, it reduces the risk of incident significantly :slightly_smiling_face:

While testing, I encountered issues :bug: and had to work through them, see the commit history :grin: But I’m pretty confident it’s in a good place now. zstd might offer a benefit when using the lower yield purge strategies.

3 Likes
6

I’m using easimon/maximize-build-space@master for years now, are you able to provide more space?

Are you doing it generally different?

Can you give me an elevator pitch why I should use yours over another solution?

7

Thanks for your question about Nothing but Nix compared to easimon/maximize-build-space. Here’s where Nothing but Nix stands out:

Nothing but Nix can provide significantly more usable space:

  • Up to 130GB for your Nix store (with Rampage protocol)
  • Versus a maximum of ~95GB from maximize-build-space

Yes :slightly_smiling_face:

While both actions create additional storage, Nothing but Nix features:

  1. Nix-specific optimization: Designed from the ground up for Nix workflows, not as a general-purpose solution
    • Specifically engineered to squeeze out every byte for /nix
  2. Two-phase approach:
    • Immediate volume creation (~65GB in 1 second), a size maximize-build-space can only reach after a significant blocking period while it purges files with rm.
    • Background expansion (up to ~130GB total)
  3. Background processing: Purging happens without blocking workflow execution
    • Background purging continues while your workflow runs, rather than blocking it
  4. Reduces CI time: Uses rmz (from Fast Unix Commands), which outperforms standard rm by an order of magnitude
    • Parallel-processes deletions for maximum efficiency

Elevator Pitch :rocket:

“Nothing but Nix provides up to 130GB of purpose-built Nix storage by aggressively reclaiming space without delaying your workflow. It’s not just more space - it’s faster space immediately available while background optimizations continue working for you.”

While maximize-build-space is still deleting files, your Nothing but Nix powered workflow has already finished :checkered_flag::trophy:

5 Likes
8

Did you just write that with AI??

11 Likes
9

No. I looked through the action.yml from maximize-build-space and worked out how it differed from Nothing but Nix and reused some of the documentation I’ve already written in the reply.

1 Like
10

Hmm. I guess your reply to my initial comment sounded more human to me than that longer one about the differences to maximize-build-space

Especially this part:

… Sorry for coming across rude.

8 Likes
11

The action looks really cool and I’m definitely likely to try this out in the future. I’ve been thinking about using GA for nix CI for my config, but I always was worried about the 20GB limit for it. This will fix that problem.

Some feedback on the blog post: the constant use of emojis everywhere is extremely distracting and made it harder to read through for me than a normal blog post. They tend to have bright colors, and especially when placed in the middle of text, make it really hard for me to focus on actually reading without my eyes snapping to the emojis. Otherwise, I thought it was a good and informative blog post.

9 Likes