Build Linux binaries for Node.js 26 on RHEL 9

[richardlau]

The next semver-major of Node.js, 26, is scheduled to be released next April (2026) and planned to be supported until April 2029.

We are currently building Linux binaries for Node.js (Node.js 25, 24, 22 and 20) on RHEL 8. RHEL 8 is scheduled to end maintenance support in May 2029.

I'm proposing that we shift building the Linux binaries for Node.js 26 onwards to RHEL 9 (maintenance for that planned to end in May 2032). This would mean that the glibc requirements to run the official Linux binaries would raise from glibc 2.28 to 2.34 which will affect compatibility on popular Linux distributions:

Distribution	glibc	Supported if binary built on RHEL 9
Debian 10	2.28	❌
Debian 11	2.31	❌
Debian 12	2.36	✅
Debian 13	2.41	✅
RHEL 8	2.28	❌
RHEL 9	2.34	✅
RHEL 10	2.39	✅
Ubuntu 20.04	2.31	❌
Ubuntu 22.04	2.35	✅
Ubuntu 24.04	2.39	✅

FWIW the GitHub Actions hosted Ubuntu 20.04 runners were retired earlier this year.

[richardlau]

Okay I got the date wrong. Node.js 26 goes End-of-Life in 2029, just before RHEL 8's end of maintenance.

A secondary reason I had for this proposal would be to simplify things for Linux on s390x and ppc64le. Support for Power 8 and z13 are being dropped from upstream V8 and currently the set up for, e.g. ppc64le, is:

• All rhel8-ppc64le are Power 8
• All rhel9-ppc64le are Power 9

so for Node.js 26, switching to RHEL 9 would be least disruptive in terms of not having to reprovision/come up with new labels to distinguish the Power 8 vs Power 9 machines.

Another potential simplification is that it would reduce the number of machines we'd need to install rust on for temporal support.

[targos]

Is there a world where using glibc 2.28 on RHEL 9 is an option?

[targos]

I guess we could use a container?

[sxa]

Is there a world where using glibc 2.28 on RHEL 9 is an option?

Absolutely yes it's technically possibly, but you'd need to have the older glibc headers and libraries available, and modify the build process to pick them up. So it becomes a matter of where you source them from. You could pull the latest ones CentOS Stream 8 (or even CentOS7 if you wanted to go back further) although there's always the chance that you still end up with other libraries on RHEL9 that wouldn't be on earlier distributions (although I'd need to check to see how many other things come from the system - possibly not a huge amount for node)

I'm not sure if we'd want to go down the route of making such modifications to the build process here although the other large project I work on does take such an approach.

I guess we could use a container?

I'm not quite clear on how that would help in itself ... Are you suggesting building in a EL8 container on RHEL9? Otherwise an EL9 container would still need the older glibc installed and referenced as per what I said above. I suppose you could try and build an EL9 container with the system glibc replaced with an earlier one so it gets picked up automatically but that sounds like something that would potentially cause all sorts of trouble :-)

[targos]

Are you suggesting building in a EL8 container on RHEL9?

This

[sxa]

I think at that point I'd personally just suggest we RHEL8 natively if we want that level of compatibility. Not sure there's too much benefit to doing it in a container...