is the cloud service that runs your Nix builds. It takes away the effort of maintaining and scaling build clusters, and integrates easily with any setup that uses Nix.

Typical Users

Development Teams

Teams can maximise resource usage by letting all developers and CI systems use the same, infinitely scalable pool of remote builders. Build artifacts are automatically reused, without having to setup any binary caches. Say goodbye to high-maintenance inhouse build farms that always seem either underutilized or overutilized!

Road Warriors allows developers with modest compute power available (e.g. laptops) to easily run large numbers of resource-intensive builds, concurrently! Configuring Nix to use is trivial, and no other software is needed on your computer.

OSS Projects

An organization can use for continuous builds, allowing its users to fetch build results without having to configure anything else than a account. There is no need for users to set up any binary cache or trusted signing keys for this. You can read more about how this works, and why it is safe for to reuse build results like this on our blog

Core Values


Getting started with 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 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 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 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.


The pay-per-use price model of 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. tries hard to avoid building by re-using results or fetching from binary caches, whenever it is safe to do so.

Register Now - Get Started for Free!

Register and start building today. Each new account includes 25 CPU hours of build time for free so you can try out the service on your own terms, without committing to anything. No credit card is needed for registration.

  • Your email address. An activation link will be sent to this address.
  • Your unique account name is used in URLs etc. Lower case alphanumeric characters only.
  • Your public SSH key of type Ed25519. See instructions. Keys can be added and removed later on.

Pricing costs 0.12 EUR (excl. VAT) per CPU hour. You're billed monthly for the CPU hours your builds have consumed. If you don't use the service, no further costs will be incurred.

The exact details around how the CPU time of a build is calculated and how billing is handled is defined here

The pricing is introductory, and will likely be followed by other pricing models (volume rebates, subscription plans etc) in the future. The hourly rate may change during billing periods.


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 25 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 billing details. This means that there will be no surprise expenses by signing up for and trying it out.

Once your account is activated, you should read through the Getting Started guide to setup your system for using

How do I administer my account?

You administer your account through the 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, see how many build hours you have consumed and manage billing.

How are payments handled?

After your account has been activated you can enable billing at any time you like. Once you have enabled billing, and only then, will you be able to use the service beyond the initial free build hours.

You enable billing through the shell. When doing this, you will be directed to a web page hosted by Stripe, where you'll enter your billing address and credit card details.

After this, Stripe will charge your credit card monthly for any (non-free) build hours consumed.

The exact details around cost calculation and billing are defined here

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 consumes around 30 CPU hours, yielding a total cost of around € 3.60, or an average cost of € 0.028 per build.

Can multiple users share the same 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 account, the build result will simply reuse that build result. This is ideal for development teams.

Where is hosted? 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

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, 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 to hang on to previous build results. This would make it possible to use both as a remote builder and as a binary cache, if desired.

How are builds secured? uses KVM-based virtualization to isolate builds from each other. A build sandbox has been developed specifically for 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 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 cannot control its CPU allocation. Instead, 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 runs in-memory only, with nothing written to disk. This gives your builds both increased performance and security.

Can I use together with my own private binary cache?

Yes. A build performed on 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, which would make such setups even simpler and more performant.

What platforms are supported by

Today, only x86_64-linux builds are supported. In the future, more platforms will be supported.

Can I run builds using KVM virtualization on

No, KVM virtualization inside is not supported today. Work is underway to make it possible.

Does work together with Hydra?

Yes. Since behaves exactly as an ordinary remote Nix builder, it works with any setup using Nix. You can add as a worker to Hydra and configure it to accept a large number of concurrent jobs, since automatically scales up.