Skip to main content
A deploy is live only when it is actually ready Traffic cuts over after the new container passes a real readiness probe, the previous release stays available, and four guarantees keep the wrong build from serving. Read deploy safety | View on GitHub

​
Four guarantees between a deploy and serving traffic

Digest-truthful deploys

A deploy is pinned to the image digest it resolved, so a moved tag cannot change what serves. Rollbacks deploy the recorded pinned reference.

Stale-deploy guard

Automated deploys carry a per-app sequence number and commit order, so an older build still in flight cannot overwrite a newer one. Manual deploys and rollbacks are never rejected.

Freeze windows

Block automated deploys on a cron schedule, for example every Friday evening, and release them afterwards.

Instant rollback window

The previous release is held briefly after cutover, and prior images stay pinned so garbage collection cannot remove a rollback target.

Three strategies

Blue-green, rolling or recreate, all gated on readiness and liveness probes.

A reason for every state

The reconciler records a status condition with a reason after each pass, so a stuck deploy explains itself.

​
Frequently asked questions

A readiness endpoint that returns success only when the app can serve. Cutover waits for it.
Traffic stays on the current release and the deploy is reported as failed, with logs and a reason.
Not for automated deploys: the stale-deploy guard skips them. Manual deploys and explicit rollbacks always run.
Yes. The same cutover logic runs on a single node.

​
Ship without holding your breath

Read the deploy safety guide or try it on a spare server. Read deploy safety | View on GitHub
Last modified on October 12, 2026