[Enhancement]: Publish arm64 container images alongside amd64 #334

What features would you like to see added?

Publish arm64 container images next to the amd64 ones. The Images workflow builds linux/amd64 only (platforms: linux/amd64 in .github/workflows/images.yml), so anyone on Apple Silicon or an arm64 Linux server has to build the images themselves.

The bigger reason is where this gets deployed. Code Interpreter and its components run well in arm64 environments on AWS, and arm64 costs less than the equivalent x86 capacity there:

• EKS on Graviton nodes
• ECS and Fargate on arm64
• Lambda MicroVM, which is arm64 only

The Lambda MicroVM path already assumes arm64 and has no published image to use: docs/lambda-microvm/README.md tells the operator to build the runner image locally with buildx, scripts/build-lambda-microvm-artifact.sh builds --platform linux/arm64, and the Terraform provisions a private ECR repository for "the arm64 runner image". The Helm chart already ships an SCMP_ARCH_AARCH64 seccomp profile. Publishing arm64 images would let all of these pull a tested image instead of building one.

Most of the groundwork is already in the tree:

• .github/workflows/ci.yml builds the lambda-microvm-runner target natively on ubuntu-24.04-arm
• launcher/src/main.rs has an aarch64 branch
• seccomp/nsjail.json has an SCMP_ARCH_AARCH64 entry
• docker/package-init.sh picks the arm64 Node and Bun downloads
• Fedora builds libkrun for both x86_64 and aarch64

More details

Keep the existing plan, build and promote shape, and add the architecture as a second matrix dimension:

• build every image twice, on ubuntu-24.04 and on ubuntu-24.04-arm, so nothing runs under emulation
• each build pushes sha-<commit>-amd64 or sha-<commit>-arm64 and keeps its own registry build cache
• a new merge job joins the two into the sha-<commit> manifest that hosts pull, so Docker picks the right architecture
• the promote job needs no change, and .github/scripts/image-revision.sh already reads a manifest list

Open questions:

• The Fedora stages (launcher-builder, sandbox-runner-base) have never been built for arm64 in CI.
• A cold arm64 build of sandbox-runner compiles CPython with profile guided optimization and may not fit the current 60 minute timeout. Installing a prebuilt CPython instead would remove most of that cost, but that is a separate change.

Verified locally: all five service images (api, worker, file-server, egress-gateway, tool-call-server) build natively for linux/arm64 on Apple Silicon.

Which components are impacted by your request?

General, Other

Pictures

No response

Code of Conduct

• I agree to follow this project's Code of Conduct