← All chapters

Deploy and runtime

Bringing a tron up, seeing what it is doing, and putting it back down.

The routes

POST/trons/:id/deployBrings the containers up from the saved canvas. A tron already running or asleep is left as it is.
POST/trons/:id/redeployDeploys the saved canvas again, even while the tron runs: how an edit reaches the container. For whoever can edit the tron; one a minute.
POST/trons/:id/stopPuts them down.
GET/trons/:id/deploy-statusState, container name, port, deployed_at, and a map of agents keyed by LABEL rather than a list. The field is still called nuclei on the wire.
GET/trons/:id/nucleiWhich agents are actually deployed. The file routes 404 unless a label is one of these.
GET/trons/:id/activity{ state, working, nuclei }, again keyed by label.
GET/trons/:id/logsThe key is events, not logs, and the tail is capped at 200. limit, n and tail are all ignored.

Reading the state

running, sleeping, idle, error. sleeping is woken by the server on the next request; idle is not.

Polling politely

Reads count against your account's per-minute limit (the x-ratelimit-limit header says it; past it, 429). deploy-status and activity answer from the server; activity of a sleeping tron does not wake it. For a job of the Tron API, instead of polling GET /v1/jobs/:jobId: its stream, or the key's webhook (see The Tron API). In the site the Live view follows a tron as it works over GET /trons/:id/live, server-sent events, with a session only.