Blue-green deploy seems to keep adding more pods

I switched one project to the bluegreen deploy strategy. I want one web pod that stops when idle and one worker that always runs. After a few deploys I had 8 web pods and 5 worker pods.

Here is my config:

[build]
  dockerfile = "Dockerfile"

[deploy]
  strategy = "bluegreen"

[processes]
  web = "node server/build/web.js"
  worker = "node server/build/worker.js"

[http_service]
  internal_port = 8080
  force_https = true
  auto_stop_pods = "stop"
  auto_start_pods = true
  min_pods_running = 0
  processes = ["web"]

  [[http_service.checks]]
    grace_period = "15s"
    interval = "15s"
    timeout = "5s"
    method = "GET"
    path = "/health"

How do I stop this from happening?

I seem to remember that min_pods_running = 0 does not play well with blue-green: the old (blue) pods are stopped rather than destroyed, so they are not counted when the next deploy decides what to clean up. Try min_pods_running = 1 and see if the count stays stable.

The client is a non-profit, and five pods running when we only need one is a real difference for them. I will try it.

It would help to post the full output of lark deploy, plus lark pod list before and after.

Here is the end of a deploy log:

Updating existing pods in "atlas-prod" with bluegreen strategy
Creating green pods
  Created pod 801e36c62e5428 [worker]
  Created pod d8934e3b092768 [web]
Waiting for all green pods to be healthy
  Pod d8934e3b092768 [web] - 1/1 passing
Marking green pods as ready
Destroying blue pods
  Skipped 3 stopped pods (not running)

"Skipped 3 stopped pods" is the giveaway, I think.

That is the bug — stopped blue pods were skipped instead of destroyed. A fix is deploying now; in the meantime min_pods_running = 1 avoids it. Thanks for the clear report.

Count has been stable across six deploys. Thank you all.