Hosting para proyectos con varias versiones de PHP

Introducción

Si has llegado hasta aquí, es muy probable que ya hayas sentido esa molestia familiar: necesitas lanzar un proyecto que depende de una versión antigua de PHP, pero tu servidor actual ofrece una más reciente, o viceversa. Este es un problema mucho más común de lo que parece y afecta tanto a desarrolladores que gestionan múltiples sitios como a agencias que heredan el mantenimiento de proyectos legacy.

Trabajar con un hosting que permite gestionar varias versiones de PHP de forma flexible no es un lujo, sino una necesidad operativa. Cuando un servidor te limita a una única versión, te ves forzado a tomar decisiones incómodas: mantener un código obsoleto por compatibilidad, arriesgar la estabilidad de un proyecto antiguo al migrarlo forzosamente, o pagar por un VPS o un servidor dedicado para configurar manualmente el entorno. Sin embargo, gestionar un servidor privado virtual implica asumir tareas de administración del sistema que muchas veces nada tienen que ver con el desarrollo web: actualizar paquetes, configurar el gestor de procesos, endurecer la seguridad del sistema base... Una carga de trabajo considerable que distrae del objetivo principal: construir y mantener buenos sitios web.

La realidad es que cada aplicación tiene sus propios requisitos. Una plataforma de comercio electrónico lanzada hace cinco años puede depender de funciones específicas de PHP 7.4, mientras que un blog moderno o una aplicación SaaS recién desarrollada probablemente exija PHP 8.2 o 8.3 para aprovechar las mejoras de rendimiento y las nuevas características del lenguaje. Poder cambiar la versión de PHP desde el panel de control del hosting, de forma rápida y sin romper nada, es la solución ideal. Te permite replicar el entorno de producción local, probar actualizaciones de código en un entorno seguro y migrar proyectos de un servidor a otro con una facilidad sorprendente.

A lo largo de este artículo, exploraremos en detalle cómo funciona esta característica en el contexto del alojamiento web compartido y en soluciones más avanzadas. Analizaremos las diferencias en la gestión de estas versiones, cómo elegir la adecuada para tu proyecto, y qué características de seguridad y rendimiento debes buscar para no limitar el desarrollo. Porque, al final, la capacidad de elegir tu entorno de ejecución no es solo una cuestión técnica; es una flexibilidad que impacta directamente en tu productividad y en la sostenibilidad de tus proyectos a largo plazo. Prepárate para entender no solo el "cómo", sino también el "por qué" detrás de esta gestión de versiones.

Qué es

Qué es el hosting con soporte multi-versión de PHP

Cuando un proyecto web crece o se diversifica, es habitual que surja un problema técnico que muchos desarrolladores conocen bien: distintas aplicaciones, o incluso distintas ramas de un mismo proyecto, requieren versiones de PHP diferentes. Un sitio heredado puede depender de funciones de PHP 7.4 que fueron eliminadas en versiones posteriores, mientras que una aplicación nueva, construida con un framework moderno, exige PHP 8.3 para funcionar con todas sus optimizaciones. En este contexto nace el concepto de hosting multi-versión: la capacidad de un servidor para ejecutar distintas versiones de PHP de forma simultánea y aislada, según las necesidades de cada dominio, subdominio o incluso directorio.

Para entenderlo con precisión, conviene diferenciarlo del hosting tradicional. En un plan de alojamiento compartido estándar, el proveedor instala una única versión de PHP en el servidor. Todos los sitios alojados en esa cuenta utilizan, quieran o no, esa misma versión. Si el usuario necesita una más reciente para un proyecto, no le queda más remedio que cambiar la configuración global de su cuenta, lo que puede romper otros sitios que dependen de la versión anterior. El hosting multi-versión resuelve este conflicto de raíz: en lugar de elegir una única versión, el servidor mantiene varias instalaciones de PHP (por ejemplo, 7.4, 8.0, 8.1, 8.2 y 8.3) y permite asociar cada una a un dominio concreto mediante un archivo de configuración como `.htaccess` o a través del panel de control.

Esta característica no solo es útil para desarrolladores que gestionan múltiples clientes. También resulta esencial para proyectos que están en plena migración. Imaginemos una plataforma de comercio electrónico con miles de líneas de código. Pasar de PHP 7.4 a PHP 8.2 no es algo que se haga de un día para otro: hay que revisar librerías, probar la compatibilidad de plugins, analizar el rendimiento con las nuevas opciones de JIT (compilación en tiempo de ejecución) y corregir posibles errores de código obsoleto. Con un hosting multi-versión, el equipo puede levantar un entorno de staging con la nueva versión mientras el sitio de producción sigue operando con la antigua, sin necesidad de contratar un servidor adicional. Cuando la migración está completa, simplemente se cambia la versión asociada al dominio en producción.

Otro escenario frecuente es el de las agencias digitales que mantienen portfolios de sitios para clientes. Cada cliente puede tener requisitos de software distintos. Uno utiliza un WordPress antiguo con un plugin que no se actualiza desde hace años y que solo funciona correctamente en PHP 7.4. Otro ha encargado una aplicación Laravel que requiere PHP 8.2. En un hosting convencional, la agencia tendría que contratar dos planes separados o arriesgarse a que el sitio heredado falle tras una actualización forzada. Con la gestión multi-versión, ambos coexisten bajo la misma cuenta, con sus versiones de PHP aisladas, y el administrador controla desde un único panel qué versión corre en cada dominio.

