A rolling update with start-first, and the capacity dip it avoids

The default update order stops a task before starting its replacement, so capacity dips during every deploy — invisible at eight replicas, a visible outage at two.

deploy:
  replicas: 4
  update_config:
    parallelism: 1
    delay: 10s
    order: start-first        # 3.4+; the default is stop-first
    failure_action: rollback
  rollback_config:
    parallelism: 0            # all at once, when rolling back

failure_action: rollback is the setting that turns a bad deploy into a brief blip rather than a manual recovery, and it depends on the healthcheck being meaningful — a container that reports healthy before it can serve traffic makes the rollback fire late or not at all. Rolling back all replicas at once is deliberate: the previous version is known good, so there is nothing to be careful about.