PHP deployment guide

Update PHP in Docker: pull, rebuild and replace containers

Docker packages an application and its software into an image. Developers and server administrators create containers from that image to run websites. After a PHP security release, they need to update the image and replace containers serving customers.

By PHPFixes · Published October 24, 2026 · Sources checked October 23, 2026

In its October 22 PHP2Shell notice, Docker said updated PHP Official Images were available on Docker Hub and mirrored to Amazon ECR. Docker Hardened Images were also updated. The fixed upstream versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Availability gives administrators a starting point; their deployment still needs to use an updated image.

Identify each running PHP container

Start in the correct deployment project on a system you own or are authorized to administer. Identify the PHP service and every running copy. For Docker Compose, this narrow command lists container IDs for a service named php. Substitute your service name:

docker compose ps -q php

For each returned ID, inspect only the image reference, local image ID and status. Replace CONTAINER_ID with that ID:

docker container inspect --format 'reference={{.Config.Image}} image-id={{.Image}} status={{.State.Status}}' CONTAINER_ID

Then inspect that image, replacing IMAGE_ID with its local image ID:

docker image inspect --format 'digests={{json .RepoDigests}} platform={{.Os}}/{{.Architecture}}' IMAGE_ID

These commands read selected metadata. Docker documents Compose container listing, formatted inspection and image inspection. Keep the record private. Avoid publishing full inspection or Compose configuration output, which can contain credentials.

A tag such as php:8.4-fpm can point to a different image after its publisher updates it. Record the image identity alongside the tag. Docker lists image IDs and registry digests separately; do not assume their strings must match.

Choose the right image update

Read your deployment definition and build files. The next step depends on who creates the image your website runs:

Scroll sideways to see all columns.

Choose the update that matches your deployment
Your deployment uses	What the administrator prepares
A ready-made PHP image	Its updated reference or digest, followed by replacement containers.
Your application image built from a PHP base	A new application build using the updated base, followed by deployment.
An application supplier’s complete image	The supplier’s fixed application image and its update instructions.

Pulling an official PHP image does not rebuild your separately named application image. Keep the image type and operating system your application expects. The official PHP image guide explains that an FPM image needs a separate web server, while an Apache image includes one. Switching between them, or between Alpine and Debian, needs compatibility testing.

Refresh a custom build

Docker describes images as immutable snapshots: software included during a build stays in that image. Review every relevant build stage and the image used by the final application.

Docker’s build documentation distinguishes two options. --pull checks for a newer base image. --no-cache reruns build steps without cached layers; by itself, it does not fetch a newer base. The Compose build reference also lists these options.

If your Dockerfile pins a base with @sha256:..., select and review a fixed replacement digest. Pulling again preserves that pin. Docker’s digest guidance explains this tradeoff: a pin gives repeatable builds, while security updates require changing it.

Replace containers through your deployment

Compose pull downloads service images without starting containers. A Compose restart restarts existing service containers and does not apply changed Compose settings. Use your deployment’s replacement procedure to put the prepared image into service.

Compose up recreates containers when their image or configuration changes, preserving mounted volumes. Before replacement, confirm where persistent data lives, retain the prior image reference and prepare application-specific recovery. Replacing a container can interrupt requests.

For Kubernetes, a managed platform or another scheduler, follow that platform’s rollout procedure. Compose commands do not update those deployments. Check every running copy and host included in the rollout.

Check new requests and customer tasks

After deployment, collect image identities again and confirm every intended container was replaced. Use your application’s trusted diagnostics to check the PHP serving a new website request. A command-line PHP version alone cannot establish which PHP configuration handles web traffic.

Test the tasks your site depends on, such as signing in, uploading a file, calling an API and processing background jobs. Record failures before declaring completion. Keep the build reference, deployed image identity, rollout time and application check results together so another administrator can identify what customers are running.

Sources and dates

Docker’s availability statement was published October 22. The official PHP image source update and Official Images update merged October 21; merge dates do not establish when every image variant reached a registry. Docker’s linked command documentation was checked October 23 and shows no publication date.

Next: use the PHP2Shell check-and-verify guide for PHP supplier details and running website checks.