Why your "zero-downtime" Docker Compose deploy still drops requests

Mitya Zima — Mon, 28 Sep 2026 16:47:35 +0000

For a while I was pretty happy with my deploy setup. Push to main, GitHub Actions builds an image, SSHes into the VPS, pulls, restarts. Simple, no Kubernetes, nothing to babysit. Then I actually measured what happened to in-flight requests during a deploy instead of just eyeballing it, and it wasn't zero.

The stack is nothing exotic. Docker Compose, Traefik in front, one VPS, no orchestrator, because for a handful of services on one box an orchestrator is more infrastructure than the problem justifies. What I wanted was for docker compose up -d to stop yanking the old container out from under active connections.

docker-rollout (https://github.com/wowu/docker-rollout) does the clever part: starts the new container next to the old one, waits for it to report healthy, points the proxy at it, only then removes the old one. Good piece of engineering, and the reason I didn't have to write that logic myself.

Wiring it into CI is where it got less clean. Upload compose files over SSH, log into a registry without leaving creds lying around, run migrations before the switch, roll out several services in the right order. None of it is individually hard, it's just the kind of glue you copy between repos and half-remember how it works six months later.

Here's the part that actually cost me an afternoon. A healthcheck tells docker-rollout the new container is ready. It says nothing about the old one. Traefik keeps routing to it right up until it's removed, and if that removal lands mid-request, that request just dies with a 502. I only caught it because I put a deploy under constant load and counted failures instead of curling the site twice and calling it done, which is roughly how I'd been "testing" this before. Every single deploy was dropping a handful of requests, consistently, invisibly.

The fix is connection draining. Make the healthcheck also check for a marker file:

healthcheck:
  test: test ! -f /tmp/drain && curl -fsS http://localhost:8000/health
  interval: 5s
  retries: 1

and before stopping the old container, touch that file and wait:

pre-stop-hook: touch /tmp/drain && sleep 10

Touching /tmp/drain makes the healthcheck fail on purpose. Traefik notices within interval × retries and quietly stops sending new traffic there. The sleep needs to cover that window plus whatever your slowest in-flight request takes. By the time docker-rollout actually stops the container, nothing's running on it anymore to interrupt. Ran the same load test with draining added: zero dropped requests.

I packaged the whole thing, file upload, registry login, pull, a pre-deploy hook for migrations, rollout with draining, automatic rollback if a release never goes healthy, into a GitHub Action (https://github.com/mtizima/docker-rollout-action):

- uses: mtizima/docker-rollout-action@v1
  with:
    host: ${{ secrets.SSH_HOST }}
    user: deploy
    ssh-key: ${{ secrets.SSH_KEY }}
    known-hosts: ${{ secrets.SSH_KNOWN_HOSTS }}
    project-dir: /opt/myapp
    services: web

Everything runs in one SSH session, plain bash, nothing to install on the runner beyond ssh itself. Inputs go over stdin instead of the command line so nothing shows up in ps, and registry credentials sit in a Docker config that's deleted the second the deploy finishes.

Couple of real constraints worth knowing before you touch this. Services you roll out this way can't have container_name or published ports, since two containers of the same service run side by side during the swap, so you need a proxy routing to them instead. And they need an actual Docker healthcheck. Without one, docker-rollout just waits a fixed number of seconds and hopes for the best, which is exactly the kind of thing that gets you a repeat of this whole post.

If you're running Kubernetes already, none of this is for you. If you're on one or two boxes with Traefik or nginx-proxy in front and you've never actually measured whether your deploys drop requests, it might be worth five minutes to check. Mine didn't, until it did.

DEV Community: Mitya Zima

Why your "zero-downtime" Docker Compose deploy still drops requests