Repository navigation
Pull Alpine/aarch64 tarball from unofficial builds as we do for Alpine/x64 #2475
Description
Although unoffical-builds does produce an arm64 binary, it is not used by the images here. I think mixed among the recent-ish discussions was whether we should just drop even that pre-built, and just use the Docker infrastructure for all the Alpine variants.
While there are reasons that i won't go into here why that might be desirable, IMHO that would push it further away from the "regular" tier1/2 platforms. Since we're building it anyway (and people are downloading it independently of the docker images at a rate of about 1000/hour) I'd prefer the container image to have the identical build that we produce in the unofficial projects.
I'll spin off another issue about whether to process the unofficial Alpine/aarch64 built in the same way as Alpine/x64 since that's separate from Alpine/s390x.
Originally posted by @sxa in #2462 (comment)
The Alpine/aarch64 builds are far less popular than the figure listed above but since nodejs/unofficial-builds#189 got merged we do now now have cross-compiled builds of Alpine/arm64 in the unofficilal-builds alone with x64 so we could follow the same process for both.
Notes:
- It's cross compiled instead of build natively (May not be an option, but we don't have any cross-compiled builds yet which have the rust support working for temporal enablement yet ... But that's potentially a bigger problem). It's also a cross-compiled build which doesn't undergo any testing elsewhere in the node system. Single Executable Application segfaults on musl builds but works on official node:alpine on arm64 unofficial-builds#200 is a potential issue with the cross-compilated build (SEA failure)
- There is a proposal to bump Alpine up to tier 2 which would change things again
- With the removal of Alpine/s390x from node 26's container images, and Alpine/ppc64le having been removed some time ago, that only leaves Alpine/arm64 as the "dynamically built at image creation time" platform so this would ultimately help reduce complexity in the process.
Activity
nschonni commentedon Apr 21, 2026
I opened a PR to show how it could look. I'm not sure if it wouldn't be better to just drop the Unoffical Builds and let them be fully built by the Docker infrastructure
sxa commentedon Apr 22, 2026
While there are various issues with the unofficial builds project, my concern with the mechanism that builds the runtime with the dockerhub infrastructure is because since we are distributing tarballs we'd effectively end up with two separate builds with potentially different behavior if we don't populate the containers and tarball builds with the same contents.
Since we have approximately 1000 downloads per hour of the Alpine/x64 tarballs there are still (surprisingly? Maybe...) a good number of people are not consumin this via the container images so I wouldn't want to just drop those.
Of course, the real best option here would be for Alpine to become a tier 2 platform ;-)
MikeMcC399 commentedon May 7, 2026
MikeMcC399 commentedon May 7, 2026
On reflection about this point, I believe that might expose the Docker team here to musl build issues that they aren't necessarily equipped to resolve. That would be very undesirable.
Right now, this repo only tries to build Alpine images if https://github.com/nodejs/unofficial-builds successfully builds
node-vxx.xx.xx-linux-x64-musl.tar.xz. It uses this image for theamd64builds, and assumes thatarm64building from source will also work.If the Dockerfiles are set up to build completely from source and unofficial-builds are ignored, it could show up as build issues here.
If the success of unofficial-builds for musl builds are used as a prerequisite to start building from source here, then it seems that would end up being redundant and possibly conflicting.
MikeMcC399 commentedon Jul 1, 2026
This would become obsolete if Alpine is promoted to Tier 2, since unofficial builds would presumably no longer be used by
docker-nodeIn this case only the
x64-muslbuild would be Tier 2, and so it would make sense to continue to cross-compile from this build for other non-x64 architectures, instead of adding a dependency on unofficial buildsarm64-musl.MikeMcC399 commentedon Jul 31, 2026
It would be difficult to integrate this proposal into the changes needed for promotion of Alpine amd64 to Tier 2.
Alternatives:
I suggest to drop this proposal, given that it is likely for the Alpine amd64 promotion to Tier 2 to be implemented soon.
MikeMcC399 commentedon Oct 7, 2026
This is obsolete, following merge of #2621
nschonni commentedon Oct 8, 2026
I agree. I think that if we get some interest/movement about upstream official ARM builds, we can spin up a new issue and also reference this prior discussion