Es importante señalar que la multi-versión no implica que todos los sitios compartan los mismos recursos de CPU o memoria. Cada proceso de PHP se ejecuta de manera independiente dentro del sistema, y el servidor gestiona los hilos y la asignación de recursos de forma dinámica. Lo que sí comparten es la infraestructura base del servidor web (Apache o Nginx) y el sistema operativo. Por eso, la funcionalidad no está exenta de límites: si se ejecutan varias versiones simultáneamente, cada una consume memoria propia. Un sitio con PHP 8.2 y otro con PHP 7.4 cargan, cada uno, su propia serie de módulos y extensiones. La ventaja es que la configuración, las extensiones y las directivas de ejecución se pueden personalizar para cada versión sin que afecten a las demás.

Frente a esta solución, existen alternativas que algunos desarrolladores consideran, como los contenedores Docker o una máquina virtual con varios entornos. Si bien ambas opciones ofrecen un control total, suponen una curva de aprendizaje mayor y una administración más compleja. El administrador debe gestionar redes, volúmenes de datos y orquestación, además del mantenimiento del propio sistema operativo. El hosting multi-versión, en cambio, lo ofrece el proveedor como una capa de gestión automatizada: el usuario elige la versión desde un menú desplegable y el servidor configura los archivos necesarios (por ejemplo, generando los `PHP-FPM` pools correspondientes) sin intervención manual en la configuración del sistema.

En resumen, el hosting multi-versión no es un lujo técnico ni un extra publicitario. Es una necesidad práctica para quienes trabajan con proyectos heterogéneos, con procesos de actualización gradual o con aplicaciones que dependen de versiones específicas del lenguaje. La herramienta convierte un problema de infraestructura (tener que elegir una única versión) en una tarea administrativa trivial: asociar cada dominio a la versión de PHP que necesita, y cambiarla cuando el proyecto evolucione. Para cualquier profesional que gestione más de un sitio, esta flexibilidad supone una ventaja real frente a los planes que limitan a una única versión del intérprete.

Aspectos importantes a evaluar

Compatibilidad nativa con múltiples versiones de PHP

El primer aspecto que debes evaluar, y quizás el más crítico, es cómo gestiona el proveedor el cambio entre versiones de PHP. No todos los paneles de control o infraestructuras manejan esto de la misma manera, y la diferencia entre una solución robusta y una improvisada se nota en el día a día.

Paneles de control y su gestión de versiones

La forma más común de gestionar múltiples versiones de PHP es a través del panel de control del hosting. Proveedores como cPanel, Plesk o DirectAdmin ofrecen la posibilidad de seleccionar la versión de PHP para cada dominio o subdominio de forma individual. Esto se hace generalmente a través de un selector de versiones que permite alternar entre PHP 7.4, 8.0, 8.1, 8.2, etc., con solo unos clics. La ventaja de este enfoque es que el cambio es inmediato y no requiere intervención técnica compleja. Tú solo eliges la versión en la interfaz y el servidor la aplica al instante.

Sin embargo, es importante verificar qué versiones específicas están disponibles. Algunos proveedores económicos ofrecen un rango limitado o se quedan atrás en las actualizaciones. Si necesitas PHP 8.3 o una versión anterior como PHP 7.4 (común para proyectos legacy con frameworks antiguos), asegúrate de que el servicio las tenga disponibles de forma nativa, sin tener que solicitar una instalación personalizada a soporte.

Entornos de desarrollo vs. producción

Un error común es asumir que el hosting solo sirve para producción. Si desarrollas o mantienes varios proyectos, la capacidad de crear entornos de staging con diferentes versiones de PHP en el mismo plan es un diferenciador enorme. Imagina que tienes un proyecto en PHP 7.4 en producción y necesitas actualizarlo a PHP 8.2. Lo ideal es tener un subdominio de prueba (por ejemplo, `dev.misitio.com`) corriendo con PHP 8.2 y el dominio principal con 7.4. Si tu hosting permite asignar versiones distintas por dominio, puedes probar la compatibilidad del código sin afectar el sitio en vivo. Si no lo permite, tendrías que hacerlo en tu máquina local o contratar un segundo plan, lo cual es poco práctico.

El problema con las soluciones "todo en uno"

Algunos hostings, especialmente los orientados a WordPress, promocionan un "PHP Manager" simplificado que solo permite alternar entre dos o tres versiones recientes. Aunque esto cubre la necesidad básica, suele ser insuficiente para proyectos con dependencias específicas. Por ejemplo, si mantienes una aplicación en CakePHP 3 que requiere PHP 7.2, no te valdrá con un selector que solo ofrezca 8.0 en adelante. La flexibilidad aquí es clave: necesitas un histórico amplio de versiones disponibles y la posibilidad de ejecutar varias de ellas de forma simultánea.

Gestión de recursos y rendimiento por proyecto

