php

What is PHP?

The PHP image packages the PHP interpreter and its standard extension set so you can run PHP applications in a container without managing runtime installations on the host. PHP is one of the most widely deployed server-side languages on the web, powering a large share of the internet's applications — from custom-built platforms running Laravel, Symfony, or CodeIgniter to widely deployed open-source software like WordPress, Drupal, Magento, and Nextcloud. The official image ships in three execution model variants: CLI for running scripts and console commands, FPM (FastCGI Process Manager) for serving PHP over FastCGI behind a web server like nginx, and Apache-embedded for running PHP directly inside an Apache httpd process in a single container. It includes the most common extensions in the default build and exposes the docker-php-ext-install and docker-php-ext-enable tooling so Dockerfiles can add extensions like pdo_mysql, redis, gd, intl, or opcache at build time. The PHP image is used by web development teams deploying application frameworks, by platform teams building standardized base images for PHP workloads, and by operators running open-source PHP software in containerized infrastructure where a reproducible, version-pinned runtime is needed across development, staging, and production environments.

What is Echo's PHP image?

Echo's PHP image is a hardened build of PHP on Echo's hardened base. Echo images are designed to be a drop-in replacement: swap the image reference in your Dockerfile or deployment manifest and CVEs go to zero without disrupting your application runtime, extension configuration, or FPM pool setup. Every image is tested across clouds, image use cases, and deployment targets. Echo ships every image in two variants:

• Distroless variant — optimized for runtime use, with the smallest possible attack surface
• Default variant — includes essential build tools, package managers, and shells for teams that need operational access

For production PHP deployments, the distroless variant keeps all runtime operations — request handling, extension loading, FPM process management, and opcache behavior — fully intact while minimizing exposure; the default variant suits application and platform teams that need shell access for extension installation, php.ini tuning, FPM pool configuration, or debugging application behavior at runtime.

What is the difference between Echo's PHP image and the public PHP image?

Public PHP images ship on bases that include OS-level tooling convenient for development but which contribute CVEs that accumulate on a runtime serving live application traffic in production. PHP applications are among the most common targets for web-based attacks — but the threat model for the container image goes beyond application-layer vulnerabilities. The PHP runtime image runs continuously with access to your application code, database credentials, session data, file upload paths, and environment variables carrying secrets injected by your orchestrator. OS-level CVEs in the base image — particularly in libraries loaded by PHP extensions such as libxml2, libpng, libcurl, or openssl — create exploitable paths that bypass application-layer controls entirely, allowing attackers to escalate from a web request to host-level access without ever touching your PHP code. For high-traffic PHP applications, the image is also the largest single source of scanner noise in the CI pipeline — every dependency in the base image becomes a finding your security team must triage, even when none of it is reachable from the application. Echo's build retains everything PHP needs for request serving, extension loading, FPM process management, and CLI execution while removing the packages that don't belong in a production PHP runtime. As we covered in our post on how to protect your company from software supply chain attacks, runtime images that serve live web traffic are the widest attack surface in the container stack — they combine inbound network exposure with direct access to application secrets and data. Echo commits to a 7-day SLA for critical and high severity vulnerabilities, and 10 days for medium, low, and unknown — with vulnerabilities triaged within 24 hours. Echo images are recognized by all major scanners and mirrored to all major registries, so they fit into existing pipelines without changing your registry, scanner, or runtime tooling.

FAQ

Can I replace my PHP image with Echo's PHP image?

Yes. Echo's PHP image is a drop-in replacement. Update the FROM line in your Dockerfile and your application keeps running. PHP extension loading, FPM pool configuration, php.ini and php-fpm.conf settings, opcache behavior, and CLI script execution all continue to work without changes to your application code, Composer dependencies, or web server configuration. If your Dockerfile uses docker-php-ext-install to add extensions at build time, those instructions continue to work on Echo's image.

Is Echo's PHP image FIPS-validated?

Yes. Echo's FIPS-validated images use cryptographic modules with an active FIPS 140-3 CMVP certificate, making them fit for federal use — unlike FIPS-compliant images that haven't been validated. This matters for application teams running PHP workloads inside FedRAMP boundaries where a runtime that handles inbound HTTPS traffic, authenticates to databases and external APIs, and processes user data must meet cryptographic requirements across the full stack — including the OpenSSL and libcurl versions bundled with the PHP runtime.

What is Echo's vulnerability management SLA on the PHP image?

Echo commits to a 7-day SLA for critical and high severity vulnerabilities, and 10 days for medium, low, and unknown — with vulnerabilities triaged within 24 hours. Patches are mirrored automatically into your private registry so you're always running a clean version — critical for a web runtime image that serves live application traffic, holds database credentials and session data, and is directly reachable from the public internet in most deployment configurations.

Is Echo's PHP image distroless?

Echo ships every image in two variants: a distroless variant optimized for runtime use, and a default variant that includes essential build tools, package managers, and shells. For production PHP deployments serving live traffic, the distroless variant is the leaner, more secure choice; for application and platform teams that need shell access for extension installation, php.ini tuning, FPM pool debugging, or runtime diagnostics, the default variant is the right fit.

How does Echo achieve such a drastic CVE reduction in PHP?

Echo's PHP image is built from source with only the absolute essentials needed to run the PHP runtime workload, which significantly shrinks the attack surface. Echo also patches aggressively over time, with backports available so you can stay on the PHP minor version your application and its dependencies are certified against — avoiding a disruptive runtime upgrade forced purely by OS-level vulnerabilities in the base image rather than by your application's own requirements.

Will Echo's PHP image help us achieve FedRAMP?

Yes. The hard parts of FedRAMP — managing vulnerabilities, applying fixes, and using FIPS-validated cryptography — are baked into Echo images, including STIG-hardened configuration and ConMon/POA&M-ready reporting. For application teams running PHP workloads under an ATO — whether that's a Laravel API, a WordPress-based portal, or a custom PHP application handling government data — Echo's hardened PHP image keeps the web runtime layer in-boundary and compliant without requiring custom hardening scripts or manual base image patching between compliance cycles.