Describe the bug
After rebuilding an image (podman-compose build <service>), running podman-compose up -d --no-deps <service> does NOT recreate the container with the new image. The existing container keeps running with the old image, even though podman images confirms the image tag now points to a new image ID.
This differs from Docker Compose, where up -d detects the image change and auto-recreates the container.
To Reproduce
-
Start a service:
podman-compose --in-pod=false up -d api
-
Verify the image ID:
podman inspect api --format '{{.Image}}'
# e.g. 5c64194536d1...
-
Rebuild with a changed source file (producing a new image):
podman-compose --in-pod=false build --build-arg BUILD_DATE=$(date -u +%Y-%m-%dT%H:%M:%S) api
# New image: 9a10b264aac6...
-
Verify the tag points to the new image:
podman images localhost/portfolio-manager_api --format '{{.ID}} {{.Tag}}'
# 9a10b264aac6 dev
-
Try to recreate:
podman-compose --in-pod=false up -d --no-deps api
# No output, no recreation
-
Check — container still uses old image:
podman inspect api --format '{{.Image}}'
# Still 5c64194536d1... (old image)
Expected behavior
Container should be recreated with the new image, matching Docker Compose behavior.
Workaround
Manually stop + remove + up:
podman stop api
podman rm -f api
podman-compose --in-pod=false up -d --no-deps api
This is fragile because podman rm fails when dependent containers exist (see #1177), forcing reverse-dependency-order removal.
Environment
- podman-compose version: 1.5.0
- podman version: 5.8.2
- OS: Linux (Hostinger VPS, Ubuntu 24.04)
--in-pod=false used throughout
Root cause hypothesis
podman-compose may be comparing the container's current image ID to the compose config's image tag, but resolving the tag at config-parse time (before the build). After a rebuild, the tag resolves to a new ID, but compose's cached config still references the old one. Alternatively, compose may not be checking image ID at all and only recreating when the compose YAML changes.
Describe the bug
After rebuilding an image (
podman-compose build <service>), runningpodman-compose up -d --no-deps <service>does NOT recreate the container with the new image. The existing container keeps running with the old image, even thoughpodman imagesconfirms the image tag now points to a new image ID.This differs from Docker Compose, where
up -ddetects the image change and auto-recreates the container.To Reproduce
Start a service:
Verify the image ID:
Rebuild with a changed source file (producing a new image):
Verify the tag points to the new image:
Try to recreate:
podman-compose --in-pod=false up -d --no-deps api # No output, no recreationCheck — container still uses old image:
Expected behavior
Container should be recreated with the new image, matching Docker Compose behavior.
Workaround
Manually stop + remove + up:
This is fragile because
podman rmfails when dependent containers exist (see #1177), forcing reverse-dependency-order removal.Environment
--in-pod=falseused throughoutRoot cause hypothesis
podman-compose may be comparing the container's current image ID to the compose config's image tag, but resolving the tag at config-parse time (before the build). After a rebuild, the tag resolves to a new ID, but compose's cached config still references the old one. Alternatively, compose may not be checking image ID at all and only recreating when the compose YAML changes.