Sume command line tool on Linux arm64: Graviton, Docker on a Mac

Yes: the Sume command line tool publishes a Linux arm64 binary, so it runs on AWS Graviton, on arm64 CI runners and in a Linux container on an Apple Silicon Mac. The release assets are sume-darwin-arm64, sume-darwin-x64, sume-linux-arm64, sume-linux-x64 and sume-windows-x64.exe, so Windows is x64 only.

That list comes from the Install and update page, read 2026-10-10. It names the assets and the installer behavior. It does not say anything about C library variants, so test the binary in your base image before you depend on it.

The short answer for a Dockerfile is therefore the Linux asset that matches the container architecture, not the one that matches your laptop. Build the image for the platform it will run on, and the same uname-based line picks the right file in both a laptop build and a Graviton build.

Which asset matches which machine

The binary name is sume-<os>-<arch>. Docker on an Apple Silicon Mac runs Linux containers as arm64 by default, which is the common source of confusion: the host is macOS, but the container needs the Linux asset.

A mismatched asset usually shows up as an exec format error the first time you run it, before any API call is made. That failure costs nothing, because nothing has been sent to the API yet. If it happens, run uname -m inside the container and compare it to the table.

The one-line installer picks for you

On macOS or Linux the hosted installer, curl https://cli.sume.com/install -fsS | bash, downloads the latest release binary for your operating system and architecture. It then compares the binary with the release checksums.txt and installs sume into ~/.sume-com/bin. If a different sume is already on your PATH, it does not overwrite it silently.

On Windows PowerShell the equivalent is irm https://cli.sume.com/install.ps1 | iex. The docs list no Windows arm64 asset, so on a Windows on Arm machine, do not assume the x64 file is supported; check it before you rely on it.

The installer's checksum step is the reason to prefer it over a bare download on a developer machine. In an image build, the direct download below gives you the same pinning with fewer moving parts, as long as you keep the release tag in one place.

Direct download for a Dockerfile

In a build you usually want a pinned version, not latest. The docs give the pattern: build the asset name from uname, and replace latest in the URL with a release tag such as v0.1.6 for a pinned install. The snippet below is the docs one, with the architecture mapping that turns x86_64 into x64 and aarch64 into arm64.

Keep the architecture mapping in the build step, not in a hard-coded file name. A multi-platform image build runs the same instruction once per target, and a fixed sume-linux-x64 would silently put the wrong binary into the arm64 image.

OS="$(uname -s | tr '[:upper:]' '[:lower:]')"
ARCH="$(uname -m | sed 's/x86_64/x64/;s/aarch64/arm64/')"
curl -fsSL "https://github.com/sumelabs/cli/releases/latest/download/sume-${OS}-${ARCH}" -o /tmp/sume
chmod +x /tmp/sume
sudo mv /tmp/sume /usr/local/bin/sume
sume version

Check it before the first paid call

After install, the docs verify with sume version, sume doctor --agent --json and sume update --check, and sign-in is a separate step. For a headless container use sume login --no-browser, or set an API key in the environment for CI and server use, which the docs describe as available but not the recommended first run for local users. Set SUME_API_BASE_URL only if you call a different API host; the default is https://api.sume.com/v1.

To keep a container build reproducible, pin the release tag, keep the downloaded checksums.txt next to it, and see installing in CI with checksums for the verification step.

sume doctor --agent --json is the useful check inside a container, since it reports setup state in a form a script can read. sume update --check only tells you whether a newer release exists; it changes no local files, so it is safe in a CI step that must not upgrade.