Hanzo
OpenapiPlatform

Deploys the app — building it first if it comes from git.

Deploys the app — building it first if it comes from git.

POST /v1/platform/projects/{project}/apps/{app}/deploy

Addresshttps://api.hanzo.ai/v1/platform/projects/{project}/apps/{app}/deploy
MethodPOST
Operationpost_platform_projects_by_project_apps_by_app_deploy
AuthAuthorization: Bearer $HANZO_API_KEY

Deploys the app — building it first if it comes from git.

It starts a new, monotonically versioned deployment of the app and answers 202 with the deployment record. A 202 is an ACCEPTED deployment, not a live one.

An IMAGE app deploys the tag you name (falling back to the app's tag, then latest) by writing its operator Service CR; the operator reconciles it to running. A GIT app launches an in-cluster BuildKit Job at commit — or the app's branch — and comes back in building; the Service CR is applied later, by the reconciler, once the Job succeeds. The reconciler is restart-safe, so a build in flight survives a cloud restart.

Deploys are bounded per org: over the concurrent-deploy cap is 429 and NOTHING is recorded, so a rejected deploy leaves no phantom in the history. An unreachable cluster is 503 but still records an honest error deployment, because a deploy that was attempted and failed must not be indistinguishable from one never made. Every other failure is likewise recorded in its real terminal state.

This is metered work: a git build is billed to the org's ledger in wall-clock build minutes once the Job finishes, and the running deployment is billed for its compute per tick for as long as it stays live. Requires a validated principal; 403 without one, and everything is written into that org's own tenant-<org> namespace.

Request

6 fields, body application/json (required).

FieldInTypeRequiredDescription
projectpathstringyesProject is the project the application lives under, from the path.
apppathstringyesApp is the application's slug, from the path.
appbodystringApp is the application's slug, from the path.
commitbodystringCommit is the git commit or ref to build, for a git-source app.
projectbodystringProject is the project the application lives under, from the path.
tagbodystringTag is the image tag to deploy, for an image-source app.

Response

StatusBodyMeaning
202deploymentViewaccepted

202 body — 12 fields.

FieldInTypeAlwaysDescription
applicationIdbodystringApplicationID is the app this deployed — the app's id, not its slug.
buildIdbodystringBuildID is the build record behind a git deploy, whose logs and status live at /v1/platform/builds.
commitbodystringCommit is the git ref this built — the commit a deploy or a push named, else the app's branch.
createdAtbodyintegerCreatedAt is when the attempt was recorded, unix seconds.
idbodystringID is the deployment's id (dep_…), minted when the attempt is recorded.
imagebodystringImage is the full repo:tag this deployment put in the CR.
messagebodystringMessage is why this attempt is not live: the failure, or the note that a newer deployment went live before this build finished.
orgbodystringOrg is the tenant the deployment belongs to, from the validated identity.
sourcebodystringSource is which lane produced it: git (built from the repo) or image (an already-built ref deployed as-is, including promote and rollback).
statusbodystringStatus is where the attempt got to: building while its image is being built, deploying once its CR reached the cluster — which is the terminal success…
updatedAtbodyintegerUpdatedAt is its last transition, unix seconds — so for a terminal deployment it is when it reached that state.
versionbodyintegerVersion counts this app's deployments, from 1 and monotonically.

Failure carries the platform error shape — see Errors.

Examples

hanzo platform projects apps deploy <project> <app>

Platform API · All Hanzo APIs · Interactive reference

How is this guide?

On this page