Zero-downtime deploys
Zero downtime is four separate problems in one deploy: requests in flight, requests arriving during the swap, jobs that are running, and old code meeting a new schema. The lessons follow one application deployed with Kamal, Puma and Solid Queue. They cover SIGTERM and SIGKILL, Docker's grace period, the exec line in the entrypoint, Solid Queue's shutdown_timeout, idempotent jobs backed by unique indexes, stale JavaScript in open browsers, Turbo asset tracking, and a five-step deploy order for schema changes. It ends with a plain score of each window and a challenge that models the shutdown grace period.
What you'll learn
- ✓The three meanings of zero downtime and the four windows of a deploy
- ✓How Puma drains on SIGTERM and why exec in the entrypoint matters
- ✓How Solid Queue releases or strands jobs depending on shutdown_timeout and the stop grace
- ✓Why idempotency and unique indexes make retried jobs safe
- ✓How Turbo uses data-turbo-track and asset digests to reload stale pages
- ✓A deploy order that keeps the schema compatible with running and arriving code
What downtime actually means
"Zero downtime" is a claim that needs a definition before it can be tested, and the useful definition is narrower and more demanding than the usual one.
Read the full lesson free →Curriculum
7 lessonsWhat downtime actually means
Defines three meanings of zero downtime and the four windows where a deploy can lose something.
How Puma shuts down
Explains SIGTERM, SIGKILL, Docker's ten-second grace period, and why exec in the entrypoint lets Puma drain.
The jobs that were running
Shows how Solid Queue inside Puma shuts down, why shutdown_timeout stays under the stop grace, and idempotency.
The client-side window
Covers stale JavaScript in open browsers, Turbo's data-turbo-track reload check, and the users it still misses.
The deploy order that works
Sets the rule that the schema must work with running and arriving code, with a five-deploy order.
What this deploy actually achieves
Scores this application against the four windows, separating what rests on mechanisms from what rests on habit.
Putting it together
Reviews the four windows and their owners, then implements shutdown_outcome, a model of the grace period.