From 0dca779f5939549972e0f11f32fe1caabe217f15 Mon Sep 17 00:00:00 2001 From: Aryan Singh Date: Thu, 6 Aug 2026 00:51:31 -0500 Subject: [PATCH] Publish arm64 alongside amd64 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit muse is now the front door of a public project, and it was the only image in that stack without an arm64 build. Raspberry Pis, arm64 NASes and Ampere VPSes are a large share of self-hosters, so amd64-only made the whole stack un-runnable for them — gluetun, slskd, soularr, lidarr, navidrome and the socket proxy all already publish both. Three parts, because changing `platforms:` alone would have failed: - setup-qemu-action registers the binfmt handlers buildx needs to produce arm64 on an amd64 runner. Without it the build errors with "exec format error"; it does not quietly fall back to amd64. - The web stage is pinned to --platform=$BUILDPLATFORM so the Next.js build runs natively once instead of being emulated per platform. It is the expensive step, and its output is static HTML/JS/CSS with no native code, so the bytes are identical either way. This is what makes the old comment's "3-5x slower for nothing" no longer true. - platforms: linux/amd64,linux/arm64. Verified locally before pushing: both platforms build in ~52s, and the loaded arm64 image reports aarch64 with uvloop, watchfiles, httptools and pydantic_core all importing, `import app` succeeding, and the static UI present. Co-Authored-By: Claude Opus 5 --- .github/workflows/release.yml | 27 ++++++++++++++++++++++++--- Dockerfile | 24 +++++++++++++++++++++--- 2 files changed, 45 insertions(+), 6 deletions(-) diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index 25ce75d..b22fe14 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -48,6 +48,14 @@ jobs: npm ci npm run build + # Registers binfmt handlers so buildx can produce a linux/arm64 image on + # an amd64 runner. REQUIRED by the multi-arch build below — without it + # buildx fails outright ("exec format error"), it does not silently fall + # back to amd64 only. + - uses: docker/setup-qemu-action@v3 + with: + platforms: arm64 + - uses: docker/setup-buildx-action@v3 - name: Log in to GHCR @@ -73,9 +81,22 @@ jobs: uses: docker/build-push-action@v6 with: context: . - # amd64 only: the only host that runs this is x86_64. Adding arm64 - # means QEMU emulation and a 3-5x slower build for nothing. - platforms: linux/amd64 + # amd64 AND arm64. + # + # This was amd64-only, and that was the right call while the only + # host running muse was one x86_64 box — arm64 meant paying QEMU for + # an image nobody would pull. That changed when muse became the + # front door of a public project: Raspberry Pis, arm64 NASes and + # Ampere VPSes are a large share of self-hosters, and every other + # image in that stack already publishes both. muse would have been + # the single thing making it un-runnable on a Pi. + # + # The old comment's cost estimate no longer applies either: the + # expensive stage (the Next.js build) is pinned to $BUILDPLATFORM in + # the Dockerfile, so it runs natively once instead of being emulated + # per platform. What is emulated is a pip install of prebuilt + # wheels. + platforms: linux/amd64,linux/arm64 push: true tags: ${{ steps.meta.outputs.tags }} labels: ${{ steps.meta.outputs.labels }} diff --git a/Dockerfile b/Dockerfile index c12b6ad..4b04b6e 100644 --- a/Dockerfile +++ b/Dockerfile @@ -4,7 +4,18 @@ # HTML/JS/CSS, so Node never runs in the final image and the runtime stays a # single Python process — same container, same healthcheck, same everything # the deploy already expects. -FROM node:22-slim AS web +# +# --platform=$BUILDPLATFORM pins this stage to the NATIVE architecture of +# whatever is doing the building, instead of the architecture being built +# FOR. That matters now that this image is multi-arch: without it, the arm64 +# image would run `npm ci` and `npm run build` under QEMU emulation, which is +# by far the slowest thing in this file — several minutes, repeated per +# platform. +# +# It is safe precisely because the output is static HTML/JS/CSS. There is no +# native code in `out/`, so bytes built on amd64 are byte-identical to bytes +# built on arm64, and stage 2 just copies them in. +FROM --platform=$BUILDPLATFORM node:22-slim AS web WORKDIR /web @@ -18,8 +29,15 @@ RUN npm run build # ── stage 2: runtime ──────────────────────────────────────────────────── # -# Slim, no build toolchain needed — every Python dependency ships wheels for -# linux/amd64 on py3.12. +# Slim, no build toolchain needed — every Python dependency ships prebuilt +# wheels on py3.12 for BOTH linux/amd64 and linux/arm64. fastapi, httpx and +# mutagen are pure Python; uvicorn[standard]'s compiled extras (uvloop, +# httptools, watchfiles) all publish aarch64 manylinux wheels. +# +# That is what keeps the emulated arm64 build cheap: pip downloads wheels +# rather than invoking a compiler under QEMU. If a dependency is ever added +# that has no aarch64 wheel, this build will suddenly take ten minutes and +# need gcc — that is the signal to switch to a native arm64 runner. FROM python:3.12-slim WORKDIR /app