You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Honestly speaking, unofficial-builds is way down the priority list for the Build WG (it is after all unofficial). Having said that the unofficial-builds machine currently:
Runs a webhook to rebuild the containers when this repository is updated.
Runs a scheduled timer to build when Node.js releases come out.
Hosts the downloads.
I think 2 and 3 could potentially move to GitHub actions. If 1 and 4 can be done in a combination of R2 and the release worker and not require replacement Build WG servers then +1 from me. I think my only concern would be to separate out as much as possible from the official releases (i.e. do not reuse API keys/tokens between unofficial and official builds if possible).
I think my only concern would be to separate out as much as possible from the official releases (i.e. do not reuse API keys/tokens between unofficial and official builds if possible).
+1, I was thinking a dedicated unofficial-builds bucket for them. Also, just making sure, are there any symlinks used when hosting the downloads?
Idk if this is worth but given the current setup for the build scripts is rather single server & docker centric + the low priority on this, wdyt of pausing new unofficial builds, copying the current downloads to an r2 bucket, and decommissioning the server to free up credits for www? Then can later work on getting new builds working again through whatever works best
Docker Apline has not changed over to the official builds yet. I'd discurage any "temporary" moves without proper planning and understanding the impacts
I'll try to push forward nodejs/docker-node#2621 that will hopefully lessen any issues with the cutover, but I think we're still talking about after the next set of Node.js releases
We can retire it too, the only hard dependency that would need to be solved is the docker images, but they can build it themselves. Mostly this is just a convenience service for people with niche architectures, but having had to retire armv6l and x86 it's a poorer version of its once useful self IMO.
Activity
richardlau commentedon Oct 2, 2026
Honestly speaking, unofficial-builds is way down the priority list for the Build WG (it is after all unofficial). Having said that the unofficial-builds machine currently:
I think 2 and 3 could potentially move to GitHub actions. If 1 and 4 can be done in a combination of R2 and the release worker and not require replacement Build WG servers then +1 from me. I think my only concern would be to separate out as much as possible from the official releases (i.e. do not reuse API keys/tokens between unofficial and official builds if possible).
flakey5 commentedon Oct 2, 2026
+1, I was thinking a dedicated
unofficial-buildsbucket for them. Also, just making sure, are there any symlinks used when hosting the downloads?richardlau commentedon Oct 2, 2026
I don't think so. There's none I can see in https://unofficial-builds.nodejs.org/download/release/.
The server set up is in https://github.com/nodejs/build/blob/main/ansible/playbooks/create-unofficial-builds.yml with the specifics in https://github.com/nodejs/build/tree/main/ansible/roles/unofficial-builds. But most of the day to day logic is in the scripts in this repository.
flakey5 commentedon Oct 2, 2026
Idk if this is worth but given the current setup for the build scripts is rather single server & docker centric + the low priority on this, wdyt of pausing new unofficial builds, copying the current downloads to an r2 bucket, and decommissioning the server to free up credits for www? Then can later work on getting new builds working again through whatever works best
nschonni commentedon Oct 2, 2026
Docker Apline has not changed over to the official builds yet. I'd discurage any "temporary" moves without proper planning and understanding the impacts
nschonni commentedon Oct 2, 2026
I'll try to push forward nodejs/docker-node#2621 that will hopefully lessen any issues with the cutover, but I think we're still talking about after the next set of Node.js releases
MikeMcC399 commentedon Oct 4, 2026
rvagg commentedon Oct 5, 2026
We can retire it too, the only hard dependency that would need to be solved is the docker images, but they can build it themselves. Mostly this is just a convenience service for people with niche architectures, but having had to retire armv6l and x86 it's a poorer version of its once useful self IMO.
flakey5 commentedon Oct 5, 2026
If migrated to the release worker yes, a requirement for it is no breaking changes for the client
MikeMcC399 commentedon Oct 6, 2026
nschonni commentedon Oct 25, 2026
All the current release lines are now using the official builds, so there shouldn't be any impact to docker-node by the migration now.