Resource Selection

nixbuild.net tries to automatically select optimal resources for each build, minimizing both build time and unused CPU time. What it means for you as a user is that the builds will be as cheap and fast as possible, without you having to do anything.

The maximum number of CPUs a build can be allocated varies depending on how the nixbuild.net build cluster is configured for the moment. If you want to limit the number of CPUs your builds can be allocated you can use the max-cpu and min-cpu settings. Note that there are no guarantees your builds will actually be given your configured max-cpu limit, since the current infrastructure might impose a lower limit.

If nixbuild.net can't make an informed decision on resource allocation, the build will be assigned 2 CPUs (configurable with the default-cpu setting).

The builds will be allocated as much memory as needed, but if a build uses an excessive amount of memory it can be cancelled. The exact memory limits are not published, and can vary over time and between different build platforms (Arm vs x86). In nixbuild.net, the memory allocated to a build is used both for the build's RAM requirements, but also for the storage of build output (both intermediate and final). If a build runs out of memory it will automatically be restarted with more memory, without affecting your Nix client. You will not be charged for the time spent by the build that ran out of memory, but if your build runs out of memory when it already has been allocated the maximum amount of memory available you will be charged for that run.

You can configure memory limits using the max-mem and min-mem settings. Setting a higher min-mem limit can sometimes be useful for specific derviations that you know more memory.

How Does it Work?

The automatic resource optimization works in two steps:

1. When a Nix derivation is submitted to nixbuild.net, we look for similar derivations that have been built on nixbuild.net before. A heuristic approach is used, where derivations are compared based on package names and version numbers. This approach can be improved in the future, by looking at more parts of the derivations, like dependencies and build scripts.

2. A number of the most recent, most similar derivations are selected. We then analyze the build data of those derivations. Since we have developed a secure sandbox specifically for running Nix builds, we're also able to collect a lot of data about the builds. One metric that is collected is CPU utilization, which lets us make predictions about how well a build would scale, performance-wise, if it was given more CPUs.

We also look at metrics about the historic memory usage to make sure the new build is allocated enough memory.