No basta con cambiar la versión; también debes evaluar cómo el servidor asigna los recursos cuando hay múltiples versiones de PHP en juego. Cada versión corre como un servicio (a menudo un proceso FPM específico) y consume recursos de memoria y CPU.

Cuotas de entrada y límites

Presta atención a los límites de memoria, ejecución y entrada. Un proyecto en PHP 8.0 puede tener un consumo de memoria ligeramente distinto al de uno en PHP 7.4. Si el hosting tiene límites estrictos (por ejemplo, 256 MB de RAM por proceso de PHP), un cambio de versión podría provocar un error de memoria inesperado. Lo ideal es que el proveedor ofrezca límites claros de entrada y que puedas ajustar el `memory_limit` y el `max_execution_time` desde el panel para cada dominio, incluso aunque compartan la misma infraestructura.

Aislamiento entre dominios

Si alojas varios proyectos en el mismo plan, asegúrate de que un pico de tráfico en el proyecto que usa PHP 7.4 no derrumbe el que usa PHP 8.2. Muchos hostings utilizan contenedores o cuentas independientes con el panel de control, pero comparten el mismo servidor físico. La diferencia está en si el proveedor utiliza límites de entrada por usuario del sistema operativo (lo cual aísla el consumo) o si permite que un proceso se coma toda la CPU. Puedes comprobar esto solicitando un "Uso de recursos" detallado en el panel. Las soluciones basadas en CloudLinux (comunes en la mayoría de hostings compartidos) ofrecen una buena contención de recursos por cuenta, lo cual es ideal cuando integras varias versiones de PHP.

Soporte técnico con conocimiento real

La gestión de múltiples versiones de PHP es un área donde el soporte técnico puede marcar una gran diferencia entre una tarea de 5 minutos y un quebradero de cabeza de varios días. Un buen equipo de soporte debe saber responder preguntas como:

• *"¿Cómo puedo asignar una variable de entorno específica para PHP 8.0 en este subdominio?"*
• *"¿Las extensiones de PHP están habilitadas a nivel global o puedo activarlas solo para una versión concreta?"*
• *"¿Qué configuración de OPcache es la recomendada para PHP 8.1 en un sitio con alto tráfico?"*

Un truco útil es contactar con el soporte del hosting antes de contratar, preguntándoles por una configuración específica y detallada para tu caso. Por ejemplo: *"Estoy migrando una aplicación que requiere PHP 7.4 y extensiones abiertas como `curl` y `mbstring`. ¿Puedo tener PHP 7.4 y PHP 8.2 en el mismo plan sin que interfieran entre sí? ¿Cómo gestionaríais los archivos de configuración específicos para cada versión?"*. Si el soporte tarda mucho o responde con respuestas genéricas y automáticas, es una señal de alerta. Un buen soporte te explicará el proceso paso a paso e incluso te indicará cómo configurar la directiva `date.timezone` para una versión específica, algo que requiere manejo de archivos como `.htaccess` o `php.ini` personalizado.

El valor del soporte de "desarrollo"

Los proveedores que tienen un plan de soporte orientado a desarrolladores (con chat en vivo 24/7 y acceso a técnicos de sistemas) son mucho más valiosos que aquellos que solo ofrecen tickets con respuestas de 24 horas. Cuando gestionas versiones distintas, el riesgo de encontrar un conflicto de configuración es real. Tener un experto al otro lado que sepa debuggear un error de `PDO_MYSQL` con PHP 8.1 es un activo intangible que no tiene precio.

Facilidad de migración y coexistencia

El último criterio práctico, y que a menudo se ignora, es la facilidad con la que puedes migrar un proyecto de una versión a otra sin tiempo de inactividad. No se trata solo de cambiar el número de versión, sino de verificar que todas las funcionalidades siguen operativas.

Estrategia de cambio progresivo

Un buen hosting debe permitirte ejecutar una configuración híbrida durante un periodo de transición. Por ejemplo, podrías tener el dominio `www.miproyecto.com` apuntando a PHP 8.2 para los nuevos visitantes, pero mantener un subdominio interno con PHP 7.4 para procesos de cron o APIs heredadas. Esto se logra mediante la asignación de versiones por directorio o por dominio, algo que ya hemos comentado. Si el hosting no te permite esta flexibilidad, la migración se convierte en un proceso de "todo o nada", arriesgado para aplicaciones críticas.

Herramientas de diagnóstico integradas

Verifica si el panel de control incluye herramientas para comprobar la compatibilidad del código, como un "Comprobador de compatibilidad de PHP" o la capacidad de ver los logs de error de cada versión por separado. Poder acceder a logs específicos de PHP 8.1 y PHP 7.4 en paralelo facilita enormemente la depuración durante una migración. Además, muchas soluciones de hosting incluyen un administrador de configuración que te permite habilitar o deshabilitar extensiones específicas para cada versión sin reiniciar el servidor, algo esencial si usas módulos como `imagick` o `ionCube` que deben estar activos en una versión concreta.

Cómo funciona o cómo tomar una decisión

