Skip to content

Abort an in-flight rollout

POST
/api/v1/deployments/{id}/rollback
curl --request POST \
--url http://localhost:3000/api/v1/deployments/2489E9AD-2EE2-8E00-8EC9-32D5F69181C0/rollback \
--header 'Content-Type: application/json' \
--header 'X-API-Key: <X-API-Key>' \
--data '{ "reason": "Canary devices reported repeated container crashes" }'

Aborts the in-flight rollout and marks it rolled back. This does not redeploy a previous application version. The effect depends on the deployment history. A rollout of the first revision withdraws the deployment from every device it was released to, and the devices uninstall it. A rollout that follows a re-deploy (POST /deployments/{id}/redeploy) does not withdraw anything: devices that already run the new revision move back to the revision they ran before, and devices that still wait for their batch keep running it. The deployment stays in every device manifest. A device that ran nothing before the re-deploy is withdrawn as for a first revision. A rolled-back deployment can be re-deployed again.

id
required
string format: uuid

Deployment UUID

x-organization-id
string format: uuid

UUID of the organization (tenant) the request acts in. It selects the tenant and grants nothing: the server checks membership or an open tenant switch. Not needed for global operations. A malformed value returns 400. API keys are fixed to their own organization; another organization returns 403. The x-organization-source header grants nothing.

Media typeapplication/json
object
reason

Operator-supplied reason for the rollback, recorded in the audit trail

string
<= 500 characters
Example
Canary devices reported repeated container crashes

Rollback triggered successfully

Forbidden — caller lacks required permission

Deployment not found