An x86-64 host cannot execute ARM binaries, and a RUN step executes binaries of the target platform. Docker 514 's documentation lists three ways around this. Emulation registers QEMU 34,579 user-mode emulators with the kernel's binfmt_misc feature, typically with docker run --privileged --rm tonistiigi/binfmt --install all, after which ARM programs run transparently, but much more slowly, especially for compilation and compression. Native nodes add a real ARM machine to the builder with docker buildx create --append. Cross-compilation runs the build steps on the build machine's own platform and produces output for the target.
binfmt_misc registrations belong to the kernel, which every container and every WSL2 6 distribution on this machine shares, so QEMU was not installed here ("not run here"). Without it, the current Dockerfile fails for ARM at its first RUN:
ls /proc/sys/fs/binfmt_misc | xargs
docker build --platform linux/arm64 -t l3-arm-test . 2>&1 | grep -m1 'format error'WSLInterop python3.14 register status #10 0.212 exec /bin/sh: exec format error
The fix is the third strategy. BuildKit 10,294 predefines BUILDPLATFORM (the machine running the build) and TARGETPLATFORM (the platform being produced), plus TARGETOS and TARGETARCH. A stage declared FROM --platform=$BUILDPLATFORM always runs natively; Go and Rust then compile for any TARGETARCH. BookNest is simpler still: its 82 packages contain no native .node add-ons, so node_modules built on amd64 works on arm64, and the runtime stage only copies files.