La gestión de múltiples versiones de PHP en un entorno de hosting ha pasado de ser una rareza técnica a convertirse en una necesidad operativa. Comprender el proceso práctico para elegir y configurar tu alojamiento es la diferencia entre un proyecto que se actualiza con fluidez y una jaula de dependencias que te mantiene anclado a tecnologías obsoletas. Este proceso no se limita a marcar una casilla en un panel de control; implica un flujo de trabajo que abarca desde la evaluación del proveedor hasta la prueba final de tu aplicación.

El punto de partida: evaluar la arquitectura del hosting

Antes de contratar, debes entender cómo gestiona el proveedor las versiones de PHP. No todos los hosts lo hacen igual, y esta diferencia define tu flujo de trabajo diario. Puedes agruparlos en tres modelos operativos:

1. Entornos compartidos con selector de versión: Este es el modelo más común en hosting compartido de gama media y alta (como SiteGround, Hostinger o Kinsta en el ámbito gestionado). El panel de control (cPanel, Plesk o un panel propietario) incluye una herramienta que te permite cambiar la versión de PHP por dominio o subdominio. El proceso es inmediato: seleccionas la versión en un menú desplegable, el sistema ajusta el intérprete (FPM, CGI, etc.) y la configuración se aplica en segundos. Aquí, la flexibilidad es alta, pero la responsabilidad de probar la compatibilidad recae enteramente en ti.

1. Hosting gestionado (Managed WordPress o VPS con panel): Proveedores como WP Engine o Cloudways se centran en optimizar el rendimiento. En este modelo, la selección de la versión suele estar ligada a la pila de software del servidor. Puedes elegir entre PHP 8.0, 8.1 u 8.2, pero las opciones de personalización avanzada (como cambiar la configuración de `opcache` o los límites de memoria) suelen ser más limitadas o preconfiguradas. La gestión es más sencilla, pero el control a nivel de servidor es menor. Si tu proyecto requiere módulos PHP menos comunes (como `imap` o `ldap`), esta opción puede ser un obstáculo.

1. Infraestructura Cloud (VPS a medida): Con servicios como DigitalOcean, AWS o Google Cloud, tienes control absoluto. Aquí, el "proceso" de gestión de versiones implica usar herramientas como Docker, Nginx con PHP-FPM o Laravel Valet. En lugar de un panel, utilizas configuraciones declarativas. La ventaja es la precisión: puedes ejecutar dos versiones de PHP simultáneamente en el mismo servidor, asignando una a cada dominio virtual. La desventaja es la complejidad; cada actualización requiere una intervención manual y un mayor conocimiento de la infraestructura.

Ejemplo práctico de arranque en VPS

• Instalar `php7.4-fpm` y `php8.3-fpm` como servicios independientes.
• Crear dos pools de FPM que escuchen en sockets Unix diferentes.
• Configurar Nginx para que el bloque de servidor (`server block`) de tu API use `fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;` y el bloque de la app antigua use el socket de PHP 7.4.
• Reiniciar Nginx. El resultado es un servidor que sirve ambas versiones sin conflicto.

El flujo de migración: cómo alternar entre versiones sin romper tu sitio

Una vez que tienes el acceso al panel, el proceso de decisión sobre cuándo y cómo moverte es un ritual de seguridad. No se trata de pulsar el botón de actualización y esperar que funcione. El flujo correcto es:

1. Análisis de entorno actual y compatibilidad estática

• Inspecciona tu pila: No solo el código principal, sino las dependencias. Si usas un framework (Laravel, Symfony, WordPress con plugins), verifica la matriz de compatibilidad en sus documentaciones oficiales. Laravel 9, por ejemplo, requiere PHP 8.0 para ejecutarse, pero para aprovechar sus funciones modernas es recomendable PHP 8.1.
• Detecta código deprecado: Utiliza herramientas de análisis estático como PHPStan o Rector. PHPStan te mostrará dónde tu código usa funciones eliminadas (por ejemplo, `each()` o `create_function()`). Rector puede incluso convertir tu código automáticamente para que sea compatible con la versión más nueva. Este paso reduce drásticamente los errores fatales en producción.

• Clona tu sitio a `staging.tudominio.com`.
• En el panel de control, asigna la nueva versión de PHP exclusivamente a este subdominio. Así, tu dominio de producción (`www.tudominio.com`) sigue en la versión estable mientras pruebas en el nuevo entorno.
• Ejecuta una batería de pruebas funcionales: formularios, carritos de compra, procesos cron, y el envío de correos.

• Programa la ventana de cambio: Prefiere horarios de bajo tráfico, aunque el cambio sea de segundos.
• Cambia la versión en el dominio de producción.
• Revisa los logs de error en tiempo real. El panel de control (o el `error_log` de tu servidor) te dirá si hay avisos de `E_DEPRECATED` o `E_WARNING`. Aunque no rompan el sitio, indican una futura incompatibilidad.
• Prueba los flujos críticos inmediatamente: Inicia sesión, realiza una compra de prueba (si aplica) y verifica el panel de administración.

El factor de los repositorios y el control de versiones

Un proceso robusto no depende solo del panel del hosting, sino de cómo versionas tu código. Antes de migrar, es imprescindible tener el código bajo control de versiones (Git). No deberías depender de la copia de archivos por FTP para hacer una prueba de versión.

