Builds

A build is an immutable image rendered from a commit — the thing a release actually runs.

What a build is

High builds a multi-arch OCI image straight from your repository, so the same build runs on an x86 cloud node and an ARM Pi without a rebuild. Every build records its provenance: the commit, the source, and a content digest like sha256:9f3c1a. Builds are immutable — you never mutate one, you produce a new one.

One image, every architecture

The build produces a single multi-arch image, so one release runs unchanged on an x86 cloud node and an ARM Pi — the node pulls the variant that matches its CPU. You don't build per target or think about architecture at all.

Triggering a build

Builds happen automatically when you push to a connected repo (see Git & auto-deploy) or deploy from a new commit, and you can request one explicitly. Because images are content-addressed, an unchanged commit reuses the existing build rather than rebuilding.

Where builds run

High never executes user build steps on the hub. Automatic selection prefers one of your live builder nodes, then an explicitly granted isolated builder, then a live dedicated node from the platform builder pool. Choosing Platform builder pool uses that same pool policy; it does not mean the hub.

A platform builder is reserved for builds and excluded from application placement. If no eligible builder is online, the build fails closed instead of falling back to the control plane. The build run records the concrete node that handled it for logs, audit, and metering.

Provenance & signing

Every build is signed by the platform and pinned by digest (sha256:…). Before a node runs an image it verifies that digest and signature, so it only ever runs bytes the platform actually built — a release can't be swapped out from under it. That signed, pinned build is also what makes a deploy exactly reproducible later.