Node.js Build: the working group that owns CI, releases and nodejs.org

A repository of roles and permissions rather than code

The nodejs/build repository is described as better build and test infra for Node, and the README is where that shows up. It opens with a purpose statement rather than a usage guide.

The Node.js Build Working Group maintains and controls infrastructure used for continuous integration, releases, benchmarks, web hosting of nodejs.org and other Node.js web properties and more.

The mission is stated as providing Node.js Project and libuv with solid computing infrastructure in order to improve the quality of the software itself by targeting correctness, speed and compatibility and to ensure streamlined delivery of binaries and source code to end-users.

So the repository is the operational documentation for a working group. Its primary content is a list of people and what they are allowed to do.

The repository itself contains information used to set up and maintain the various pieces of Node.js Project infrastructure managed by the Build Working Group, and it is intended to be open and transparent, with an invitation to open an issue if any relevant information is missing.

The transparency point is deliberate and the mechanism is stated: if you see any relevant information missing please open an issue. That is a small design decision with a large consequence for a repository like this one, because the alternative would be that access knowledge lives only in the heads of the admins.

The primary language is recorded as Jinja, which is a clue about how the infrastructure is configured, and the licence field in the repository metadata is reported as unknown. The default branch is main, the last push was on 2026-10-20, and there are no GitHub releases.

Five separate admin roles, and the Jenkins servers they map to

The README lists the admin roles as separate sections, and the split is not arbitrary. Each role corresponds to a distinct system with its own blast radius.

The Infra Admins cover the general infrastructure, and the Jenkins Admins have admin access to https://ci.nodejs.org/. The Release Admins have access to release secrets, and the Release Jenkins Admins have admin access to https://ci-release.nodejs.org/. The GitHub Bot Admins cover the automation account that acts on the project's behalf.

That split is the substance of the governance. The release secrets role is the sensitive one, since that is what lets a release be signed, and the Release Jenkins is a separate server from the CI Jenkins so that a compromise of the main CI does not automatically give access to the release path.

The membership lists themselves are rendered with a comment marker that identifies the generating team, for example ncu-team-sync.team(nodejs/build-infra) for the infra admins and ncu-team-sync.team(nodejs/jenkins-admins) for the Jenkins admins. The README then explains where the source of truth is: above list is manually synced with the gpg member list, linking to the build/test gpg key list in the nodejs-private secrets repository.

The same note appears under the Release Admins list, pointing at the build/release gpg member list instead. So there are two separate membership authorities, one for the test and build secrets and one for the release secrets, and the README is a rendering of them.

The word manually is doing real work in that sentence. It tells you that a person updates this file, and it tells you that a mismatch between this file and the gpg lists is possible. The Build WG Members list and the Infra Admins list share most of the same names, which is consistent with a small group holding several roles.

The README also has an Emeriti section, listing former members including several long-time Node.js contributors, which tells you this working group has been running for a long time and that people do leave it.

The ARM clusters are the physical part of the story

The image at the top of the README is captioned with the ARM cluster, and the caption expands on it.

Some of the Node.js Build ARM resources: 3 generations of Raspberry Pi and other ARMv7 and ARM64 hardware.

This is the one part of the repository that is unambiguously physical hardware rather than configuration, and it is why the repository is not purely documentation. Node.js ships prebuilt binaries for Linux ARM targets, and those binaries have to be built and tested on the target architecture to be worth shipping, because a binary that only ever ran on an x86 builder is not a tested ARM binary.

So the ARM cluster exists to close a gap that cross-compilation alone cannot. You can compile ARM code on an x86 machine, but the point of a test cluster is running the result on the real processor, catching things like alignment differences, unaligned access handling and any libc or kernel behaviour specific to the architecture.

The listing of three generations of Raspberry Pi is telling in a specific way. A single generation would only tell you whether the current target works. Spanning three generations tells you whether the binaries work across the range of ARM devices users actually have, which for Node.js is the point of shipping them at all.

The Build WG Members list also includes an entry that is not a person, @node-forward-build, described as node-forward build infrastructure. That is a machine account standing in for automation, and its presence in both the WG members and the admin lists is a reminder that the role structure is shared between humans and the systems they run.

The infrastructure providers section at the bottom of the README begins by saying the Node.js Project is proud to receive contributions from many companies, both i, and the visible text is truncated there, so the specifics of those contributions are not available in this copy of the document.

Ansible, Jenkins and Orka are the three toolchains in the tree

