Why an Updated Docker Image Does Not Guarantee Laradock Will Run It

After a security update, it is easy to produce a new Docker image, verify the required PHP version inside it, and assume the problem is closed.

But Docker Compose does not run an abstract "latest safe image". It uses the configuration produced after merging Compose files, environment variables, image, build, and overrides.

In my local Laradock setup, this became a separate verification step: after preparing patched PHP-FPM, workspace, and phpMyAdmin images, I still had to prove that the next start would not restore the old image references.

A Docker image can already exist locally and even pass validation. That still does not mean the Compose service points to that image reference.

The service may still contain an old image:, a remaining build: section, another override, or be started with a different set of -f files.

That is why after preparing a new image I verify both the image itself and the effective model Docker Compose actually sees.

docker compose config -q does not start containers. It checks whether Docker Compose can resolve the configuration without syntax and some structural errors.

For a security change, this is an important first guard: if the override is invalid, there is no reason to proceed to container recreation.

This command is more useful than a simple docker image ls when the question is: "What will Compose actually use?"

docker image ls shows what exists locally. docker compose config --images shows the image references resolved from the Compose model.

If the patched image exists locally but is absent from config --images, the image alone fixes nothing.

The most dangerous mistake here is validating one Compose file set but starting the environment with another command.

If Laradock uses a base file plus several overrides, every verification command must use the same -f set that will be used on the next start.

A tag is convenient for humans, but it is not an immutable image identity. Today my-php:8.5-secure may point to one image ID, and after a rebuild the same tag may point to another.

During a controlled security update, I record both the tag and the immutable image ID.

Three things matter here:

1. the image reference returned by docker compose config --images;
2. the image ID currently behind that tag;
3. the image ID actually used by the container.

Only when these values line up do you have a clear picture of the current state.

Even when image: points to the intended image, an active build: section can change what happens on the next command depending on how Compose is invoked.

In my case, the safe override was designed so the effective model used pinned image references for the required PHP services and did not silently rebuild them from an older base.

Starting a container once with the correct image ID is not enough. If the next ordinary docker compose up omits the required override, the environment can return to the old image reference or rebuild again.

That is why an image pin must be part of a repeatable Compose configuration rather than only a manual command used during an emergency update.

Before recreating containers, I want to see the smallest expected change: image references changed for the required PHP services while unrelated services, ports, volumes, and networks stayed unchanged.

This is a good point to save sanitized effective configurations before and after the change and compare them.

Before any mutating Compose command, I want clear answers to several questions:

• is the required Compose file set valid;
• does config --images show the patched image references;
• are the immutable image IDs known;
• is there an unwanted build: for services that should use prepared images;
• does the override unexpectedly change unrelated ports, volumes, or services;
• will the next command use the exact same -f file set.

In a Docker security update, two facts must stay separate: "I created a patched image" and "Laradock is guaranteed to use it". They are not the same thing.

My practical conclusion is simple: after updating images, verify the effective Compose model, image references, immutable image IDs, and the persistent override. Only then move to a controlled container recreation.

The next problem worth examining is why Docker Compose can sometimes bring up more services than expected even when the command looks local and targeted.