litellm - 💡(How to fix) Fix [Bug]: v1.83.14-stable linux/arm64 image contains amd64 binaries (mislabeled manifest)

Summary

The versioned v1.83.14-stable Docker image publishes a linux/arm64 manifest entry whose OCI config declares architecture: arm64, but the image contents are actually amd64/x86_64 binaries. Pulling with --platform linux/arm64 succeeds, yet the container runs as x86_64 and core binaries such as /usr/bin/python3.13 and /bin/sh are ELF e_machine 0x3e (amd64), not 0xb7 (aarch64).

This breaks any arm64 deployment that copies runtime artifacts from the image (e.g. multi-stage Docker builds on aarch64 hosts).

Affected images

Both registries expose the same broken arm64 variant:

• docker.litellm.ai/berriai/litellm:v1.83.14-stable
• ghcr.io/berriai/litellm:v1.83.14-stable

Steps to reproduce

On a native aarch64 host (or any environment where amd64 emulation is not masking the problem):

# Pull the arm64 variant explicitly
docker pull --platform linux/arm64 ghcr.io/berriai/litellm:v1.83.14-stable

# Inspect runtime architecture and ELF machine type of bundled Python
docker run --rm --platform linux/arm64 --entrypoint sh \
  ghcr.io/berriai/litellm:v1.83.14-stable -c '
    echo "uname -m: $(uname -m)"
    echo "python3.13 e_machine: $(od -An -tx1 -j18 -N1 /usr/bin/python3.13 | tr -d " ")"
    echo "/bin/sh e_machine:     $(od -An -tx1 -j18 -N1 /bin/sh | tr -d " ")"
  '

Repeat for docker.litellm.ai/berriai/litellm:v1.83.14-stable — same result.

Expected behavior

On arm64:

• uname -m → aarch64
• /usr/bin/python3.13 ELF e_machine → b7 (aarch64)
• /bin/sh ELF e_machine → b7 (aarch64)

Actual behavior

On arm64:

• uname -m → x86_64
• /usr/bin/python3.13 ELF e_machine → 3e (amd64)
• /bin/sh ELF e_machine → 3e (amd64)

The image config still declares arm64:

# arm64 manifest digest for v1.83.14-stable
docker image inspect ghcr.io/berriai/litellm@sha256:1bdc7fd7d6634bbf693d837b14ae41a49d7970cacecb5a0d89db401a825d05e1 \
  --format '{{.Os}}/{{.Architecture}}'
# → linux/arm64

Control (working image)

The rolling main-stable tag does ship a genuine arm64 image:

docker run --rm --platform linux/arm64 --entrypoint sh \
  ghcr.io/berriai/litellm:main-stable -c '
    echo "uname -m: $(uname -m)"
    echo "python3.13 e_machine: $(od -An -tx1 -j18 -N1 /usr/bin/python3.13 | tr -d " ")"
  '
# uname -m: aarch64
# python3.13 e_machine: b7

Impact

When bundling Python and /app/.venv from v1.83.14-stable into an aarch64 container, the kernel cannot execute the amd64 Python binary. Console scripts with #!/app/.venv/bin/python3 shebangs then fall back to /bin/sh, producing errors like:

import: command not found
syntax error near unexpected token `"-script.pyw"'

We hit this while building a Home Assistant add-on that extracts runtime artifacts from the upstream image via a multi-stage Dockerfile. CI correctly built for linux/arm64; the upstream arm64 image itself was the problem.

Environment

• Host: native aarch64 Linux (Docker 29.x)
• Reproduced: 2026-05-31
• Tag: v1.83.14-stable
• arm64 manifest digest: sha256:1bdc7fd7d6634bbf693d837b14ae41a49d7970cacecb5a0d89db401a825d05e1

Workaround

Use ghcr.io/berriai/litellm:main-stable, which currently publishes a correct multi-arch arm64 variant.

Suggested fix

Rebuild and republish the v1.83.14-stable (and likely other vX.Y.Z-stable) arm64 images with actual aarch64 binaries, and add CI validation that linux/arm64 manifest entries contain arm64 ELF binaries (e.g. check e_machine or run file/uname -m on the built image per platform).