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.
Deploy safetyZero-downtime deploys
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.
curl -fsSL https://levelrail.com/install.sh | sudo sh
Four guarantees between a deploy and serving traffic
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
What does zero downtime require from my app?
A readiness endpoint that returns success only when the app can serve. Cutover waits for it.
What if the new version never becomes ready?
Traffic stays on the current release and the deploy is reported as failed, with logs and a reason.
Can a stale build overwrite a newer one?
Not for automated deploys: the stale-deploy guard skips them. Manual deploys and explicit rollbacks always run.
Does it work on one server?
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.