OS & Platform Support

Supported targets

pure build compiles in the cloud, so the machine you run it from doesn’t determine what you get back by itself — pass --platform to choose, or let it default to your own machine’s OS and architecture:

| --platform value | Output | libc | |---|---|---| | linux-x64 (default on Linux/x64) | Linux binary, x86_64 | musl (default, static) or glibc | | linux-arm64 (default on Linux/arm64) | Linux binary, arm64 | musl (default, static) or glibc | | macos-x64 (default on Intel Macs) Experimental | macOS binary, Intel | — | | macos-arm64 (default on Apple Silicon) Experimental | macOS binary, Apple Silicon | — |

Windows output isn’t available yet. --libc/--glibc-version only apply to linux-* platforms — they’re accepted but have no effect on a macos-* platform.

macOS output

Experimental macOS output is new and not yet as battle-tested as the Linux path — Pure has been compiling and running Linux binaries in production for a while, and macOS output hasn’t seen the same real-world mileage yet. If you hit anything that looks wrong, let us know.

A couple of things to know going in:

• The binary is unsigned. Pure never signs customer code with its own certificate — a macOS binary from pure build will trigger Gatekeeper’s “unidentified developer” warning the first time you run it (xattr -d com.apple.quarantine ./yourbinary, or right-click → Open, clears it). If you want a signed and notarized binary, sign it yourself afterward with codesign/notarytool using your own Apple Developer certificate — signing doesn’t have to happen at build time.
• You don’t need a Mac to build a macOS binary. pure build --platform macos-arm64 works from Linux, macOS, or anywhere else the CLI runs — compilation always happens in the cloud, and cross-compiling to macOS is no different from cross-compiling to glibc Linux.

The pure CLI itself can also be installed and run on Linux or macOS — see Installation — that’s a separate concern from what platform your compiled output targets.

glibc vs musl

Pure builds against musl by default — a fully static binary with no runtime dependency on the host’s C library. This is what makes a Pure binary “just run” on Alpine, inside a FROM scratch container, or on any Linux host, regardless of what libc (or version) is installed there. It’s also smaller, faster to build, and faster to start than a glibc build of the same project — stick with the default unless you have a specific reason not to.

The one real reason to reach for --libc glibc: a native (N-API) npm dependency whose prebuilt binary is only available for glibc. A musl binary can’t load a glibc-linked native addon (and vice versa) — they’re not interchangeable at the binary level. Most native packages either publish a musl-compatible build already or build correctly from source during install, so this is uncommon in practice; if it does come up, Pure’s build error will identify a libc mismatch by name so it’s obvious what’s going on. If you hit it and no musl-compatible version of the package is available, pass --libc glibc:

pure build server.ts --libc glibc

A glibc build requires a host with glibc at or above the version it targets — --glibc-version sets that floor (default and minimum 2.29, the lowest glibc Pure’s own runtime links against; a lower value is silently raised to 2.29 rather than producing a binary that fails to link). Raise it, e.g. --glibc-version 2.31, if you know your target hosts support a newer one. See pure build for both flags’ full reference.