Tracking issue for official Node.js build with pointer compression enabled

Official Node.js build with pointer compression enabled

Summary

This is a fresh tracking issue to try to give pointer compression (PC) for an officially shipped Node.js build some renewed traction, as the previous tracking issue was closed by @cjihrig with "If anyone needs this issue, please open a new one." This is that new issue.

I am not familiar with the internal build/release machinery, so I cannot judge exactly what needs to happen here. I am opening this mainly because the topic seems to have stalled, while there is now concrete evidence it works, and I would like to see if it can move forward again.

It picks up two now-inactive threads:

• https://github.com/nodejs/build/issues/3204 ("Path to adding a Tier 2 build with pointer compression enabled") - closed 2024-09-25 by @cjihrig with "If anyone needs this issue, please open a new one."
• https://github.com/nodejs/node/issues/55735 ("Pointer Compression and Isolate Groups") - auto-closed 2026-04-26 as stale.

Since those threads went quiet, the key technical blocker has moved forward: IsolateGroups landed (https://github.com/nodejs/node/pull/60254, merged 2025-10-17). That removes the historic "process-wide 4 GB cage" objection by giving each isolate group its own pointer cage. With that in place, the conversation about an official build seems worth reopening.

Why now

• The memory upside of pointer compression is well documented (https://v8.dev/blog/pointer-compression).
• IsolateGroups (https://github.com/nodejs/node/pull/60254) mean a PC build no longer caps the whole process at 4 GB. Each worker thread can run in its own 4 GB cage.
• A working, benchmarked PC build already exists in the wild. Platformatic shipped node-caged (https://github.com/platformatic/node-caged), pre-built multi-arch (amd64/arm64) Docker images for Node.js 25 and 26 with pointer compression + IsolateGroups enabled, with published end-to-end benchmarks: https://blog.platformatic.dev/we-cut-nodejs-memory-in-half. This shows a PC build on current Node.js is viable today and delivers a large, measurable benefit.

Concrete real-world demand: memory-constrained / embedded Linux

We run Node.js on memory-constrained embedded Linux hardware (arm64), where the V8 heap footprint is a hard limiting factor. RAM is fixed and not expandable, so every byte the runtime saves is headroom we can give back to the application. Cutting the heap roughly in half (as the Platformatic numbers show) directly translates into running more, or larger, workloads on the same device, and into fewer out-of-memory failures.

For this class of deployment the typical objection ("just buy more memory") does not apply, and the 4 GB-per-isolate cap is a non-issue. This is the kind of workload that benefits most from an official, maintained PC build, rather than each vendor maintaining their own breakage-prone fork.

Open question

Given that IsolateGroups have landed and a working, benchmarked PC build now exists, what would it actually take to get an official Node.js PC build moving again, and how can we give this effort some traction?

No source file or test is named. Start by reading the previous build issue #3204 and Node.js PR #60254, then compare the existing node-caged build and its benchmarks. Done would require a defined, agreed path for producing and maintaining an official pointer-compression build.