Why there is no linux-arm64 build yet
oam ships binaries for five targets: windows-x64, windows-arm64, macos-x64, macos-arm64 and linux-x64. linux-arm64 is not one of them. Run the installer on an ARM Linux machine and it does not guess, and does not attempt a download that was never published — it refuses the target by name:
oam-install: error: no published oam binary for Linux aarch64 yet (aarch64-unknown-linux-gnu is unreleased; use an x86_64 host or build from source)Any other unrecognized Linux architecture gets the generic unsupported Linux arch error. aarch64 has its own branch, which names the exact target triple that is missing and the two workarounds that exist. This post is the longer version of that message.
The code is not the problem
linux-arm64 builds from the same tree as the five shipped targets. On an ARM Linux host with stable Rust — the version is pinned in rust-toolchain.toml — cargo build --workspace produces a working binary. What has never existed is a released one, and the blocker is a single build artifact: the V8 startup snapshot.
What the snapshot is for
oam embeds a V8 startup snapshot: engine state captured at build time that the runtime loads at boot instead of reconstructing on every start. It lives in oam_engine — the only crate that touches V8, alongside isolates and the code cache — and the repo automation has a job whose whole purpose is rebuilding it.
The snapshot is there because cold start is the axis oam optimizes. The runtime is built to host MCP servers: many short-lived processes, idle most of the time, each needing to answer its first request fast. In the committed benchmark table (cargo run -p xtask -- bench --release --compare at commit acec008, release profile, one windows-aarch64 machine, oam 0.9.0 against node v22.22.2 and bun 1.3.14), cold-start is 59.58ms against Node's 113.42ms and Bun's 307.97ms, and mcp-cold-start is 35.00ms against Node's 250.87ms and Bun's 483.19ms. The same table shows Bun beating oam outright on url-parse, http-throughput and crypto-hash, and Node edging fs-read — cold start is what the snapshot buys, not everything.
And the snapshot is the piece that cannot be cross-compiled. Generating it is not a compile step you can point at a foreign target: it has to run on the architecture it is for. A linux-arm64 snapshot needs a native ARM Linux machine, and the release flow — scripts/release-local.sh, which cuts a GitHub Release for every pushed v* tag by building locally and on remote build hosts — does not have one yet.
What you can do today
The two options in the error message are the two that exist.
- Use an x86_64 host. linux-x64 ships, installs with
curl -fsSL https://oamjs.org/install.sh | sh, and is verified against the publishedSHA256SUMSlike every other target. - Build from source. Stable Rust, then
cargo build --workspace— andcargo test --workspaceif you want the suite. It is the same tree the shipped binaries come from.
One consequence of a source build: oam self-update re-runs the canonical installer, and the installer refuses this target. A source-built oam on ARM Linux stays on manual updates until the release exists.
The slot is already reserved
The release naming contract lists oam-aarch64-unknown-linux-gnu alongside the five shipped asset names, marked not yet shipped, needs an ARM Linux build host. The installer's uname mapping carries a comment to re-add the aarch64 branch the moment that release leg exists. Neither has a date attached, because there is no ARM Linux builder attached — and a date without a builder is the same kind of claim as a percentage without a denominator.
Until then: an x86_64 box, or cargo build on your own machine. The installer will keep saying so, by name.