El flujo ideal es:

1. Ten el código en un repositorio.
2. Conecta tu entorno de staging al repositorio (despliegue continuo).
3. Cambia la versión PHP en el servidor de pruebas.
4. Ejecuta las pruebas.
5. Si pasa, despliega a producción y cambia la versión.

Toma de decisiones: el criterio de la "versión mínima segura"

No se trata de usar siempre la última versión de PHP por moda. La decisión debe basarse en un criterio pragmático: seguridad y soporte activo. Cada rama de PHP tiene un ciclo de vida soportado de dos años (soporte activo y de seguridad). PHP 8.0 quedó fuera del soporte de seguridad a finales de 2023. Si tu host te ofrece PHP 8.0 pero tu código es compatible con 8.1, no hay motivo racional para quedarse en 8.0.

Al evaluar tu código, hazte esta pregunta: ¿mi aplicación requiere funcionalidades obsoletas que solo existen en versiones antiguas?

• Si la respuesta es sí, es una deuda técnica crítica. El proceso correcto no es mantener el hosting en versiones antiguas (lo cual es inseguro), sino planificar la actualización del código.
• Si la respuesta es no (el caso más común), entonces elige la versión más reciente y estable que ofrezca tu proveedor, siempre que tu stack (base de datos, certificados SSL, librerías externas) lo soporte.

El proceso de gestión de versiones PHP es cíclico. Cada vez que una nueva versión principal salga al mercado, debes repetir este flujo de evaluación, prueba y despliegue. Un hosting que simplifique ese ciclo con herramientas claras (cambios de versión instantáneos y entornos de staging) te permitirá mantenerte al día sin convertir cada actualización en una cirugía a corazón abierto.

Ventajas y limitaciones

Ventajas de un hosting multi-versión de PHP

La principal razón para elegir un hosting que ofrezca múltiples versiones de PHP es, sin duda, la flexibilidad. Pero esta flexibilidad se traduce en beneficios muy concretos que impactan directamente en la estabilidad, la seguridad y el coste de tus proyectos. Vamos a desglosarlos.

1. Gestión de proyectos legados y modernos desde un mismo panel

Imagina que eres una agencia o un desarrollador freelance. Probablemente gestionas decenas de sitios web. Algunos son tiendas WooCommerce que necesitan PHP 7.4 por compatibilidad con ciertos plugins antiguos, mientras que otros son aplicaciones Laravel o Symfony que exigen PHP 8.2 para funcionar con el último framework.

Un hosting con gestión de versiones por directorio te permite tener ambos sitios activos bajo un mismo panel (cPanel, Plesk, etc.) sin conflictos. No necesitas contratar dos planes de hosting diferentes ni mantener una máquina virtual solo para el cliente con el código heredado. Esto simplifica la administración, centraliza las facturas y reduce la carga operativa. Es la diferencia entre tener que migrar (y romper) un proyecto antiguo por obligación, o poder mantenerlo estable mientras planificas una actualización con calma.

2. Entornos de prueba instantáneos (Staging)

La capacidad de cambiar de versión de PHP con un clic no es solo para producción; es una herramienta de desarrollo potentísima. Supongamos que necesitas actualizar un plugin de WordPress. Puedes crear un subdominio como `test.tudominio.com`, ponerle PHP 8.1 y probar el plugin ahí. Si todo funciona, cambias el PHP del sitio principal. Si falla, dejas el subdominio con esa versión y el sitio principal sigue en su versión estable.

Este flujo de trabajo te permite validar la compatibilidad de tu código con nuevas versiones de PHP antes de dar el salto definitivo. En muchos entornos de hosting, este proceso implicaba crear una copia del sitio y esperar a que el soporte técnico reconfigurara el servidor, un proceso que podía llevar horas. Con el selector de versiones, el proceso se reduce a minutos.

3. Mitigación de vulnerabilidades en software obsoleto

Es un hecho: las versiones antiguas de PHP (como 5.6 o 7.0) ya no reciben parches de seguridad. Tener un sitio en el servidor con PHP 7.0 es un riesgo para ti y para los demás usuarios del mismo servidor.

La ventaja de un hosting con varias versiones es que te da un "plan de escape". Si tienes un proyecto crítico que aún depende de una librería incompatible con PHP 8.x, puedes usar una versión intermedia (como 7.4, que aún tiene soporte de seguridad en algunas distribuciones) como puente. No es una solución eterna, pero te da un margen de tiempo real para reescribir el código sin dejar el sitio expuesto a vulnerabilidades conocidas. Además, puedes ir subiendo la versión de forma incremental: de 7.4 a 8.0, luego a 8.1, y así sucesivamente, en lugar de hacer un salto mortal directo que probablemente romperá algo.

Limitaciones que debes considerar

Aunque la flexibilidad es enorme, no es una solución mágica. Es importante ser consciente de las limitaciones para no llevarse sorpresas.

##### 1. Rendimiento heterogéneo

