This is what I meant was false. We definitely wait at least 60 seconds - configurable - before killing old containers.

Maybe my explanation wasn't clear. Although we keep the old container around, new traffic is sent to the new container right away.

This can lead to 502s if your app doesn't bind to the port right away, an easy way to repro this is using a setTimeout around the listen call in Heroku's sample node.js app.

Maybe this is an edge-case and not worth bringing up in the docs.

Thoughts?

@josegonzalez what are you saying is false?

The sentence regarding DOKKU_CHECKS_WAIT is true. We should also add a mention of DOKKU_WAIT_TO_RETIRE as that is was controls how long the old container has to fulfill in-flight requests before being killed.

There's a short wait for the container to start, then the checks are run against it, before switching traffic. So if the new container is not able to handle request, traffic keeps flowing to the old one, new container gets destroyed.

The long timeout servers two purposes. First, some responses are just slow. Second long lasting connections (eg server sent events), helps to gradually migrate those over to new server.

👍