Checking a deploy

Builds are asynchronous, so a successful tool call means "queued", not "live". How to confirm a deploy actually serves.

Because builds are asynchronous, a successful tool call means "queued", not "live". Confirm a deploy in this order:

Poll get_app until status settles (e.g. running or error). A freshly created app may report running from a previous deploy while the new build is still coming up, so don't stop at the first read.
Prove it serves. The real signal is a request to the app's URL — hit a known route (a /health endpoint is ideal) and check the response body, not just that a status says "running".
get_app_logs shows recent build/runtime output when you need to see why something crashed. It's best-effort and can be briefly unavailable — if it is, fall back to hitting the URL.

A status of running is not proof

A crash-looping container and a healthy one can both read as running in a narrow window. Treat a real HTTP response from your app as the deploy's pass condition.

What happens after the call returns

Your source is committed

The files you passed are written to the app's private repository as a commit. This is synchronous — by the time the tool returns, your source is stored.

A container is built from your source using the runtime's recipe (or your own Dockerfile). This is the part that takes time — typically well under a minute for a static site, longer for an app with dependencies to install.

The container replaces the running one

Once built, it starts and takes over. The app's status transitions to running when the container is up — which is not the same as your process inside it staying up.

An invite-only app has its gate re-applied

Rebuilding regenerates the container's proxy configuration, which would otherwise drop the access gate. agenthost re-applies it for you after every build, and keeps a background reconciler over private apps besides — you do not have to poll for this to happen, and nothing you do can leave a shared app publicly readable.

Statuses

Status	Meaning
`created`	The record exists; nothing has been built
`provisioning`	Queued or building
`running`	The container is up
`stopped`	Not serving
`error`	Provisioning or the build failed

A reasonable polling loop

Poll get_app every few seconds until the status leaves provisioning, giving up after a couple of minutes rather than forever. Then make one real request to the app's URL and treat that as the verdict:

deploy_app  → queued
get_app     → provisioning
get_app     → provisioning
get_app     → running
GET <url>   → 200 + expected body   ← the pass condition

If the status reaches error, or the request fails after the status settles, read the logs — see Fix a broken deploy.

Simulated mode

When hosting isn't configured on the server, deploys run in simulated mode: nothing is built, deployed or served, and every result says so explicitly. Treat that note as a failure to deploy, not a success.