Workloads
How deployments work
Strategies, revisions, previews, and zero-downtime releases.
#Strategies
| Strategy | Steps |
|---|---|
| recreate (default) | init → provision → health_gate → complete |
| rolling | init → scale_up → health_gate → scale_down → complete |
| blue-green | init → provision → health_gate → promote → verify → drain_old → complete |
| canary | init → provision → health_gate → drain_canary → promote → complete (default 10%) |
Rollout progression
#Status honesty
Deployment status runs pending → provisioning → in_progress → awaiting_health → promoting → completed, with failed, cancelled, and rollback states. Only one active deployment per server is allowed; a second one is rejected, not queued silently. Images must pin a @sha256 digest. If no runtime or traffic executor is wired, the API refuses instead of reporting success.
The health-check port must be 0–65535, the path must be a local absolute path, and the host may only be empty, localhost, or a loopback address.
#Revisions and rollback
Each deployment records a revision (image ref, compose manifest ref, git SHA, config hash). Rollback creates a mirrored recreate deployment against a completed target — never the live one — and writes a rollback audit row. Deployment versions can be listed, compared (diff against live), and rolled back per app or per server.
POST /admin/deployments/rolling|/blue-green|/canary|/recreate
GET /admin/deployments/:id /:id/steps
GET /apps/:appId/deployment-versions /:id/diff
POST /apps/:appId/deployment-versions/:id/rollback {reason}#Previews and zero-downtime
Preview deployments build per-PR environments with TTLs and HMAC-verified webhooks. Zero-downtime releases are a separate flow: deploy is synchronous while health-check and promote run async, with explicit promote and rollback actions per release.