Podman can automatically pull new container images before starting a container, but it doesn’t update running containers.
Let’s see it in action. Imagine you have a container running an old version of nginx:
podman run -d --name my-nginx -p 8080:80 docker.io/library/nginx:1.23.0
Now, a new version of nginx is released, say 1.24.0. If you simply restart the container without telling Podman to check for a new image, you’ll still be running the old version:
podman restart my-nginx
To ensure you’re running the latest image, you need to explicitly tell Podman to pull it. The podman run command has a --pull flag that controls this behavior.
Here’s how you’d use it to pull the latest tag (which usually points to the most recent stable release):
podman run -d --name my-nginx --pull=always docker.io/library/nginx:latest
The --pull flag can take three values:
missing: Podman will pull the image only if it doesn’t exist locally.newer: Podman will pull the image if a newer version is available on the registry. This is the default behavior.always: Podman will always attempt to pull the image, regardless of whether a local version exists or if it’s newer. This is the most aggressive option for ensuring you have the latest.
Let’s try that always option with a specific version to demonstrate:
# First, run an older version
podman run -d --name my-nginx --pull=missing docker.io/library/nginx:1.23.0
# Now, try to "update" to a newer version using --pull=always
podman run -d --name my-nginx --pull=always docker.io/library/nginx:1.24.0
After the second podman run command, if you check the image ID for my-nginx, it will be different, reflecting nginx:1.24.0.
podman inspect --format '{{.Image}}' my-nginx
This mechanism is crucial for development and testing environments where you want to quickly iterate with the latest base images. For production, you’d typically pin to specific image tags (e.g., nginx:1.24.0 instead of nginx:latest) and manage updates through a more controlled deployment process, but --pull=always can still be useful in CI/CD pipelines.
It’s important to understand that --pull only affects the image before the container is started or recreated. It does not update containers that are already running. If you want to update a running container, you typically need to stop it, remove it, and then run a new container with the updated image. Podman’s podman auto-update command is a separate utility that aims to automate this process for containers managed by systemd units, but it’s not directly tied to the --pull flag within podman run.
The interaction between --pull and image digests is also worth noting. If you specify an image by its digest (e.g., docker.io/library/nginx@sha256:...), the --pull flag will attempt to pull that exact digest, even if you have a different version of nginx locally. If the specified digest doesn’t exist, the pull will fail.
A common pitfall is relying on --pull=newer or --pull=always with the latest tag in production. While convenient, the latest tag can be updated by upstream maintainers at any time, potentially introducing breaking changes or unexpected behavior. For reproducible deployments, always use specific version tags (e.g., nginx:1.24.0) or image digests.
The next step after mastering image pulling is understanding how to manage container lifecycles automatically, especially when dealing with systemd services.