Runner

Package platform is Hanzo PaaS: deploy containers to your own tenant namespace — builds, releases, environments, logs, custom domains.

runner

GET /v1/runner/releases/{id}

Returns one self-publish release by the id its 202 returned.

It returns the state of one release run — which is the whole reason the trigger answers with an id, because without this a release that died in the detached pipeline would look exactly like one still in flight. SuperAdmin only.

A 404 means the id is unknown OR has aged out of this process's in-memory record. That is the honest answer either way: the process genuinely cannot tell the two apart.

GET /v1/runner/releases

Lists the self-publish releases this process has run.

It lists the platform's own release runs with their current state, so a release that answered 202 with an id can be followed to its end. SuperAdmin only — this is the platform's own publishing record, not a tenant surface.

The record lives in THIS process's memory, so it covers the releases this instance started and does not survive a restart.

POST /v1/runner

Triggers a native build — an image, or the binaries a repo declares.

The fabric's own build trigger, and what hanzo build, git-push-to-deploy and cloud's own self-release all call. It answers 202 with the build job id: a queued build, not a pushed artifact.

Two lanes, and a build is exactly one of them. The IMAGE lane takes repo and the output image and launches a BuildKit Job that pushes it. The ARTIFACT lane takes binaries — the same recipe the repo's hanzo.yml declares — and publishes to object storage instead; it must carry no image, because a build produces binaries or an image, never both. release: true is the third mode: cloud self-publishing its own image, version computed, built, smoke-tested, tagged and announced.

PRIVILEGED, with exactly two credentials and never a third: the shared build-callback token compared in constant time — the machine path, which a user never holds — or a validated IAM principal who is an ADMIN of their org, which is the hanzo build user path and means one IAM login authorizes a build with no separate build token. A plain member is refused.

Both paths are bounded the same way: the output must push to a registry the fabric owns, and on the IAM path the image's registry namespace must MATCH the caller's own validated org — so an org admin can only publish into their own brand and can never overwrite another's through the shared push credential. The same confinement applies to the artifact lane's repo owner.

release: true is the exception, and takes SUPERADMIN. It publishes the platform's own image — the binary the whole fleet runs — so what it lands reaches every org at the next reconcile, and no role inside the caller's own org can authorize that. An org admin is refused however the registry namespace lines up, and the build token, which carries no identity at all, may enqueue an ordinary build but never a release.

The output image is parsed and validated as a single well-formed OCI ref before any authorization decision reads it, so a crafted ref cannot smuggle a build-exporter attribute past the check.

Request body — application/json (required)

---

All Hanzo APIs · Interactive reference