deployment and operations
Container Images For PHP Applications
A container image packages the PHP runtime, required extensions, system packages, and application files into a repeatable artifact. The same image can move from CI to staging and production. That reduces environment drift, but it does not make state, secrets, or operations disappear.
Build One Environment-Neutral Artifact
Choose the PHP base image deliberately: CLI, Apache, and FPM variants serve different purposes. Install only the extensions and runtime packages the application needs. Composer dependencies for production should be installed predictably from the lock file.
FROM php:8.5-fpm
WORKDIR /app
COPY --from=composer:2 /usr/bin/composer /usr/bin/composer
COPY . /app
RUN composer install --no-dev --no-interaction --prefer-dist --optimize-autoloader
Do not bake environment secrets into image layers. Inject them at runtime from the deployment platform. Treat container filesystems as disposable: uploaded files, database data, and durable cache data belong in services or volumes chosen for that purpose.
Verify The Runtime Boundary
Build the image once, then promote that exact artifact. In staging, verify the PHP version, loaded extensions, entry point, file permissions, health endpoint, and application logs. Prefer an unprivileged runtime user where the platform permits it. A smaller image is useful, but reproducibility and a clear operating model matter more than chasing the smallest possible size.
Practice
Practice: Review A PHP Container Image
Review a PHP-FPM container image for a web application that stores uploaded invoices. Identify what belongs in the image, what must be supplied at runtime, and what must remain durable outside the container filesystem.
Requirements
- Pin a suitable PHP base image deliberately.
- Install only required extensions and runtime packages.
- Keep secrets out of image layers.
- Build image once.
- Run the same artifact through environments.
- Verify PHP version, extensions, entry point, and health.
Show solution
The image should contain the chosen PHP-FPM base, required extensions, application code, and locked production dependencies. Build it once and promote the same artifact through staging and production.
Inject secrets when the container starts; do not store them in the Dockerfile, image layers, or build output. Uploaded invoices need durable object storage or a deliberately mounted persistent volume. In staging, verify the PHP version, extensions, entry point, runtime user, permissions, logs, and health endpoint.