Start or resume an application deploy run
Hand the deploy wizard’s whole ordered multi-stack deploy to the server. The run is persisted before anything is created - roles, drafts, and the stack name derived for each - and the maintenance supervisor creates each stack in turn, waiting for every stack that has another behind it to report up. Closing the browser tab no longer strands the remaining stacks. A request made while a run for the same application and cluster is already in flight joins that run and answers with resumed=true rather than starting a rival queue. Browser session authentication with the X-Ankra-CSRF double-submit header only (no bearer twin).
Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Path Parameters
Body
The queue in deploy order: platform stacks first, the application stack last.
Where the application's workload lands on this cluster. The application role's stack deploys the manifests committed under .ankra/manifests, rendered into this namespace; a run that omits it promotes its designed stacks unchanged.
Sizing the deploy chose ('quick' or 'high_availability'). Omitted is default sizing.
Answers to the application's option contract that no repository can hold - the ingress host and class this cluster publishes it on. Options the contract declares a default for, and the image tag of the application's own most recent successful publish, are resolved at render time and need not be sent.
Response
Successful Response
pending, running, succeeded, or failed.
True when the request joined a run that was already in flight instead of starting a new one.
How a resumed run differs from the queue the request carried (a role not in the run, a role deploying a different stack name or draft, or a differing role count). Null when the request asked for what is already in flight, and always null on a run this request started.