# nixbuild.net blog nixbuild.net blog This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## OIDC support in nixbuild.net DevFeed: [OIDC support in nixbuild.net]() Original publisher: [Read original article]() Author: support@nixbuild.net Published: 2025-09-01T00:00:00Z Content type: tutorial Language: en Sources: [nixbuild.net blog]() Topics: [OpenID connect (OIDC)](), [GitHub Actions](), [Nix](), [Authorization](), [JSON Web Tokens](), [Authentication]() Tags: [authentication](), [authorization](), [github-actions](), [jwt](), [oidc]() ### AI overview This tutorial explains how nixbuild.net uses OpenID Connect and Biscuit policies to create authentication tokens that require an OIDC JWT from a specified identity provider. It demonstrates securing GitHub Actions workflows for Nix builds by creating a base token, deriving an attenuated token with OIDC conditions, and passing a GitHub-issued OIDC JWT to nixbuild.net. ### Source excerpt nixbuild.net now supports OpenID Connect (OIDC)! This means that you can create auth tokens that are only usable if you also can provide an OIDC JWT signed by a specific identity provider. In practice, you can now configure your GitHub Actions workflow with a nixbuild.net auth token that can only be used from within GitHub's infrastructure. You can even lock it down to specific GitHub repositories. This is a great step forward in securing nixbuild.net's authentication and authorization. This new feature is not specific to GitHub, but can be used together with any OIDC provider. Additionally, it is implemented on top of the existing Biscuit support in nixbuild.net. This further validates the usefulness and flexibility that nixbuild.net's Biscuit policies provide. Read on to find out exactly how it all fits together! A Usage Example Let's illustrate how OIDC works in nixbuild.net by working our way through a complete usage example. The repository used in this example is available for inspection at GitHub. Our objective is to configure a GitHub Actions workflow that uses nixbuild.net to perform Nix builds. We want to make use of OIDC to secure the nixbuild.net authentication and avoid the impact a workflow auth token leak could have. We have three steps to go through: Create a new nixbuild.net auth token with the base permissions needed for our GitHub workflow. Derive a new token from the original one, with a Biscuit policy that takes the OIDC context into account. This process is called attenuation and is done offline from nixbuild.net, on your local computer. Arguably, the nixbuild.net UI could offer a way to attach a Biscuit policy directly during token creation, but there is no such functionality yet. Create a GitHub Actions workflow that requests an OIDC JWT from GitHub and passes it on to nixbuild.net. Step 1: Create a Base Token Create a new nixbuild.net auth token using the nixbuild.net admin shell or the web UI. This token defines the "upper limit" of what our ## A Batch of nixbuild.net Updates DevFeed: [A Batch of nixbuild.net Updates]() Original publisher: [Read original article]() Author: support@nixbuild.net Published: 2024-10-16T00:00:00Z Content type: article Language: en Sources: [nixbuild.net blog]() Topics: [Self-hosted](), [Amazon EC2](), [Amazon Web Services](), [Provisioning](), [Cloud](), [builds](), [configuration]() Tags: [aws](), [builds](), [cloud](), [configuration](), [deployment](), [ec2](), [provisioning](), [self-hosted](), [self-hosting]() ### AI overview This blog post summarizes nixbuild.net updates, focusing on enterprise self-hosting. It describes an EC2 AMI-based deployment using NixOS, EC2 provisioning, and configuration files or cloud-init, with support for configurable builder instances and build provisioning. ### Source excerpt We have not written about nixbuild.net for over a year now, but that doesn't mean nothing has happened. Quite the opposite - we've been really busy! This blog post will try to summarize some of what we have been working on behind the scene the last couple of years. Read on to hear about nixbuild.net going enterprise, a brand new web UI and lots of new functionality! Self-Hosting nixbuild.net A big thing that has kept us busy the last year is packaging nixbuild.net for self-hosting inside enterprise setups. We've had a number of companies reaching out to us inquiring about such setups. The reason for wanting to self-host nixbuild.net are several: internal legal requirements, network bottlenecks, cost control and the ability to use hardware that is tricky to offer in the public service. One of our enterprise customers self-hosts nixbuild.net in production running 10K+ builds daily. A very welcome side-effect of adapting nixbuild.net for self-hosting is that many scenarios that are seldom or never triggered by users of our public service are uncovered by enterprise usage. This has made nixbuild.net even more reliable and capable under high load. We are in a stage where we are happy to work closely with companies, figuring out how to best deploy and integrate nixbuild.net into their environments. Our goal is to eventually be able to offer self-hosted nixbuild.net as an off-the-shelf product. Actually, if you are on AWS, the deployment of nixbuild.net is already very simple. We will publish a blog post with more details on this in the near future, but the short rundown is this: We provide an EC2 AMI that runs NixOS and all necessary nixbuild.net services. The user deploys this AMI using her preferred method of EC2 provisioning. The user provides nixbuild.net configuration through cloud-init or by simply putting configuration files in place on the EC2 instance. The nixbuild.net configuration includes details on what types of EC2 instances to use for running the builds, an ## nixbuild.net Expands Biscuit Token Usage with Signed Build Links and Access Policies DevFeed: [nixbuild.net Expands Biscuit Token Usage with Signed Build Links and Access Policies]() Original publisher: [Read original article]() Author: support@nixbuild.net Published: 2023-09-22T00:00:00Z Content type: release Language: en Sources: [nixbuild.net blog]() Topics: [API](), [Authentication](), [Authorization](), [Nix](), [builds](), [GitHub](), [Command-line interface]() Tags: [api](), [authentication](), [authorization](), [build](), [cli](), [github-action](), [http](), [ssh](), [web]() ### AI overview The article announces expanded use of Biscuit authorization tokens in nixbuild.net. It describes signed links for accessing build details and logs, advanced access policies, and token-based SSH authentication, with tokens restricted by permissions, expiration, and build-specific scope. ### Source excerpt About one year ago, we introduced an HTTP API for nixbuild.net. This API can be used to retrieve information about the builds you've run on the service. One place where the API is used is in the GitHub Action nixbuild-action to create detailed build summaries at the end of workflow runs. When the API was launched, it was using Biscuit auth tokens to handle authentication and authorization. In the initial implementation, we didn't really take much advantage of Biscuit, and basically used them as plain API keys. This week, however, we've finally expanded our Biscuit usage to properly take advantage of the flexibility offered. Read on to find out how this allows us to now support advanced access policies, token-based SSH auth and signed web links that gives easy access to build logs and fancy build reports. Signed Web Links Let's start out with the feature we're really happy to launch: signed web links. To show how it works, I grep for a broken package in nixpkgs and find one called textpieces. Then I try building it on my laptop which has been setup to use nixbuild.net as a remote builder (we need NIXPKGS_ALLOW_BROKEN=1 and --impure in order to force Nix to evaluate the broken package): $ NIXPKGS_ALLOW_BROKEN=1 nix build --impure nixpkgs#textpieces error: build of '/nix/store/s7ns32ymdf9iq44hpa62dkdbwlhvc7nx-textpieces-3.4.1.drv' on 'ssh://eu.nixbuild.net' failed: builder for '/nix/store/s7ns32ymdf9iq44hpa62dkdbwlhvc7nx-textpieces-3.4.1.drv' failed with exit code 1 error: builder for '/nix/store/s7ns32ymdf9iq44hpa62dkdbwlhvc7nx-textpieces-3.4.1.drv' failed with exit code 1; last 10 log lines: > upgrade: Use the '$' extern syntax introduced in blueprint 0.8.0 > at ../resources/ui/CustomToolPage.blp line 43 column 3: > 43 | .TextPiecesToolSettings tool_settings { > | ^ > error: Cannot convert 2.5 to integer > at ../resources/ui/Editor.blp line 45 column 26: > 45 | margin-bottom: 2.5; > | ^ > ninja: build stopped: subcommand failed. > [nixbuild.net] See this link for bui ## ARM Builds for All DevFeed: [ARM Builds for All]() Original publisher: [Read original article]() Author: support@nixbuild.net Published: 2022-08-18T00:00:00Z Content type: release Language: en Sources: [nixbuild.net blog]() Topics: [Arm](), [builds](), [Nix](), [x86]() Tags: [announce](), [arm](), [builds](), [free](), [linux](), [x86]() ### AI overview nixbuild.net has moved ARM (aarch64-linux) builds from Early Access to general availability for all users. ARM builds initially have the same pricing as x86-64 builds, though that may change in the future. Existing users can configure Nix through the documentation, and new accounts receive free build hours for ARM and x86-64 builds. ### Source excerpt Less than a year ago, we announced support for ARM (aarch64-linux) builds on nixbuild.net, for users that wanted to evaluate the feature in an Early Access phase. Today, we are thrilled to announce that all nixbuild.net users now can run aarch64-linux builds! For now, ARM builds are priced in the exact same way as x86-64 builds. This might change in the future. If you're already a nixbuild.net user, head over to the documentation to learn about how to configure Nix to run aarch64-linux builds on nixbuild.net. If you're not a user, register today and get started! Every new account gets free build hours that can be spent on both ARM and x86-64 builds. ## nixbuild.net Announces Remote Store Builds for Faster Nix CI DevFeed: [nixbuild.net Announces Remote Store Builds for Faster Nix CI]() Original publisher: [Read original article]() Author: support@nixbuild.net Published: 2022-03-16T00:00:00Z Content type: release Language: en Sources: [nixbuild.net blog]() Topics: [Nix](), [ci](), [build performance](), [GitHub Actions](), [Caching]() Tags: [build-performance](), [cache](), [ci](), [github](), [github-actions](), [ssh]() ### AI overview nixbuild.net announces support for remote store builds, an alternative Nix build mode intended to improve performance in some environments, especially hosted CI services such as GitHub Actions. The article describes how remote builders and stores work and reports a reduction in the best-case time of the company's slowest CI job from 20 minutes to 20 seconds after switching modes. ### Source excerpt Today we are announcing support for remote store builds in nixbuild.net. This is an alternative way of remote building in Nix, which can improve build performance greatly for certain types of environments. The biggest performance impact can be had in CI setups, especially in hosted CI services like GitHub Actions. By switching over our own CI setup (running on GitHub Actions) to this build mode we reduced the best-case build time of our slowest CI job from 20 minutes down to just 20 seconds, an amazing 60x speedup! No extra setup is needed, everything is already built into Nix and the feature is available to all nixbuild.net users right now. Read on to find out how to try this out on your own CI builds! Remote Builders vs Stores Usually, when Nix distributes builds, it sends them to one or more remote builder. These remote builders are just normal Nix machines, accessed over SSH by the Nix client. Since nixbuild.net tries hard to act just like a normal Nix machine from the outside, you can use nixbuild.net as a drop-in replacement for a remote builder. This is how nixbuild.net has worked from the very launch. Here is a brief iteration of what happens when Nix uses a remote builder to perform a build: Nix checks if the build result already is available in the local store or can be fetched from any configured substituter (binary cache). If Nix needs to run the build, it will first make sure that all dependencies (inputs), and their transitive closures, are in place in the local Nix store. This might mean it has to build the inputs, if there are no existing builds to be found. Once all inputs are locally available, Nix will select a remote builder machine that can perform the build, and then check if the builder has all build inputs in place in its store. If there are any missing closures, they will either be downloaded from a substituter directly to the remote builder, or uploaded from the local store to the builder. Now, Nix asks the remote builder to perform the bui ## KVM builds supported on nixbuild.net DevFeed: [KVM builds supported on nixbuild.net]() Original publisher: [Read original article]() Author: support@nixbuild.net Published: 2021-10-01T00:00:00Z Content type: release Language: en Sources: [nixbuild.net blog]() Topics: [Nix](), [builds](), [CI/CD](), [Testing](), [GitHub Actions](), [x86]() Tags: [builds](), [ci-cd](), [github-actions](), [kvm](), [testing](), [x86-64]() ### AI overview nixbuild.net announces early access support for KVM-based builds. The feature enables NixOS integration tests, is initially available only on x86_64-linux, and is supported in the nixbuild.net GitHub Action. ### Source excerpt Less than two weeks ago, we announced support for ARM builds on nixbuild.net. Today we are excited to announce another early access feature -- support for builds that use KVM! KVM support is something that almost no public CI/CD provider offers, so we are very happy to be able to make this available to our users. For NixOS users and developers, this is especially valuable since it makes it possible to run integration tests based on the powerful testing framework found in nixpkgs/NixOS. KVM builds are currently in an Early Access phase. If you want to try it out, contact us at support@nixbuild.net. Anyone is free to request access, but there might be waiting time depending on interest. During Early Access, KVM builds are priced and handled exactly as standard builds. The final pricing and price model for builds that require KVM has not been settled yet. So far KVM builds are only supported on x86_64-linux, not on ARM. Setup Once you've gained access to running KVM builds, configuring your Nix client is simple. You just need to mark your eu.nixbuild.net remote builder with the kvm system feature. And if you want to run NixOS integration tests you'll need the nixos-test feature too. For more detailed configuration descriptions see the documentation. KVM builds in GitHub Actions The nixbuild.net GitHub Action has been updated to support KVM builds too. If you've been granted access to KVM builds, all you have to do is to make sure you use the latest release of nixbuild-action. No extra configuration is needed to run KVM builds, or NixOS integration tests, in GitHub Actions. ## nixbuild.net now supports ARM builds! DevFeed: [nixbuild.net now supports ARM builds!]() Original publisher: [Read original article]() Author: support@nixbuild.net Published: 2021-09-20T00:00:00Z Content type: release Language: en Sources: [nixbuild.net blog]() Topics: [Nix](), [Arm](), [GitHub Actions](), [builds](), [ci]() Tags: [arm](), [builds](), [ci](), [github](), [github-actions](), [linux]() ### AI overview nixbuild.net adds Early Access support for aarch64-linux ARM builds. Users can configure it as a remote builder alongside x86_64-linux builds, and GitHub Action release v6 supports aarch64-linux builds for GitHub Actions. ### Source excerpt As of today, there is support for running aarch64-linux builds in nixbuild.net. This is a feature that has been requested by many of our users, and we are very happy to be able to provide this as part of our service. For the moment, ARM builds are in an Early Access phase. If you want to try it out, just drop us a line at support@nixbuild.net. Anyone is free to request access, but there might be waiting time depending on interest. During Early Access, ARM builds are priced and handled exactly as the standard x86_64-linux builds. The final pricing and price model for ARM builds has not been settled yet. Setup Once you've gained access to running ARM builds, configuring your Nix client is just as straightforward as for x86_64-linux builds. Just swap the system of your remote builder to aarch64-linux. You can use nixbuild.net for both x86_64 and ARM builds at the same time. For more detailed configuration descriptions see the documentation. Zero-config aarch64-linux builds in GitHub Actions Together with the new support for ARM builds in nixbuild.net, there's also a new release of the nixbuild.net GitHub Action. The release (v6) enables support for aarch64-linux for your GitHub builds. If you've been granted access to aarch64-linux builds, all you have to do is to add --system aarch64-linux or similar to your nix invocations inside your GitHub actions. It is of course also simple to run aarch64-linux builds from GitLab, Hydra or any other CI setup using Nix. Just add nixbuild.net as an aarch64-linux remote builder as described in the documentation. ## Data Science with Nix: Parameter Sweeps DevFeed: [Data Science with Nix: Parameter Sweeps]() Original publisher: [Read original article]() Author: support@nixbuild.net Published: 2021-04-26T00:00:00Z Content type: tutorial Language: en Sources: [nixbuild.net blog]() Topics: [Nix](), [Data Science](), [Simulation](), [builds]() Tags: [benchmarking](), [data-science](), [hpc](), [parameter](), [simulation](), [software]() ### AI overview This practical article explains parameter sweeps in scientific computing and their equivalent in software build matrices. It demonstrates how Nix and nixbuild.net can manage tasks involving many input-parameter combinations, including simulations, builds, and benchmarks. ### Source excerpt Parameter sweeping is a technique often utilized in scientific computing and HPC settings. In the mainstream software industry the concept is called a build matrix. The idea is that you have a task you want to perform with varying input parameters. If the task takes multiple parameters, and you'd like to try it out with multiple values for each parameter, it is easy to end up with a combinatorial explosion. This blog post gives a practical demonstration showing how Nix is a perfect companion for managing parameter sweeps and build matrices, and how nixbuild.net can be used to supercharge your workflow. My hope is that this text can interest readers that don't know anything about Nix as well as experienced Nix users. Use Cases In scientific computing, it is common to run simulations of physical processes. The list of things simulated is endless: weather forecasting, molecular dynamics, celestial movements, FEM analysis, particle physics etc. A simulation is usually implemented directly as a computer program or as a description for a higher level simulation framework. A simulation generally has a set of input parameters that can be defined. These parameters can describe initial states, environmental aspects or tweak the behavior of the simulation algorithm itself. Scientists are interested in comparing simulation results for a range of different parameter values, and the process of doing so is referred to as a parameter sweep. Parameter sweeping is often built into simulation frameworks. For simulations implemented directly as specialized programs, scientists will simply run the program over and over again with different parameters, collecting and comparing the results. When supercomputers are used for running the simulations, the job scheduler usually has some support for launching multiple simulation instances with varying parameters. In the software industry, the term build matrix is used to mean basically the same thing as parameter sweeping. Regularly, build matr ## Finding Non-determinism with nixbuild.net DevFeed: [Finding Non-determinism with nixbuild.net]() Original publisher: [Read original article]() Author: support@nixbuild.net Published: 2021-01-13T00:00:00Z Content type: tutorial Language: en Sources: [nixbuild.net blog]() Topics: [Nix](), [reproducibility](), [reproducible builds](), [builds](), [content addressed store]() Tags: [blog](), [blog-post](), [build](), [reproducibility](), [reproducible-builds]() ### AI overview This blog post explains how to use Nix repeated builds to detect non-deterministic outputs by comparing build results bit for bit. It also describes how nixbuild.net records repeated-build results and can help investigate failures from past builds. ### Source excerpt During the last decade, many initiatives focussing on making builds reproducible have gained momentum. reproducible-builds.org is a great resource for anyone interested in how the work progresses in multiple software communities. r13y.com tracks the current reproducibility metrics in NixOS. Nix is particularly suited for working on reproducibility, since it by design isolates builds and comes with tools for finding non-determinism. The Nix community also works on related projects, like Trustix and the content-addressed store. This blog post summarises how nixbuild.net can be useful for finding non-deterministic builds, and announces a new feature related to reproducibility! Repeated Builds The way to find non-reproducible builds is to run the same build multiple times and check for any difference in results, when compared bit-for-bit. Since Nix guarantees that all inputs will be identical between the runs, just finding differing output results is enough to conclude that a build is non-deterministic. Of course, we can never prove that a build is deterministic this way, but if we run the build many times, we gain a certain confidence in it. To run a Nix build multiple times, simply add the -repeat option to your build command. It will run your build the number of extra times you specify. Suppose we have the following Nix expression in deterministic.nix: let inherit (import {}) runCommand; in { stable = runCommand "stable" {} '' touch $out ''; unstable = runCommand "unstable" {} '' echo $RANDOM > $out ''; } We can run repeated builds like this (note that the --builders "" option is there to force a local build, to not use nixbuild.net): $ nix-build deterministic.nix --builders "" -A stable --repeat 1 these derivations will be built: /nix/store/0fj164aqyhsciy7x97s1baswygxn8lzf-stable.drv building '/nix/store/0fj164aqyhsciy7x97s1baswygxn8lzf-stable.drv' (round 1/2)... building '/nix/store/0fj164aqyhsciy7x97s1baswygxn8lzf-stable.drv' (round 2/2)... /nix/store/65 ## nixbuild.net's First Year: Stability Improvements and Build Result Reuse DevFeed: [nixbuild.net's First Year: Stability Improvements and Build Result Reuse]() Original publisher: [Read original article]() Author: support@nixbuild.net Published: 2020-12-29T00:00:00Z Content type: article Language: en Sources: [nixbuild.net blog]() Topics: [Nix](), [builds](), [Linux](), [Filesystems]() ### AI overview The article reviews nixbuild.net's first year, describing stability and performance improvements after general availability and new ways to reuse build results, including certain previously failed builds. ### Source excerpt One year ago nixbuild.net was announced to the Nix community for the very first time. The service then ran as a closed beta for 7 months until it was made generally available on the 28th of August 2020. This blog post will try to summarize how nixbuild.net has evolved since GA four months ago, and give a glimpse of the future for the service. Stability and Performance Thousands of Nix builds have been built by nixbuild.net so far, and every build helps in making the service more reliable by uncovering possible edge cases in the build environment. These are some of the stability-related improvements and fixes that have been deployed since GA: Better detection and handling of builds that time out or hang. Improved retry logic should our backend storage not deliver Nix closures as expected. Fixes to the virtual file system inside the KVM sandbox. Better handling of builds that have binary data in their log output. Changes to the virtual sandbox environment so it looks even more like a "standard" Linux environment. Application of the Nix sandbox inside our KVM sandbox. This basically guarantees that the Nix environment provided through nixbuild.net is identical to the Nix environment for local builds. Support for following HTTP redirects from binary caches. Even Better Build Reuse One of the fundamental ideas in nixbuild.net is to try as hard as possible to not build your builds, if an existing build result can be reused instead. We can trivially reuse an account's own builds since they are implicitly trusted by the user, but also untrusted builds can be reused under certain circumstances. This has been described in detail in an earlier blog post Since GA we've introduced a number of new ways build results can be reused. Reuse of Build Failures Build failures are now also reused. This means that if someone tries to build a build that is identical (in the sense that the derivation and its transitive input closure is bit-by-bit identical) to a previously failed build, nix