Deploy Error Decoder

Docker 'exec format error' — fix the arch mismatch

Quick answer: Docker exec format error almost always means an architecture mismatch: the image was built for one CPU architecture (e.g. arm64 on an Apple Silicon Mac) and you're running it on another (amd64 server). Build for the target platform — docker buildx build --platform linux/amd64 — or publish a multi-arch image so it runs everywhere.

What the error looks like

The container can't even start the entrypoint binary:

exec /app/server: exec format error

# older runc phrasing:
standard_init_linux.go:228: exec user process caused:
exec format error

The kernel is refusing to run a binary compiled for a different CPU architecture. It's almost never a corrupt file — it's arm64 vs amd64.

Why it happens

Built on Apple Silicon, run on amd64

An image built on an M-series Mac defaults to arm64 and won't run on a typical amd64 server.

Base image is the wrong arch

The FROM image (or a pinned digest) is for an architecture the host doesn't share.

A binary compiled for the wrong target

A Go/Rust binary built for the wrong GOARCH/target is copied into the image.

A script with no/!wrong interpreter

A shell script entrypoint without a valid shebang (or CRLF line endings) can present the same error.

Diagnose it in three steps

1

Check the image vs host arch

docker image inspect IMAGE --format '{{.Architecture}}'
uname -m        # x86_64 (amd64) or aarch64 (arm64) on the host
2

Build for the target platform

docker buildx build --platform linux/amd64 -t myapp:amd64 . --load
3

Or publish multi-arch

docker buildx build --platform linux/amd64,linux/arm64 \
  -t registry/myapp:1.0 --push .
The real fix

Match the build platform to where it runs

Build for the architecture you deploy to. The cleanest approach is a multi-arch image so the right variant is pulled automatically; otherwise pin --platform in your build and compose so a laptop build doesn't ship the wrong arch to production. For script entrypoints, also verify the shebang and LF line endings.

How Infraveil handles this

The wrong artifact, stopped at the gate

An arch-mismatched build is exactly the kind of broken artifact that shouldn't reach users. Infraveil verifies a package before the agent runs it on your own servers — nothing starts until it passes — so a build that can't execute is caught at the deploy gate, recorded, and easy to roll back from.

Deploys are verified before they run — an unrunnable artifact is caught early
One-click rollback to the last release that started on your hardware
Every deploy recorded in a tamper-evident trail, on servers you control
See how it works More deploy fixes

Frequently asked questions

What does 'exec format error' mean in Docker?

The kernel refused to execute the container's binary because it was built for a different CPU architecture than the host — typically arm64 vs amd64.

Why does my image fail only on the server?

You likely built it on an Apple Silicon (arm64) Mac, which produces an arm64 image, while the server is amd64. Build with --platform linux/amd64 or publish multi-arch.

How do I build a multi-arch Docker image?

Use buildx: docker buildx build --platform linux/amd64,linux/arm64 -t registry/app:tag --push .. The registry then serves the right variant per host.

Can a shell script cause exec format error?

Yes — an entrypoint script with no valid shebang line, or with Windows CRLF line endings, can produce the same error even without an arch mismatch.