Context
In #525 the project default was switched from Hetzner ARM (cax31) to x86 (cpx31). All stacks build/run on x86 except Sling, whose Dockerfile hardcodes the arm64-only download URL from the upstream GitHub release:
# stacks/sling/Dockerfile (current, arm64-only)
RUN set -eux; \
curl -L -o /tmp/sling_linux_arm64.tar.gz https://github.com/slingdata-io/sling-cli/releases/download/v1.5.13/sling_linux_arm64.tar.gz; \
curl -L -o /tmp/checksums.txt https://github.com/slingdata-io/sling-cli/releases/download/v1.5.13/linux.arm64.checksums.txt; \
cd /tmp && sha256sum -c checksums.txt; \
tar xzf /tmp/sling_linux_arm64.tar.gz -C /usr/local/bin; \
chmod +x /usr/local/bin/sling; \
rm /tmp/sling_linux_arm64.tar.gz /tmp/checksums.txt
On x86 (cpx31) the build fails — the arm64 binary refuses to execute. compose-runner treats per-stack failures as yellow warnings (deploy continues), so this is non-blocking, but Sling itself is unusable until fixed.
Proposed fix
Replace the hardcoded URL with dpkg --print-architecture detection so the Dockerfile produces the right binary for whichever arch it's being built on:
# Download and install Sling — auto-detect arch via dpkg.
# Sling release artefact naming: sling_linux_<arch>.tar.gz with
# checksum file linux.<arch>.checksums.txt.
RUN set -eux; \
DPKG_ARCH=$(dpkg --print-architecture); \
case "$DPKG_ARCH" in \
amd64) SLING_ARCH=amd64 ;; \
arm64) SLING_ARCH=arm64 ;; \
*) echo "Unsupported arch: $DPKG_ARCH" >&2; exit 1 ;; \
esac; \
curl -L -o /tmp/sling.tar.gz "https://github.com/slingdata-io/sling-cli/releases/download/v1.5.13/sling_linux_${SLING_ARCH}.tar.gz"; \
curl -L -o /tmp/checksums.txt "https://github.com/slingdata-io/sling-cli/releases/download/v1.5.13/linux.${SLING_ARCH}.checksums.txt"; \
cd /tmp && sha256sum --ignore-missing -c checksums.txt; \
tar xzf /tmp/sling.tar.gz -C /usr/local/bin; \
chmod +x /usr/local/bin/sling; \
rm /tmp/sling.tar.gz /tmp/checksums.txt
Plus update the file header from "Custom ARM64-compatible build" to "Multi-arch build (amd64 + arm64)".
Verification
cd stacks/sling && docker build -t sling:multiarch . on the x86 Hetzner host — must succeed.
docker exec sling sling --version — must print version 1.5.13.
- (Optional) Build on an ARM machine (Apple Silicon, etc.) to confirm the arm64 path still works.
Out of scope (related but separate)
stacks/dagster/Dockerfile has a similar "ARM64-compatible build" header but the base is python:3.11-slim so it's already multi-arch by construction — only the title is misleading. Could be cleaned up alongside Sling or in a separate doc-touch PR.
Priority
Low / opportunistic. Sling is a CLI-only stack that few users enable by default. Fixing it removes the yellow warning on x86 spin-ups for users who do enable it. Forward-compatible with a future ARM revert.
Context
In #525 the project default was switched from Hetzner ARM (
cax31) to x86 (cpx31). All stacks build/run on x86 except Sling, whoseDockerfilehardcodes the arm64-only download URL from the upstream GitHub release:On x86 (
cpx31) the build fails — the arm64 binary refuses to execute.compose-runnertreats per-stack failures as yellow warnings (deploy continues), so this is non-blocking, but Sling itself is unusable until fixed.Proposed fix
Replace the hardcoded URL with
dpkg --print-architecturedetection so the Dockerfile produces the right binary for whichever arch it's being built on:Plus update the file header from "Custom ARM64-compatible build" to "Multi-arch build (amd64 + arm64)".
Verification
cd stacks/sling && docker build -t sling:multiarch .on the x86 Hetzner host — must succeed.docker exec sling sling --version— must print version1.5.13.Out of scope (related but separate)
stacks/dagster/Dockerfilehas a similar "ARM64-compatible build" header but the base ispython:3.11-slimso it's already multi-arch by construction — only the title is misleading. Could be cleaned up alongside Sling or in a separate doc-touch PR.Priority
Low / opportunistic. Sling is a CLI-only stack that few users enable by default. Fixing it removes the yellow warning on x86 spin-ups for users who do enable it. Forward-compatible with a future ARM revert.