No todas las versiones de PHP rinden igual. PHP 8.0 y superiores incluyen el compilador JIT (Just-In-Time) que puede acelerar operaciones intensivas de CPU hasta un 30% en ciertos escenarios. Si tienes dos sitios en el mismo plan, uno con PHP 7.4 y otro con PHP 8.3, el segundo tendrá un rendimiento notablemente superior. El hosting sigue siendo el mismo, pero la velocidad de ejecución del código varía.

Esto implica que tu prueba de rendimiento debe considerar la versión específica que usa cada proyecto. No puedes asumir que un resultado de carga en un subdominio se replicará en otro si usan versiones distintas. Para aplicaciones críticas que procesan datos en tiempo real (como APIs o paneles de analítica), la versión de PHP es tan importante como el plan de hosting.

##### 2. Selector por directorio, no por servidor

Una confusión común es pensar que el selector de versiones cambia todo el entorno. En la mayoría de los casos, solo cambia la versión del intérprete (la línea de comandos y los módulos de Apache/Nginx). Las extensiones de PHP (como `curl`, `mysqli`, `gd`) suelen estar compiladas para cada versión, pero la configuración del servidor web (Apache o Nginx) es compartida.

Esto significa que si un sitio necesita un módulo específico de Apache (como `mod_rewrite` con reglas personalizadas), deberá estar habilitado para todo el servidor. No puedes activar un módulo para un directorio y no para otro. La ventaja es clara a nivel de intérprete, pero la personalización del servidor sigue siendo compartida.

##### 3. Módulos y extensiones desactualizadas

Hay una diferencia crucial entre tener PHP 8.3 disponible y tener PHP 8.3 con todas las extensiones que necesitas. Un desarrollador que trabaja con bases de datos específicas (como PostgreSQL o Redis) o con extensiones poco comunes (como `intl` o `imagick`) debe verificar que el hosting tenga compiladas esas extensiones para la versión elegida.

Si tu proyecto depende de una extensión que no está disponible en la versión nueva, la flexibilidad desaparece. Es una limitación del proveedor, no de la versión PHP. Antes de decidirte por un plan, revisa en su documentación la lista de extensiones habilitadas para cada versión de PHP.

Errores comunes

Uno de los fallos más habituales al gestionar un servidor con múltiples versiones de PHP es asumir que un único ajuste en el archivo de configuración soluciona todos los proyectos. La realidad es que cada aplicación web tiene dependencias específicas con la versión del intérprete, y lo que funciona para un WordPress antiguo puede romper por completo una aplicación Laravel moderna. Este malentendido provoca errores de compatibilidad difíciles de rastrear, como funciones obsoletas que lanzan excepciones fatales o extensiones que no están habilitadas para el binario correcto.

Confundir la versión CLI con la versión del servidor web Uno de los errores más comunes y frustrantes ocurre cuando un desarrollador ejecuta `php -v` en la terminal, ve una versión concreta (por ejemplo, PHP 8.2) y asume que es la que está utilizando el sitio web. Sin embargo, cuando se usa PHP-FPM (FastCGI Process Manager), la versión ejecutada por la terminal es independiente de la que procesa las peticiones HTTP. El servidor web, ya sea Nginx o Apache, utiliza un socket o puerto específico gestionado por el demonio de FPM correspondiente a esa versión. Podrías tener PHP 8.2 en la CLI y PHP 7.4 en el pool de FPM activo sin que te des cuenta. Para verificarlo correctamente, debes crear un archivo `phpinfo.php` en el directorio raíz del proyecto y acceder a él desde un navegador. Si la página muestra la versión esperada, el problema no está en el binario, sino en la configuración del pool o en la directiva `listen` de tu servidor web.

Ignorar la gestión de extensiones por cada versión Cada versión de PHP requiere sus propias extensiones compiladas y módulos. Es habitual encontrar sistemas donde se instala `php8.1-mysql` y luego se espera que funcione en el pool de PHP 8.0. Las extensiones no son transversales entre versiones; cada binario necesita su propio conjunto de librerías. Un error típico es activar `opcache` o `redis` únicamente en la configuración de una versión y luego preguntarse por qué la otra arroja errores de "class not found" o "undefined function". Antes de implementar una nueva versión, verifica qué extensiones requiere cada proyecto para esa versión concreta y utiliza los comandos de instalación específicos del sistema operativo para habilitarlas. En Ubuntu, por ejemplo, el paquete se llamará `php8.0-xml`, no `php-xml` genérico.

Actualizar el binario por defecto del sistema Otra decisión arriesgada es modificar el `update-alternatives` del sistema para cambiar la versión global de PHP. Esto puede parecer una solución rápida para un proyecto concreto, pero rompe la configuración de otros sitios que dependen de la versión anterior. Si un proyecto requiere PHP 7.4 y otro necesita PHP 8.3, fijar el global a 8.3 provocará que el proyecto antiguo genere errores de sintaxis o de incompatibilidad con funciones eliminadas como `each()` o `create_function()`. La solución robusta es crear pools específicos de FPM para cada versión y enlazar el dominio o la ruta en el servidor web al socket correspondiente. Nunca alteres la versión del intérprete a nivel de sistema operativo si gestionas más de una aplicación con requisitos dispares.

