Deployment Pipeline
How the queue, build, health gates and rollback work.
Every deployment follows the same pipeline, visible live in the dashboard:
PENDING → BUILDING → DEPLOYING → SUCCESS — or FAILED/CANCELED. Build
and runtime logs stream over the socket connection; the deployment details
modal shows logs, containers, attempts and node placement.
Queue and concurrency#
Deployments run inside your organization's build queue. The plan sets the
concurrency (Free: 1, Pro: 3, Enterprise: configurable up to 50), and
org concurrency in the CLI shows and adjusts it. When the slots are full,
new deployments wait with a position and an estimated start — the queue never
drops work, and rollbacks/restores jump the queue.
Deployment strategies#
| Strategy | Behavior | Default for |
|---|---|---|
| Blue/green | The new container starts and passes its health gate before the old one stops. Traffic never hits a half-ready process. | Most services |
| Recreate | The old container stops first, then the new one starts. | Compose services using fixed host ports |
| Serialized cutover | A single-writer handover for databases and other stateful datastores: the old instance drains, the new one takes over. | Auto-detected datastores, or opt-in via x-zensailor.deployment.strategy: serialized |
If the new deployment fails its health gate, the previous version stays running — you do not lose a working service to a bad release, and the failure is marked with the reason on the deployment.
Cancelling#
A queued or building deployment can be cancelled from the dashboard or with
zensailor service deployment <id> (with cancel). Cancel stops the pipeline
cleanly; any container already started by a blue/green deploy is removed.
Logs: build logs are permanent deployment artifacts; runtime logs are ephemeral per container and tail/filter from the service's Logs tab.