https://stackonward.com/tags/connection-drain/Recent content in Connection Drain on StackOnwardHugoen-USFri, 11 Sep 2026 05:18:00 +0800https://stackonward.com/posts/single-server-short-downtime-deployment/Fri, 11 Sep 2026 05:00:00 +0800https://stackonward.com/posts/single-server-short-downtime-deployment/<p>A Docker Compose blue-green deployment on one server starts the candidate, waits until the app is ready, validates and switches the Caddy upstream, proves the public hostname, drains old connections, then stops the old version. Do not delete the old container before the candidate is taking traffic.</p> <p>That sequence can shrink the unavailable window. The host, disk, Docker daemon, and shared database are still single points of failure, so measure the window instead of calling the result zero downtime.</p> <figure> <img src="https://stackonward.com/images/posts/single-server-short-downtime-deployment/en/blue-green-release-flow.svg" alt="Old version keeps traffic on 18080; candidate starts on 18081 and passes a loopback health check; Caddy switches, the public hostname is verified, then old connections drain" loading="lazy" decoding="async"> <figcaption>The gateway switch is the only public cutover. Candidate startup and warmup happen before that switch.</figcaption> </figure> <h2 id="docker-compose-blue-green-only-works-under-these-constraints">Docker Compose blue-green only works under these constraints</h2> <p>Run two app instances on one host only when the service meets all of these conditions:</p>