In previous blog posts, we’ve talked about how we speed up Devbox installs by fetching package closures directly from the official Nix Cache. This blog post will dig a bit more into how a Nix cache solution works, and how it can speed up your package installation time. In addition to covering the official Nix cache, we’ll talk about how you can integrate the Jetify Cache with Devbox to speed up your shells and share your custom packages across your team.
Building Reproducible Packages with Nixpkgs
The Nixpkgs repository provides over 100,000 packages, and supports multiple architectures and operating systems. Nix packages define all their requirements and dependencies within their build definition, making them reproducible and isolating them from the dependencies on your host machine. This means you can install multiple versions of the same Nix package on the same machine without conflicts.
This isolation comes with a trade-off. Due to the unique way Nix defines packages, it can't simply download upstream binaries. Instead, it needs to ensure the package links its dependencies in the Nix store correctly. The only way to guarantee a package does this is to build the package and it’s dependencies from source, and link it’s dependencies within the Nix store.
All that building can add up. Building a package like MongoDB can take up to 30 minutes, and that's just for MongoDB. Building a full closure from source can take hours, and updating a dependency in the graph means you have to rebuild the whole universe. All that building leads to the obligatory XKCD comic:
Speeding up Installations with Nix Package Caches
Fortunately, Nix's reproducibility and isolation also makes it easy to share and reuse the build outputs of packages. Each Nix package has a unique store path determined by the hash of its inputs. This unique store path means Nix can identify and reuse build outputs easily.
This reuse happens in two layers:
Nix can reuse existing packages and outputs in your Nix Store. When Nix starts building your package's dependencies, it first checks if a package with the correct store path exists in your local store, and then reuses that store path. The Nix Store enables sharing packages on a single machine, but you'll need a different layer if you want to share across machines.
To share across machines, you need a Nix Cache. If someone is building and pushing the packages you need to a cache, you can skip building and download precisely what you need. Developers can configure multiple Nix caches as "substituters," which tell the Nix Daemon where to look for “substitute” store paths that aren't in their current Nix store.
The largest cache is the Public Cache maintained by the NixOS Foundation. The Foundation knows that users want to avoid constantly rebuilding, so they build most of Nixpkgs packages in Hydra (Nix’s CI build system) and push them to the public cache. For the most popular binaries and platforms, the Nix Public Cache has you covered.
The public cache does have some gaps, however, that your project can fall into
Packages outside the Nixpkgs like custom packages on our machine or flakes hosted in public repositories.
Packages such as MongoDB, Terraform, and Vault aren't hosted in the Nix cache because they lack an open-source license.
Older packages, or packages on less popular platforms, can be garbage collected or excluded from the public cache.
For this reason, many developers set up their own Nix caches to use as substituters for their custom packages. Technically, any machine running Nix can serve as a cache or substituter for another machine. If you're trying to support a team, however, managing issues like trust, access control, and populating the cache with the latest packages can take a lot of extra effort and development.
Jetify Cache: A Package Cache designed for Devbox and Nix
For teams that want a cache without the extra overhead, we built the Jetify Cache. Jetify Cache is an enterprise grade Nix Cache that integrates nicely with Devbox, so you can speed up your shells with little extra effort.
Our Jetify Cache offers two solutions that can help your team develop faster:
For packages in Nixpkgs that are not available in the Nix Cache, we offer the Jetify Prebuilt Cache. This provides prebuilt versions of packages not in the official Nix Cache. If you have a Jetify Cloud account, Devbox will automatically configure the Prebuilt cache as a substituter. When Devbox prepares to install a package, it will use the Prebuilt cache if there are any gaps in your local Nix Store or the official Nix cache.
For your custom packages and flakes, we offer the Jetify Private Cache. Jetify Privat Cache lets you share binaries across all your devices and developers. After you build your Devbox project (either locally, or in CI), you can run
devbox cache uploadto push the entire closure of your project to the cache. Developers who share your Jetify Cloud Project can then easily download their packages from the cache without building from source.
Devbox: Optimized for Nix Package Caching
Devbox can automatically configure the Jetify Cache caches for you when you authenticate with Jetify Cloud With the Jetify Cache enabled, you now have 4 layers where Devbox and Nix can check for binaries before building from source:
The Nix Store (`/nix/store`)
Your Jetify Private Cache
The Official Nix Cache (cache.nixos.org)
The Jetify Prebuilt Cache.
As mentioned above, Devbox can install packages by copying them directly from the cache, without needing to re-run evaluation steps. We do this by retrieving the store paths directly from Nixhub (our Nix Package Search engine) at install time, and then save the store paths in our devbox.lock file. With this optimized cache experience, you can start reducing your installation times in seconds.
