How I assessed 74 Docker containers and prepared PHP patches without stopping production
The goal was to reduce outdated PHP runtime risk across several projects. My approach was to record the live system first, prepare candidate changes and verify them separately. A tested patch and authorization to deploy it are separate decisions.
What the work delivered
I inventoried actual runtimes, images, extensions and application startup paths. Security patches were prepared for 12 projects, with phpMyAdmin treated as a separate image. The deliverable was a reviewable change set and candidate images, not an upgraded production estate.
Each PHP branch required its own compatibility assessment. Target versions were selected against applicable fixes and application requirements; a new image tag alone was not accepted as evidence.
Why inventory came first
The version running in a container may differ from what its Dockerfile suggests. Dependencies, background services and startup configuration also matter. Without this context, a successful build can say very little about the actual service.
Read-only discovery was separate from changes. The verification stage used isolated copies and build contexts without production volumes, working secrets or existing data.
How isolation worked
Separate candidate images
New builds used separate tags. Original production Dockerfiles and Compose configurations were preserved.
Synthetic data
Database, Redis, queue and scheduler checks ran in a separate environment without real business jobs or external sends.
Bounded resources
Main builds ran sequentially with CPU and memory limits to control load on the shared server.
Explicit applicability
An inapplicable or untested check was not reported as a pass.
What 13 successful builds establish
All 13 target runtime/image builds succeeded. Nine Laravel copies also passed Composer platform requirements, PHP lint, CLI boot and HTTP health checks. HTTP verification required the expected body without a fatal error, not merely a 200 status.
- SQLite, isolated MariaDB and MySQL 8.4 were checked using test data.
- Redis checks used the relevant client drivers where Redis applied.
- Workers processed synthetic jobs; scheduler checks used a safe test callback.
- An applicable WebSocket service passed handshake and connection-event checks.
- phpMyAdmin passed HTTP and a query against an isolated test database.
What “without stopping production” means
Production was not upgraded during this stage: no commit, push, deployment, manual restart or replacement of live containers was performed. All 74 original container/image IDs and the source Dockerfiles were preserved.
Three workers showed the expected hourly lifecycle consistent with their configured maximum runtime. The accurate claim is no manual restarts or rollout, rather than no process ever restarting.
This was not a measurement of zero latency impact. Resource use was bounded, but no separate load experiment established that claim.
Verification limits
- Complete business workflows and actual production routing were not tested.
- Mail, Telegram, external RPC and queues containing existing live data were not exercised.
- PHP upgrades do not automatically resolve Composer or system-library advisories.
- Unsupported legacy stacks require a separate migration or verified backport plan.
- This test package did not rehearse production restoration from backup.
Before a production rollout
Verified backups, rollback criteria, a maintenance window and a coordinated update plan for workers and scheduler are still required. Production deployment can then be approved separately; a successful build is not that approval.
Frequently asked questions
Do successful builds authorize deployment?
They establish the listed technical checks. Backup/rollback readiness, business verification and separate deployment approval are still required.
Why not update PHP inside a live container?
Changes without a reproducible image and verification complicate compatibility assessment and rollback. I use candidate builds and a controlled release process.