Zero-downtime deploys
The new version must pass a health check before it takes any traffic, and the old one stays around for rollback.
Every deploy — from dock deploy, a Git push, or a redeploy from the dashboard — follows the same sequence, and at no point does your app stop serving requests.
The new version builds
The new container builds and starts while the current, live version keeps serving all traffic exactly as before. Nothing about the live app changes yet.
It's health-checked
The new version must respond successfully to a health check before it's considered ready. If it never becomes healthy — a startup crash, a missing environment variable, an app that never binds to its port — the deploy is marked failed and traffic never moves to it. The previous version keeps running the whole time.
Traffic switches
Once healthy, traffic switches to the new version. This is instant from the outside — no gap where a request would fail because nothing was listening.
The old version is kept
The previous version isn't deleted immediately. If the new version starts misbehaving after taking traffic — errors that only show up under real load, something the health check didn't catch — you can roll back to it.
Rolling back
Roll back to the previous version from your project's Deployments tab. This switches traffic back the same way a normal deploy switches it forward — no downtime, no rebuild required, since the old container is already there.
Why a failed health check doesn't take your site down
Because traffic only moves to the new version after it passes the health check, a broken deploy fails loudly during the deploy itself rather than silently after your users start hitting it. Check dock logs --follow while a deploy is running if you want to watch this happen in real time.