Build targets #

Stream uses Zig 0.17.1. Production builds use ReleaseSafe, baseline CPU features, and x86_64-linux-gnu. Keep compiler versions synchronized across build.zig.zon, tools/loadgen/build.zig.zon, CI, Docker, and the admission host.

zig build -Doptimize=ReleaseSafe -Dcpu=baseline -Dtarget=x86_64-linux-gnu
zig build -Doptimize=ReleaseSafe -Dcpu=baseline -Dtarget=aarch64-linux-gnu

A successful cross-build establishes compilation, not runtime support. The serialized admission gate executes Linux x86-64 behavior, storage recovery, and protocol contracts before production deployment. ARM64 requires its own runtime qualification before deployment. macOS ARM64 is the development host.

Build probes for the destination CPU too. A native HeavyPad loadgen build uses instructions unavailable on the production host and fails before connecting. For a probe that will be copied to production:

cd tools/loadgen
zig build -Doptimize=ReleaseSafe -Dcpu=baseline -Dtarget=x86_64-linux-gnu

WebAssembly #

zig build -Dtarget=wasm32-wasi currently fails while configuring RocksDB: its build supports Linux and macOS, not WASI. The full service also depends on native threading, sockets, filesystem persistence, C++, and telemetry. It is not currently a WebAssembly deployment target.

Zeldi separates its native host from explicitly built WebAssembly cells. The transferable pattern is to expose a narrow portable codec/inspection module and test it independently. Compiling a dependency or an unused module to WebAssembly does not prove the Stream server works there. Extracting that surface is separate work, not part of a dependency maintenance release.

Release metadata #

The binary defaults to the version in build.zig.zon; -Dversion can override it. Release images should carry the commit date through -Dbuild-date and the source SHA through the existing build-info options. Use stream version and stream_build_info to verify the deployed artifact.