Start-first update order limits in Docker Swarm rolling updates

Migrating a small application in Docker Swarm without downtime relies on the documented rolling update capability of docker service update. The default stop-first order terminates the old task before starting its replacement, which causes a brief outage. Switching to --update-order start-first is intended to avoid that gap by starting the new task before the old one stops.

However, the overlap window introduces operational uncertainty. While both tasks are running, the routing mesh may send traffic to the old and new versions concurrently, raising unresolved questions about published-port conflicts and mixed-version responses. The start-first strategy also assumes sufficient free capacity on the target nodes; if resources are exhausted, the replacement task cannot start and the update stalls. In addition, Docker does not drain in-flight connections at the proxy layer, so graceful shutdown depends on the application handling SIGTERM within the --stop-grace-period. Flag names and defaults are version-sensitive and should be confirmed against the installed Docker Engine release.

What practical limits should be considered when relying on start-first for a zero-downtime migration? How does the routing mesh behave when old and new tasks share a published port during the overlap? What resource and health-check constraints must be satisfied before attempting this update order in production?