The repository listing is where the tooling shows through, and there are three distinct technologies there.

There is an ansible/ directory along with an ansible.cfg at the root, and a .shellcheckrc alongside it. Ansible is the configuration management layer for the servers, which fits a working group that has to keep a fleet of build machines in a known state rather than configuring them by hand.

There is a jenkins/ directory, and the two Jenkins endpoints in the admin role list are the two systems it drives, the CI server at ci.nodejs.org and the release server at ci-release.nodejs.org. The separate directories for configuration and for the servers themselves are what let the release path be administered separately from the CI path.

There is an orka/ directory, and Orka is the virtualisation layer, which is where the ARM clusters fit, since those are virtual machines on real ARM hardware rather than bare machines.

There is also a backup/ directory, a doc/ directory, a tools/ directory and static-assets/ for the images used in the README itself. There is a .flake8 for linting the Python in the tooling, a .mailmap for identity mapping, and a .gitignore.

The Jinja language recorded as primary fits the Ansible directory, since Jinja is the template language Ansible uses for variable substitution in its playbooks and roles.

There is no install command to copy here, because this repository is not installed anywhere. The two Jenkins endpoints the admin roles point at are the closest thing to a starting point, and they are the systems an approved member would log into.

Admin access to https://ci.nodejs.org/.

The second one, for the release path, is a separate server.

Admin access to https://ci-release.nodejs.org/.

Two governance documents sit alongside the README, and they are the ones the README points to. GOVERNANCE.md is referenced for understanding the process and reasoning used for granting access to the resources we manage, and there is an ONBOARDING.md and an OFFBOARDING.md at the root, which together suggest that joining and leaving this working group is a documented procedure with steps on both sides.

That is the practical answer to how someone gets access. Access to the Node.js CI is not something you request in an issue and receive; it is granted through a process described in GOVERNANCE.md, and the same repository that lists the admins also describes how to become one.

Where nodejs/build is the wrong tool

The first wrong-tool case is someone looking for a Node.js build tool. The description says better build and test infra for Node, and it is tempting to read that as a tool that improves your own project's builds. It is not. The infrastructure here is the Node.js project's own: the CI servers that build Node itself, the release signing path, the web properties. Nothing in the repository is a general purpose improvement to your build pipeline.

The second case is a developer who wants to reproduce a Node.js CI failure locally and expects configuration from here. The Jenkins setup in the tree is for the Node.js project's servers, with its own plugins, its own secrets and its own provider accounts. There is no supported path for running that configuration yourself.

The third case is a team that expects an open source contribution model. The repository is intended to be open and transparent, and the README asks you to open an issue if you see any relevant information missing, which is a genuine invitation. But the resources themselves are not contributed to. Access to ci.nodejs.org and to the release secrets comes through a process documented in GOVERNANCE.md, and the membership lists are synced from gpg member lists held in a separate private secrets repository. So the transparency is about the governance, not about the infrastructure.

There is a fourth case that is less obvious. The repository has no GitHub releases, and its content is largely a list of people and their access levels. That means the document ages in a specific way: it changes when the membership changes, and the README says the lists are manually synced with the gpg member lists. If you read it as a current source of truth about who can do what, you are relying on a manually maintained mirror. The gpg lists in the private repository are the actual authority.

That also means the repository is not the right place to look for a technical answer about how a build is configured. The doc/ directory exists, but the README's role is orientation: what the working group owns, who holds which role, and where to go next. Someone expecting a wiki of build configuration will find a directory listing and a set of names.

On licence, the licence field in the repository metadata is reported as unknown. For a repository of governance documents and configuration, that is a smaller issue than it would be for a library, but it does mean there is no stated licence text at the root for the Ansible playbooks or the Jenkins configuration, and anyone who wants to reuse those files should ask rather than assume. There is a .mailmap file, which is a sign the project takes identity hygiene seriously for a repository full of contributor names.

Editorial conclusion

nodejs/build suits a contributor who wants to understand who owns which piece of Node.js infrastructure and how to get access to it, because the README is a map of roles rather than code. It does not suit anyone looking for a reusable build tool, since the configuration here is specific to the Node.js project's own servers and secrets. Before acting on anything in it, read GOVERNANCE.md and ONBOARDING.md as the README points out, since access to these resources is granted through a process rather than by opening a pull request.

Frequently asked questions

Official sources

1. Issues
2. nodejs/build on GitHub
3. README