Olvidar la herencia de configuración en el servidor web Cuando trabajamos con Nginx, es frecuente usar bloques `location` o directivas `fastcgi_pass` para redirigir a un socket específico. Un error recurrente es heredar una configuración global que apunta al socket de una versión determinada y luego crear un `include` dentro de un `server` block que anula la variable `fastcgi_pass`. Esto genera conflictos de "host not found" o "connection refused" si omites el puerto o el socket correcto en la configuración del archivo `.conf` del sitio. Es crucial revisar el archivo de configuración del virtual host y asegurarse de que el parámetro `fastcgi_pass` apunte al socket Unix correcto, como `unix:/run/php/php7.4-fpm.sock`, y que no exista una anulación en cascada desde la sección `http` del archivo principal.

Descuidar la sincronización de las variables de entorno Las aplicaciones modernas suelen depender de variables de entorno almacenadas en archivos como `.env`. Cuando cambias la versión de PHP para un proyecto, especialmente en entornos con PHP-FPM, las variables de entorno gestionadas por el pool pueden perderse o no heredarse correctamente. Si defines `clear_env = yes` en un pool (por defecto para evitar fugas de variables del sistema), el proceso de FPM no las expone a la aplicación. De repente, la aplicación pierde acceso a credenciales de base de datos o claves de API, generando errores de conexión que parecen ser problemas de PHP cuando en realidad son de configuración del entorno. Si experimentas caídas inesperadas tras un cambio de versión, revisa la directiva `env` dentro del archivo de configuración del pool.

No probar la compatibilidad real antes del cambio Un enfoque demasiado confiado consiste en cambiar la versión de PHP del dominio solo por cambiar el socket y esperar que todo funcione. Las aplicaciones con código legacy muestran incompatibilidades sutiles, por ejemplo, con el manejo de `NULL`, tipos estrictos en funciones internas o el comportamiento de ciertas funciones de cadenas. Antes de migrar, ejecuta un escaneo con herramientas como `php -l` (lint) sobre cada archivo en modo CLI, pero usando la versión de destino. Además, activa los `E_DEPRECATED` y `E_NOTICE` en un entorno de prueba para detectar advertencias que, en producción, pasarían desapercibidas hasta provocar un fallo grave. Realiza siempre una prueba de humo HTTP con `curl` contra la nueva configuración antes de hacer el cambio definitivo.

La clave reside en tratar cada versión de PHP como un "entorno" aislado e independiente, con sus propias configuraciones, extensiones y sockets. Si adoptas una mentalidad de granularidad, evitarás el caos de intentar homogeneizar lo que por naturaleza debe ser heterogéneo.

Preguntas frecuentes

¿Puedo tener diferentes versiones de PHP en el mismo hosting?

Sí, es posible, pero la forma de hacerlo depende completamente de la infraestructura del proveedor. En un hosting compartido tradicional, el servidor suele ofrecer un selector de versión de PHP a nivel de panel de control (cPanel, Plesk o similar). Esto te permite cambiar la versión global de tu dominio o de subdominios específicos con solo unos clics. Sin embargo, esta flexibilidad tiene un límite: normalmente solo puedes elegir entre las versiones que el proveedor ha preinstalado (por ejemplo, 7.4, 8.1 y 8.2). No puedes ejecutar una versión personalizada o muy antigua si no está en esa lista.

Para proyectos que requieren más granularidad, como gestionar dos aplicaciones en el mismo servidor con versiones de PHP distintas (una tienda WooCommerce en PHP 8.1 y un CMS legacy en 7.4), necesitas un entorno más avanzado. Las soluciones típicas son:

1. Hosting con contenedores (Docker): Cada proyecto se ejecuta en su propio contenedor con su propia pila de software. Esto es ideal para desarrollo y para producción si el proveedor lo permite, ya que aíslas completamente las dependencias. El inconveniente es que requiere ciertos conocimientos de administración de sistemas.
2. Servidores VPS o Cloud: Tienes control total del sistema operativo. Puedes instalar múltiples versiones de PHP (por ejemplo, usando `phpbrew` o el gestor de versiones de tu distribución Linux) y configurar tu servidor web (Apache o Nginx) para que cada dominio ejecute una versión específica. Esto es la opción más potente y flexible, pero asumes toda la responsabilidad de mantener el sistema actualizado y seguro.
3. Hosting con Multi-PHP por directorio: Algunos paneles de control avanzados (como Plesk o DirectAdmin) permiten asignar una versión de PHP específica a un subdominio o incluso a una carpeta concreta del sitio. Esto es muy práctico si tienes un solo plan de hosting pero quieres migrar una aplicación gradualmente sin afectar a la otra.

¿Cómo afecta el PHP elegido al rendimiento de mi sitio?

La versión de PHP tiene un impacto directo en la velocidad y el consumo de recursos, pero no es el único factor. Las versiones más recientes (PHP 8.0 y superiores) incluyen el compilador JIT (Just In Time) y mejoras significativas en la gestión de memoria y tipos de datos. Esto se traduce en una ejecución de código notablemente más rápida para aplicaciones modernas. Un sitio que corre en PHP 8.3 puede ser hasta un 30% o 40% más rápido sin cambiar una sola línea de código, simplemente porque el motor del lenguaje es más eficiente.

