Ejecutar varias versiones de PHP en un servidor (5.6 a 8.4), por sitio

Cualquiera que aloje más de un sitio PHP acaba topándose con el muro de las versiones. Un sitio antiguo de cliente ejecuta un tema o plugin que se rompe con cualquier cosa posterior a PHP 7.4. La app que construyes hoy quiere 8.3 u 8.4 por sus propiedades tipadas y su rendimiento. Un tercer proyecto está atascado en código de la era 5.6 que nadie tiene presupuesto para modernizar. El instinto es levantar un servidor aparte por época — pero es un desperdicio e innecesario. Una sola máquina Linux puede ejecutar todas las versiones de PHP a la vez, cada sitio fijado exactamente a la que necesita. Así funciona, y cómo mantenerlo limpio.

Por qué importa el multi-PHP

• Legacy y moderno, lado a lado. No tienes que forzar un sitio antiguo a un PHP nuevo (y verlo dar pantalla en blanco) ni frenar una app nueva en uno viejo. Cada uno recibe su versión correcta.
• Actualizaciones seguras. Puedes pasar un sitio de 8.1 a 8.3 por su cuenta, probarlo y revertir — sin tocar los otros doce sitios de la máquina.
• Un servidor, muchas épocas. Sin pagar VPS extra solo para separar versiones de PHP. Alojar un sitio 5.6 junto a uno 8.4 no cuesta prácticamente nada.

El mecanismo que lo hace posible es PHP-FPM (FastCGI Process Manager), y entenderlo es toda la clave.

Cómo funciona ejecutar muchas versiones

Las distribuciones Linux modernas permiten instalar varias versiones de PHP en paralelo. En Ubuntu/Debian la vía común es el PPA ondrej/php, que empaqueta php5.6-fpm, php7.4-fpm, php8.1-fpm, … php8.4-fpm como servicios distintos que coexisten sin problemas.

Cada versión instalada ejecuta su propio máster FPM, y cada máster puede ejecutar varios pools. Un pool es un grupo de procesos worker aislado, con su propia configuración: bajo qué usuario corre, sus límites de recursos y — crucialmente — su propio socket de escucha. Así que el cuadro es:

php7.4-fpm  →  pool: siteA  →  /run/php/siteA.sock   (corre como usuario siteA)
php8.4-fpm  →  pool: siteB  →  /run/php/siteB.sock   (corre como usuario siteB)

Tu servidor web (Nginx) no ejecuta PHP él mismo — pasa las peticiones .php a un socket por FastCGI. Así que «¿qué versión de PHP usa este sitio?» se responde con una línea en la configuración de Nginx del sitio: a qué socket reenvía.

# Sitio A en PHP 7.4
location ~ \.php$ {
    fastcgi_pass unix:/run/php/siteA.sock;
    include fastcgi_params;
}

Apunta ese fastcgi_pass al socket del pool 7.4 y el sitio corre 7.4; apúntalo al socket del pool 8.4 y corre 8.4. Cambiar la versión de PHP de un sitio es en realidad solo reapuntar su socket y recargar Nginx. Todo lo demás — archivos, base de datos — queda intacto.

El aislamiento: la parte que la gente se salta

Ejecutar un pool por sitio no va solo de versiones; es también cómo mantienes separados a los inquilinos. Dos reglas hacen el trabajo pesado:

• Un usuario Linux por pool. Ejecuta el pool FPM de cada sitio bajo su propio usuario dedicado (no un www-data compartido). Así, un plugin comprometido en un sitio no puede leer los archivos ni las credenciales de base de datos de otro — los permisos del sistema lo impiden.
• open_basedir por pool. Define open_basedir en la configuración de cada pool para fijar su PHP a la raíz de ese sitio (más su directorio temporal). Incluso un script con fallos o malicioso no puede entonces leer físicamente fuera de su directorio.

Acierta con estos dos y «muchas versiones de PHP en una máquina» significa también «muchos sitios aislados de forma segura en una máquina». (Más sobre ese aislamiento por capas en alojar varios sitios de clientes en un solo VPS.)

Las trampas a vigilar

• El PHP en CLI es una versión distinta. El php que obtienes en la línea de comandos (para Composer, WP-CLI, cron) es el predeterminado del sistema — a menudo no la versión que usa el pool FPM de un sitio dado. Usa binarios específicos de versión (php7.4, php8.4) o define el predeterminado por sitio para que tus tareas cron no corran bajo la versión equivocada.
• Las extensiones son por versión. php-redis, php-imagick, php-gd y compañía deben instalarse para cada versión de PHP por separado (php8.4-redis, php7.4-redis). Un sitio que «perdió» una extensión tras un cambio de versión normalmente solo necesita el paquete de esa extensión para la nueva versión.
• Cada pool cuesta memoria. Cada pool mantiene procesos worker en RAM. Una docena de pools activos suma — dimensiona pm.max_children por pool y vigila la memoria, en vez de dejar que cada pool asuma que posee toda la máquina.
• Recarga, no lo olvides. Tras cambiar un pool o un socket, recarga el servicio FPM y Nginx. Una configuración renovada que no se recarga es una configuración que no está activa.

Hacerlo a mano es engorroso — hazlo de un clic

Nada de lo anterior es difícil por separado. Pero cablearlo bien para cada sitio — instalar la versión FPM correcta, crear un pool como usuario del sitio con el open_basedir y los límites correctos, generar un socket, reapuntar Nginx, recargar ambos servicios, mantener CLI y extensiones alineados — son muchos pasos engorrosos y propensos a error que repetir a mano cada vez que añades un sitio o cambias una versión.

Eso es justo lo que un panel debería absorber. ShadowPanel gestiona toda la pila multi-PHP por ti:

• PHP 5.6 a 8.4, instalados en paralelo y listos por sitio.
• Cambia la versión de un sitio desde un desplegable — el panel regenera el pool FPM aislado del sitio, reapunta el socket de Nginx y recarga ambos servicios. Sin SSH, sin editar configuración.
• Aislamiento aplicado por defecto — cada pool corre bajo el propio usuario Linux del sitio con open_basedir impuesto.
• Extensiones y configuración por sitio gestionadas desde el panel, para que un cambio de versión no deje caer en silencio lo que el sitio necesita.

Tú eliges la versión; el panel hace la fontanería — de forma segura, igual cada vez.

En resumen

No necesitas un servidor por época de PHP. Una máquina, PHP-FPM y un pool aislado por sitio te permiten ejecutar 5.6 junto a 8.4, cada sitio en exactamente la versión que necesita — y, bien hecho, cada sitio sellado de los demás. Los conceptos son simples; el cableado por sitio es tedioso y fácil de errar de forma sutil. ShadowPanel convierte «cambiar la versión de PHP de este sitio» en un desplegable, con el aislamiento integrado.

curl -fsSL https://shadowpanel.de/install.sh | bash

Ver precios y descargar →