The problem is familiar to anyone maintaining old client sites: the code needs PHP 5.6 or 7.x, the distribution stopped packaging it years ago, and compiling it against a modern OpenSSL is an afternoon you will never get back.
Containers solve this cleanly because the old PHP brings its own userland. The image is built on a base old enough to have the libraries that version expects, while the kernel underneath is current and patched.
The shape of the solution
A container per legacy version, each running PHP-FPM and listening on a socket or port that your web server treats exactly like a native pool. The vhost does not care whether the FastCGI endpoint is a local PHP-FPM pool or a container — it is the same protocol.
The three details that make or break it
Path consistency. The document root path inside the container must match the path the web server sends in
User and group. The FPM process inside the container needs the same numeric UID as the file owner on the host. Containers do not care about usernames, only numbers, and a UID mismatch produces permission errors that make no sense when you look at the ownership on the host side.
Database sockets. Legacy code frequently connects to MySQL over a Unix socket at a hardcoded path. Inside a container that path does not exist. Either mount the socket in, or change the connection to TCP — and mounting is usually less invasive because it does not require touching the client's code.
Security reality check
Old PHP is old PHP. The container does not patch it; it isolates it. Treat these sites as untrusted: no shared filesystem with modern sites, a memory limit, and ideally a network they cannot use to reach your other stacks. The container is a blast radius control, not a fix.
Anyone still running 5.6 in production — what is the application, and is there a migration path, or is it one of those?
Containers solve this cleanly because the old PHP brings its own userland. The image is built on a base old enough to have the libraries that version expects, while the kernel underneath is current and patched.
The shape of the solution
A container per legacy version, each running PHP-FPM and listening on a socket or port that your web server treats exactly like a native pool. The vhost does not care whether the FastCGI endpoint is a local PHP-FPM pool or a container — it is the same protocol.
Code:
location ~ \.php$ {
include fastcgi_params;
fastcgi_pass 127.0.0.1:9056; # PHP 5.6 container
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}The three details that make or break it
Path consistency. The document root path inside the container must match the path the web server sends in
SCRIPT_FILENAME. Mount the site at the same path it has on the host, or every request 404s from FPM while the file plainly exists.User and group. The FPM process inside the container needs the same numeric UID as the file owner on the host. Containers do not care about usernames, only numbers, and a UID mismatch produces permission errors that make no sense when you look at the ownership on the host side.
Database sockets. Legacy code frequently connects to MySQL over a Unix socket at a hardcoded path. Inside a container that path does not exist. Either mount the socket in, or change the connection to TCP — and mounting is usually less invasive because it does not require touching the client's code.
Security reality check
Old PHP is old PHP. The container does not patch it; it isolates it. Treat these sites as untrusted: no shared filesystem with modern sites, a memory limit, and ideally a network they cannot use to reach your other stacks. The container is a blast radius control, not a fix.
Anyone still running 5.6 in production — what is the application, and is there a migration path, or is it one of those?