Sin embargo, el rendimiento real depende de cómo esté escrito el código. Una plataforma mal optimizada que haga consultas SQL lentas no se arreglará mágicamente con cambiar a la última versión de PHP. El rendimiento percibido también depende del servidor web (Nginx suele gestionar mejor el tráfico estático que Apache), del sistema de caché de páginas y de la configuración de la base de datos. Por lo tanto, actualizar a una versión superior de PHP es una mejora muy rentable, pero debe ir acompañada de una revisión del código de la aplicación para obtener todos los beneficios.

Lo que sí debes vigilar es la compatibilidad. Una versión desactualizada (como PHP 5.6) es un riesgo de seguridad enorme y a menudo el origen de ralentizaciones porque el desarrollador ha tenido que aplicar parches manuales que rompen el rendimiento. Al elegir hosting, prioriza proveedores que ofrezcan soporte para PHP 8.3 o 8.4, ya que te garantiza un rendimiento base sólido y parches de seguridad activos.

¿Qué riesgos tengo si uso una versión antigua de PHP para una aplicación legacy?

Usar una versión obsoleta de PHP es uno de los mayores riesgos de seguridad que puedes asumir en un proyecto web. Una vez que el equipo de desarrollo de PHP deja de dar soporte para una versión (final de vida o EOL), ya no se publican parches de seguridad. Las vulnerabilidades descubiertas tras esa fecha quedarán expuestas permanentemente. Para sistemas como WordPress, esto es crítico, porque los plugins y temas suelen explotar estas brechas.

Los riesgos prácticos son:

• Inyección de código y deserialización: Las versiones antiguas tienen fallos conocidos en funciones como `unserialize()` que permiten a un atacante ejecutar código remoto en el servidor.
• Problemas de compatibilidad: No podrás usar librerías modernas ni APIs seguras. Por ejemplo, funciones de cifrado como `password_hash()` están mejor soportadas y optimizadas en PHP 8.x.
• Dificultad de contratación: Encontrar un desarrollador que quiera o sepa trabajar con PHP 5.6 es difícil y caro.

¿Puedo migrar un proyecto a una versión de PHP superior sin miedo a romperlo?

No es cuestión de miedo, sino de método. Migrar de PHP 7.4 a 8.2 suele implicar romper algunos fragmentos de código, especialmente si usas extensiones antiguas o funciones deprecadas (como `create_function()` o `each()`). El error más común es el "Cambio en la interpretación de tipos débiles", que puede lanzar excepciones inesperadas en operaciones con variables mixtas. El proceso correcto es:

1. Auditoría de código: Ejecuta herramientas de análisis estático como *PHPStan* o *Rector* que te señalarán automáticamente los fragmentos incompatibles.
2. Entorno de pruebas: En tu alojamiento, crea un subdominio o un directorio oculto que use la nueva versión de PHP. Copia tu aplicación y ejecuta toda la suite de pruebas automatizadas. Si no tienes pruebas, haz pruebas manuales intensivas del flujo de compra, registro y administración.
3. Revisa extensiones: Asegúrate de que las extensiones de PHP necesarias (como `mysqli`, `curl` o `gd`) están habilitadas en la nueva versión. A veces no están instaladas por defecto y la web muestra pantallas en blanco.
4. Migración en caliente: Si tu panel de control lo permite, cambia la versión de PHP en horario de baja afluencia. Observa los logs de error durante las primeras 24 horas. La mayoría de los errores fatales aparecerán en minutos, así que usa un cron de vigilancia.

Conclusión

Elegir un hosting que permita gestionar varias versiones de PHP no es un lujo técnico, sino una necesidad operativa para cualquier equipo que mantenga proyectos heredados o múltiples aplicaciones con requisitos distintos. En lugar de buscar la plataforma con más funciones llamativas, prioriza la flexibilidad del panel de control y la facilidad para alternar entre versiones sin fricciones.

En la práctica, esto significa que tu flujo de trabajo debe permitirte asignar PHP 7.4 a un proyecto antiguo y PHP 8.3 a uno nuevo en cuestión de segundos, sin necesidad de contactar al soporte o editar archivos de configuración manualmente. Plataformas como cPanel, Plesk o los paneles customizados de proveedores como SiteGround, Hostinger o Kinsta (en el ámbito gestionado) ya integran esta funcionalidad de forma nativa.

Antes de contratar, verifica dos aspectos clave: la cantidad de versiones disponibles simultáneamente y la política de actualización del proveedor. Algunos hosts mantienen versiones antiguas durante años por compatibilidad, mientras que otros fuerzan migraciones tempranas. Para entornos de producción estables, busca un equilibrio entre soporte a largo plazo y opciones modernas.

Si tu proyecto crecerá en complejidad, considera también qué tan fácil es clonar entornos o mover dominios entre servidores. Un hosting que simplifica la gestión de versiones te ahorrará dolores de cabeza futuros y te permitirá enfocarte en el desarrollo, no en la administración del servidor. La decisión correcta es aquella que se adapta a tu flujo actual y te da margen para evolucionar sin cambiar de proveedor.