[BUG] Compose 5.6.1 does not recreate containers after pulling updated images (containerd image store)

Start by tracing how docker compose up compares the locally pulled image with the image recorded for an existing container, especially the image digest reconciliation changes mentioned for Compose 5.5.0. Reproduce with a mutable tag, docker compose pull, then docker compose --dry-run up -d; done means ordinary up -d detects the changed image and recreates the container. The issue names no source files or tests, so locating the relevant code and test coverage will take project familiarity.

Description

After pulling an updated Docker image, docker compose up -d does not recreate the existing container, even though the locally downloaded image ID differs from the image used by the running container.

This behavior was reproduced with two independent services, postgres:16 and redis:latest, on October 21–22, 2026.

Expected behavior: Docker Compose detects that the image has changed and recreates the affected container using the updated image.

Actual behavior: Compose reports the existing container as healthy/running and does not recreate it. The container continues running the old image.

Running docker compose up -d --no-deps --force-recreate <service> successfully recreates the container using the newly downloaded image.

The issue occurs with Docker Compose v5.6.1, Docker Engine 29.9.2, and the containerd image store. No COMPOSE_ or DOCKER_ environment overrides were set.

This may be related to the image digest reconciliation changes introduced in Compose 5.5.0, although the cause has not been established.

Steps To Reproduce

1. Create a Compose project using an image with a mutable tag, such as redis:latest.
2. Start the project using docker compose up -d.
3. Wait until a newer image is published to that tag.
4. Run docker compose pull redis.
5. Confirm the downloaded image ID differs from the running container image ID.
6. Run docker compose up -d.
7. Observe that Compose reports the container as healthy/running without recreating it.
8. Compare the image IDs again. The running container still uses the previous image.
9. Run docker compose up -d --no-deps --force-recreate redis. The running image then matches the newly downloaded image.

Actual Redis reproduction:

Before pulling, the running container image was:

sha256:5c02d7c0f8d75af45958c0294a8004f2e14b42df98a1103e3a669aa7ec787be6

After docker compose pull redis, the new local image was:

sha256:97ec88159e6d7cfb5ddef9015386087d58a912de80112f06ebdfa78fa5989901

Both images contained Redis 8.10.2.

After docker compose up -d, the running container was still using 5c02d7c0f8d7.

A dry run also failed to identify a need for recreation:

$ docker compose --dry-run up -d --no-deps redis
[+] up 1/1
✔ Container sure-redis-1 Running

The current Compose configuration hash matched the container's recorded configuration hash:

60fc3385a6508b479182c302719059b7dc8fbfec960bdf5d04b3e19cbb6532ef

After --force-recreate, the running image correctly changed to 97ec88159e6d.

PostgreSQL reproduction: The same behavior occurred with postgres:16. The newly downloaded image ID was sha256:9e2cf6287f25c3151f4c9421ccce2b17f3e60061c111a29165e0d2cdd9ff0a97, but the running container retained sha256:a902560563d3a5661228585f53474c5065e7f273b21ffd77e555a8b5682c5690 until forced recreation.

Compose Version

Docker Compose version v5.6.1

Docker Environment

Client: Docker Engine - Community
 Version:    29.9.2
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.38.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v5.6.1
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 4
  Running: 4
  Paused: 0
  Stopped: 0
 Images: 7
 Server Version: 29.9.2
 Storage Driver: overlayfs
  driver-type: io.containerd.snapshotter.v1
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: b7a25261e029d68978bbf290df0a62fc819b3c51
 runc version: v1.5.2-0-g29dd3dc2
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 7.0.14-22-pve
 Operating System: Debian GNU/Linux 13 (trixie)
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 2GiB
 Name: sure
 ID: <redacted>
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
  ::1/128
 Live Restore Enabled: false
 Firewall Backend: iptables
  EnableUserlandProxy: true
  UserlandProxyPath: /usr/bin/docker-proxy

Anything else?

Docker Engine 29.9.2 and Docker Compose 5.6.1 are running inside an unprivileged Proxmox LXC container, using Debian 13 (Trixie), kernel 7.0.14-22-pve, overlayfs storage, and the containerd snapshotter (io.containerd.snapshotter.v1).

The behavior was reproduced independently with both postgres:16 and redis:latest. Normal docker compose up -d failed to recreate the containers after pulling updated images, while --force-recreate worked correctly.