Fails to install node binary when running in docker on apple silicon

[mmmmmrob]

Describe the bug
The buildpack fails while attempting to install node when running in docker on apple silicon.

The expected behaviour is that the binaries install correctly.

To Reproduce
Steps to reproduce the behavior:
On an apple silicon machine with docker desktop installed:

1. Download the Dockerfile.txt
2. Remove the .txt extension
3. run docker build . --platform=linux/amd64
4. See error fail.log

Versions (please complete the following information):

• heroku-20
• node 14.x
• NPM or Yarn Version: [e.g. Yarn 1.22.10]
• latest (https://github.com/heroku/heroku-buildpack-nodejs/archive/refs/tags/latest.zip)

Additional context
Running heroku:20 and the buildpack in docker to create heroku-like runtime environment for local dev.

.

[joshwlewis]

Yeah, it looks like we'll try to download the x64 binaries.

We really only support darwin so that we can test this buildpack locally. Nobody on the team has an M1 yet, so this isn't a big priority, though I'd entertain a PR.

It looks like the bug could be fixed by changing the architecture calculation here:

heroku-buildpack-nodejs/cmd/resolve-version/main.go

Lines 142 to 147 in 39e4b17

	func getPlatform() string {
	if runtime.GOOS == "darwin" {
	return "darwin-x64"
	}
	return "linux-x64"
	}

(It should return darwin-arm64 for M1 macs)

[jaygould]

Returning darwin-arm64 to the getPlatform() fn didn't solve this for me. Are there any other solutions?

[abarke]

This would be really awesome to support multiple platforms. In our use cases specifically M1 and AWS Graviton architectures.

We use heroku buildpacks and can now deploy to AWS Graviton processors. If the buildpack was able to detect the platform and binary to install that would be incredible 😃

Or perhaps the simplest approach for now would be to set an environment variable like NODE_PLATFORM=linux-arm64 that would pull the node distribution for ARM v8 🚀

NODE_PLATFORM would then default to the existing platform binary. This would ensure backwards compatability.

Would this work? Any thoughts? @jmorrell @edmorley @joshwlewis 🤔

For those engineers who support Sustainable Engineering 🌞 and Green Software 🌳 this would be a big deal as this would allow engineers to deploy the same code on ARM, while boosting application performance, using less energy and reducing costs. A win-win for all 👏

[beporter]

This is still an issue here in 2025.

Our team has a desire to maintain platform architecture between our development machines (M-Series Macs) and our deployment environments (arm64 EC2/ECS on AWS). Lots of progress has been made, especially with heroku/builder:24 having been (generally) cross-platform for the past year-plus, but this buildpack still bundles amd64 binaries, such as resolve-version-linux. Yes, there's resolve-version-darwin but our deployment environments aren't darwin.

Since the source for this tool is Rust, and Rust supports cross-compilation to both x86_64-unknown-linux-gnu and aarch64-unknown-linux-gnu it sure seems possible to include both in this buildpack, which would unblock the contemporary error I'm seeing:

-----> Installing binaries
       engines.node (package.json):   unspecified
       engines.npm (package.json):    unspecified (use default)

       Resolving node version 22.x...
       /tmp/buildpackqW3bn/lib/binaries.sh: line 11: 
              /tmp/buildpackqW3bn/lib/vendor/resolve-version-linux: 
              cannot execute binary file: Exec format error
       Error: Unknown error installing "22.x" of node

(The cannot execute binary file: Exec format error being the trouble spot.)

EDIT: See also, #1268 (comment)