Skip to content
experience

Docker was supposed to kill "works on my machine". Now it works on my container.

Guillaume Mercier@guillaume_rale

September 16, 2026 · 2 min read

#2 in Works On My Machine

Bon. Story of my Tuesday, because I need to complain and also because maybe it saves someone 3 hours.

New colleague, new MacBook with an M3. He builds our Symfony image on his machine, tests it, everything works, and he pushes the image to the registry from his laptop because "CI is slow" (it is, but this is not the point). Deploy on our servers. Container starts and dies directly:

exec /usr/local/bin/docker-php-entrypoint: exec format error

The famous "it works on my machine", but now with extra steps and a registry. His Mac is arm64. Our servers are amd64. Docker on the Mac built an arm64 image by default, of course, and the server cannot execute it. Nobody told the image it was going to production.

Three solutions, from "ok" to "how it should be since the beginning":

  1. Force the platform when you build locally.
    docker build --platform linux/amd64 -t app:dev .
    It works, it uses emulation, it is slow on the Mac. Ok for testing, not a process.
  2. Build multi-arch with buildx, so the same tag works on Macs and on servers:
    docker buildx build --platform linux/amd64,linux/arm64 -t registry.example.com/app:1.4.2 --push .
    The registry stores a manifest list and each machine pulls its own architecture.
  3. Never push to the registry from a laptop. Only CI pushes. CI builds what goes to production. Laptops build for laptops.

Also check your FROM. Some base images exist only for amd64, Docker on the Mac will silently emulate them, it will be slow, and then people say "Docker is slow on Mac". No. Your image is wrong.

We did 2 and 3, and I added this to the Dockerfile so the build log says loudly what it is building:

ARG TARGETPLATFORM
RUN echo "building for $TARGETPLATFORM"

Bref. Docker solved "works on my machine" the same way the RER solves transport: in theory.

#docker#php#devops#rant

Get the best of #works-on-my-machine weekly

One email each Monday with the most useful posts. No spam; unsubscribe in one click.

Comments

9

Sign in to join the conversation.

Sign in to comment
Julien Lefèvre@julien_wp1 rep in Works On My Machine
Ah, le classique. Même chose chez un client le mois dernier, image buildée sur un Mac M2, prod en amd64. J'ai mis 2 heures à comprendre. Point 3 ou rien.
6 net votes
Guillaume Mercier@guillaume_rale#2 in Works On My Machine
Point 3 ou rien. On devrait le graver sur les MacBooks.
1 net votes
Harmanpreet Singh@harman_devops1 rep in Works On My Machine
paaji point 3 is daily ka kaam for us. push from laptop = access revoked. strict rule
6 net votes
Alasdair Reid@onprem_or_die#8 in Works On My Machine
or run the same arch everywhere like a grown up. cupboard server is amd64, laptop is amd64, problems are zero
4 net votes
Guillaume Mercier@guillaume_rale#2 in Works On My Machine
And your laptop weighs 4 kilos, I suppose.
2 net votes
Alasdair Reid@onprem_or_die#8 in Works On My Machine
3.6. and it has a parallel port. what of it
4 net votes
Nguyễn Minh Hiếu@homelab_hieu1 rep in Works On My Machine
Same problem in my homelab but reverse :D I build on amd64 desktop and deploy to a Raspberry Pi arm64. buildx multi-arch saved me. hope this help someone
5 net votes
Sam Whitaker@segfault_sam#6 in Works On My Machine
works on my machine evolved into works on my architecture. next year: works on my planet
6 net votes
Nadia Benali@nullbyte_nadia1 rep in Works On My Machine
And when only CI pushes, you can sign the images and verify the signature at deploy. Laptops pushing to a prod registry is a supply chain problem, not only an architecture problem. Bref, point 3 twice.
4 net votes