Simple
Getting started with nixbuild.net is simple. It works just like
any other
remote Nix builder, and you set it up in exactly the same simple way.
This also means that nixbuild.net can be used anywhere you use Nix. You
can use it on single machines or on CI servers, no matter how you use
Nix.
Simplicity also extends to pricing. You pay for the time your builds
consume, with no subscription costs.
Performant
nixbuild.net has been designed from the ground up to be as performant as
possible.
Builders are allocated on demand, meaning you never have
to worry about slowdown even when running large numbers of concurrent
builds.
An innovative feature of nixbuild.net is
automatic resource allocation
By looking at historic usage, each build is assigned CPUs and
memory that give you the best balance between price and performance.
Cost-effective
The pay-per-use price model of nixbuild.net means you don't have to
pay for build servers that most of the time are either underutilized or
overutilized. Instead, you pay for the build time you use, while having
infinite scalability readily available.
The cheapest build is the one that you don't even have to run.
nixbuild.net tries hard to avoid building by re-using results or fetching
from binary caches, whenever it is
safe
to do so.
What happens after I've filled out the registration form?
Shortly after you've submitted the form you'll receive an email with an
activation link. As soon as you've activated your account, you can start
running Nix builds. Since every account includes
50 free CPU hours,
no cost is incurred until the free build time has been consumed. When
that happens, you'll get a second mail asking you for invoicing details.
This means that there will be no surprise expenses by signing up for
nixbuild.net and trying it out.
Once your account is activated, you should read through the
Getting Started guide
to setup your system for using nixbuild.net.
How do I administer my nixbuild.net account?
You administer your account through the
nixbuild.net shell.
This is a simple text-based shell accessible directly over ssh, no
installation needed. Through the shell you can add/remove ssh keys, list
details about your builds and see how many build hours you have consumed.
There are plans on also providing a web-based administration
interface.
What does a typical build cost?
Since builds and their resource requirements vary wildly, it is
difficult to give a general answer. However, if you make a low-level
change in nixpkgs (changing
the stdenv) and then build the Linux kernel, you will trigger
the build of about 130 packages (the kernel plus all of its dependencies).
Building those 130 packages on nixbuild.net consumes around 30 CPU hours,
giving a total cost of around € 3.60, or an average cost of
€ 0.028 per build.
Can multiple users share the same nixbuild.net account?
Yes. You're free to add as many public ssh keys as you like to your
account. This means multiple users (including "virtual" users like CI
runners etc) can use the service. Furthermore, if a user tries to build
a Nix derivation that already has been built by any user of the same
nixbuild.net account, the build result will simply reuse that build
result. This is ideal for development teams.
Where is nixbuild.net hosted?
nixbuild.net is served from Germany. As the userbase grows, there will
be more endpoints in other regions, to optimise latencies and bandwidth for
everyone.
For how long are build results kept in nixbuild.net?
If you build something that you or some other user built recently,
you can expect the build result to be reused without having to rebuild.
This is also true for build dependencies that have been uploaded or
fetched. Today, there is no formally defined limit for how long build
results are kept. Instead, nixbuild.net tries to optimise the overall
build performance for its users.
There are plans on offering additional pricing models where the user
can decide for itself how much storage to use in nixbuild.net to hang
on to previous build results. This would make it possible to use
nixbuild.net both as a remote builder and as a binary cache, if desired.
How are builds secured?
nixbuild.net uses KVM-based virtualization to isolate builds from each
other. A build sandbox has been developed specifically for nixbuild.net.
This sandbox makes sure that a build has no network access and no physical
disk access. A virtualized file system makes sure that the build only
has access to its specific dependencies.
The sandbox also guarantees that each build is pure and
repeatable. This means that a build that runs on nixbuild.net cannot produce
output influenced by sources not explicitly defined in
its dependencies (inputs).
Build dependencies and results are only shared with other users of the
same account, or with accounts that explicitly have been marked as
trusted. No other accounts can access the dependencies or results of a
build.
Read more about privacy
here.
What CPU limits are imposed on my builds?
In general, a build submitted to nixbuild.net cannot control its CPU
allocation. Instead, nixbuild.net will
automatically allocate
1–16 virtualized CPUs for it. The upper CPU limit might change in
the future. Each vCPU is mapped to a dedicated hyperthread, no CPU threads
are shared between builds.
How much memory can a build use?
There is no formally defined memory limit for builds. If a build should
run out of memory it will be restarted with more memory, without any
interaction needed from the end user. The reasoning behind this behavior
is that builds are usually compute-bound, not memory-bound. However, the
memory usage of each build is monitored, and if repeated excessive memory
usage is noticed, the responsible account owner will be contacted.
Also note that all intermediate artifacts produced by a build, along
with the final build result, count towards the build's total memory usage.
This is because each build on nixbuild.net runs in-memory only, with
nothing written to disk. This gives your builds both increased performance
and security.
Can I use nixbuild.net together with my own private binary cache?
Yes. A build performed on nixbuild.net behaves just like any other
Nix build. This means that you can upload the resulting artifacts to your
own cache or to any third-party cache service just as usual.
There are plans on supporting cache uploads directly from nixbuild.net,
which would make such setups even simpler and more performant.
What platforms are supported by nixbuild.net?
Today, only x86_64-linux builds are supported. In the
future, more platforms will be supported.
Can I run builds using KVM virtualization on nixbuild.net?
No, KVM virtualization inside nixbuild.net is not supported today.
Work is underway to make it possible.
Does nixbuild.net work together with
Hydra?
Yes. Since nixbuild.net behaves exactly as an ordinary
remote Nix
builder, it works with any setup using Nix. You can add nixbuild.net
as a worker to Hydra and configure it to accept a large number of
concurrent jobs, since nixbuild.net automatically scales up.