Odd "syntax errors" when launching an image on macOS, but not on Linux

I have the following Dockerfile:

FROM node:18-slim

COPY . /opt/app

WORKDIR /opt/app

RUN npm i

EXPOSE 8080/tcp

CMD /bin/bash npm run dev -- -- --api-listen-addr

(For full context: create-chiselstrike-app: Generate Dockerfile by penberg · Pull Request #1787 · chiselstrike/chiselstrike · GitHub)

When I fly launch from a Linux machine with podman installed, it deploys fine and I can access my application.

However, when I do the exact same thing from macOS, I see errors like this when attempting to start the application:

2022-09-22T08:34:37.000 [info] /opt/app/node_modules/binary-install/bin/chisel: 1: Syntax error: "(" unexpected

That file is supposed to be a Linux binary and the Docker image is also tested to be OK.

How is the fly launch process different on Linux and macOS?

The main difference that springs to mind is which docker builder is being used and the context provided to the builder.

When using a recent version of flyctl, it will likely default to using a remote builder provided by Fly.io on both linux and macos. Some developers have had issues with the local docker builders on macos. the output from fly launch will indicate if it used the local builder or a remote builder. If a local builder is getting used by default, pass the --remote-only flag to force fly launch to use a remote builder instead.

The docker context may be different between linux and macos. For example, if some binaries are built locally and then copied into the docker image, the versions that are built on macos are not likely to work in the linux/x86_64 docker images that are built when deploying to Fly. One way to fix that is to ensure that all the “building” happens within docker, and use a .dockerignore file to ensure that any locally generated build artifacts are not passed into the docker build context.

I tried running fly launch on a macos device for the linked PR, and the docker build failed due to a missing Cargo.toml file. I didn’t investigate further, but that could be an indication that the docker build is relying on some artifacts that are built on the host system.