github/dokku
0
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

feat: send SIGTERM to old containers immediately on deploy

Browse Source 
The docker-local scheduler now sends `SIGTERM` to old containers immediately after a successful deploy via `docker container kill --signal=SIGTERM`, rather than waiting `wait-to-retire` seconds before signaling. This matches Heroku's graceful-shutdown contract and lets applications begin draining in-flight work as soon as proxy traffic switches. The existing `wait-to-retire` grace period and `stop-timeout-seconds` hard-stop continue to apply unchanged as the authoritative cleanup path.
This commit is contained in:
Jose Diaz-Gonzalez
2026-04-27 18:18:39 -04:00
parent f19227dcd9
commit 1161dda05e
4 changed files with 55 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/deployment/zero-downtime-deploys.md
View File

@@ -28,7 +28,9 @@ You may both create user-defined checks for web processes using the `healthcheck
### wait-to-retire
After a successful deploy, the grace period given to old containers before they are stopped/terminated is determined by the value of `wait-to-retire`. This is useful for ensuring completion of long-running HTTP connections.
After a successful deploy, Dokku immediately sends `SIGTERM` to old containers so the application can begin a graceful shutdown (draining in-flight connections, flushing buffers, and so on) the moment proxy traffic switches to the new containers. The old containers are then left running for the `wait-to-retire` grace period before being stopped, which sends `SIGTERM` again and ultimately `SIGKILL` after `stop-timeout-seconds`. This mirrors Heroku's [dyno shutdown behavior](https://devcenter.heroku.com/articles/dyno-shutdown-behavior).
The `wait-to-retire` value controls the grace period and is useful for ensuring completion of long-running HTTP connections.
```shell
dokku checks:set node-js-app wait-to-retire 30