El criterio real: quién aplica los parches
La pregunta « ¿cuál es más potente? » lleva casi siempre al VPS. La pregunta útil para una agencia es otra: cuando una vulnerabilidad crítica sale un martes por la noche, ¿quién aplica el parche en el servidor de ese cliente? En un hosting compartido con cPanel, lo hace el proveedor. El kernel, el intérprete de PHP, el cortafuegos del servidor y la supervisión de la máquina no corren por su cuenta, y usted conserva la relación con el cliente. En un VPS, todo eso pasa a ser su ámbito desde el primer minuto, fines de semana incluidos. No es un defecto del VPS: es el precio de la libertad que ofrece, con root, servicios persistentes y una pila a medida. La tabla siguiente enfrenta cada criterio con la persona que se encarga, porque esa línea, mucho más que las cifras de RAM, cambia su carga de trabajo. Aquí se razona en responsabilidades, no en rendimiento bruto.
Compartido y VPS, criterio por criterio
Desplace la tabla
| Criterio | Hosting compartido (quién se encarga) | VPS (quién se encarga) |
|---|---|---|
| Acceso root | No, cuentas cPanel acotadas: el proveedor | Sí, completo: la agencia |
| Aislamiento entre sitios | Cuentas cPanel aisladas entre sí: el proveedor | Un VPS por cliente, o radio de impacto común si varios sitios conviven: la agencia |
| Actualizaciones del kernel | Aplicadas en la máquina compartida: el proveedor | Actualización y reinicio planificados: la agencia |
| Actualizaciones de PHP | Parches aplicados en el servidor: el proveedor | Paquetes que actualizar y probar: la agencia |
| Cortafuegos | Cortafuegos del servidor: el proveedor | Que configurar y mantener al día: la agencia |
| Copias de seguridad | Según el plan, semanales en la gama de entrada y diarias en Pro y Agency: el proveedor | Estrategia que definir y probar: la agencia |
| Supervisión | Máquina supervisada por el proveedor, sitio vigilado por usted: compartido | Disponibilidad, disco, certificados, servicios: la agencia |
| Escalado | Límites por cuenta, luego plan superior o VPS: el proveedor y la agencia | Recursos ajustados a demanda, arquitectura en sus manos: la agencia |
PHP2Shell: el parche de PHP, en compartido y en VPS
El 21 de octubre de 2026, el proyecto PHP publicó el aviso de CVE-2026-109619, apodada PHP2Shell, una ejecución remota de código clasificada como crítica y corregida en PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12. En compartido, el proveedor aplica el parche; en un VPS, le toca a usted actualizar PHP en cada máquina y recargar PHP-FPM. El artículo dedicado a PHP2Shell detalla el inventario y las mitigaciones.
Fragnesia: cuando el kernel es el de la agencia
Fragnesia (CVE-2026-46300) es una vulnerabilidad del kernel de Linux que permite una escalada local de privilegios hasta root. En compartido, el proveedor planifica la actualización del kernel; en un VPS, el kernel es el de la agencia, y por tanto su ventana de mantenimiento y su reinicio, porque un VPS que nunca se reinicia conserva el kernel antiguo en memoria. Compruebe el kernel activo con uname -r. El artículo dedicado a Fragnesia detalla la vulnerabilidad y las mitigaciones.
Aislamiento y copias: lo que protege a un cliente de los demás
En un hosting compartido, cada sitio vive en una cuenta cPanel aislada: un sitio comprometido no da, en principio, acceso a los archivos del vecino. En un VPS, el aislamiento depende de cómo lo reparta. Un VPS por cliente traza una frontera nítida, pero multiplica las máquinas que mantener al día. Varios sitios mezclados en un mismo VPS reducen la factura, pero comparten un radio de impacto común: un plugin vulnerable en un sitio expone a todos los demás, y un acceso root robado se los lleva todos. En cuanto a las copias, no generalice. En compartido, la frecuencia depende del plan: semanal en la gama de entrada, diaria en los planes Pro y Agency. Revise la ficha del plan antes de prometer una frecuencia de restauración a un cliente. En un VPS, nada se decide por usted: la estrategia de copias, su destino fuera de la máquina y sobre todo la prueba de restauración los define y verifica la agencia. Una copia nunca restaurada sigue siendo una hipótesis.
Cuántas horas de mantenimiento al mes y por sitio
Las cifras de la tabla siguiente no son un benchmark: son las hipótesis de este artículo, que debe sustituir por sus propias mediciones. Suponen un VPS Linux estándar por cliente, llevado por una persona competente, frente a un sitio en una cuenta compartida cuyo proveedor lleva la máquina. El total da el orden de magnitud: unas 0,75 h al mes y por sitio en compartido, frente a unas 4,5 h al mes por VPS. Con doce clientes, son 9 h frente a 54 h al mes. Compare con su tarifa horaria interna: si la diferencia de horas, valorada a esa tarifa, supera la diferencia de precio mensual, a igual período de facturación, entre 799 DH/año y 99 DH/mes, el VPS cuesta más que su tarifa publicada. Agrupar varios sitios en un VPS divide las horas por sitio, pero agranda el radio de impacto. La opción de administración de VPS puede trasladar parte de esas horas a ServOrbit; compruebe su alcance en la página de VPS. Las guías del blog se ofrecen sin soporte.
Hipótesis del artículo: horas de mantenimiento al mes
Desplace la tabla
| Tarea | Compartido (por sitio) | VPS (por servidor) |
|---|---|---|
| Kernel y reinicios | 0 h | 0,5 h |
| PHP y paquetes del sistema | 0 h | 1 h |
| Cortafuegos y refuerzo | 0 h | 0,5 h |
| Copias y prueba de restauración | 0,25 h | 1 h |
| Supervisión y alertas | 0,25 h | 0,75 h |
| Incidentes y guardias | 0,25 h | 0,75 h |
| Total | 0,75 h | 4,5 h |
Rejilla de decisión: cinco preguntas de sí o no
¿El tráfico supera de forma duradera los límites del plan?
No: el compartido basta. Sí, de forma sostenida y no por un pico aislado: pase a la pregunta 2. Un pico puntual se trata primero con caché y con el plan superior.
¿El cliente tiene varios sitios o servicios pesados?
No: siga en compartido mientras aguanten los límites de procesos. Sí: el VPS se vuelve creíble, pase a la pregunta 3.
¿Necesita root o servicios persistentes?
No: el compartido sigue siendo la opción por defecto. Sí, para un demonio, una cola de tareas, un motor de base de datos específico o una pila no estándar: el VPS está justificado, pase a la pregunta 4.
¿Hay que aislar a este cliente de los demás?
Sí, por datos sensibles o una exigencia contractual: prevea un VPS dedicado a ese cliente. No: el aislamiento por cuenta cPanel del compartido ya basta.
¿Tiene la competencia de administración y la guardia?
No: no abra un VPS sin administración prevista, quédese en compartido o estudie la opción de administración de VPS. Sí: el VPS queda validado y usted presupuesta las horas de la tabla anterior.
Las señales que justifican cambiar de modelo
Un alojamiento no se elige de una vez por todas. Dos familias de señales desencadenan una migración, en un sentido o en otro. Hacia el VPS, son restricciones técnicas que se repiten: el mismo techo alcanzado cada mes, un servicio que el compartido no permite. Hacia el compartido, es lo contrario: la máquina cuesta más tiempo del que aporta. Anote la fecha y la causa de cada incidente ligado a los límites o a la administración. Regla práctica de este artículo: un incidente aislado es un accidente, tres en un trimestre son una señal.
Siete señales de migración
- Hacia el VPS: procesos o memoria limitados — los errores de límite vuelven pese a optimizar el sitio, se alcanza el techo del plan.
- Hacia el VPS: root o servicios persistentes — el proyecto exige un demonio, un worker, un motor de búsqueda o una versión del sistema que el compartido no ofrece.
- Hacia el VPS: carga sostenida — la carga se mantiene alta durante varias semanas, no solo durante una campaña puntual.
- Hacia el VPS: cortafuegos o pila específicos — una regla de red, un proxy inverso o un entorno de ejecución concreto pasa a ser exigencia del cliente.
- Hacia el compartido: poco tráfico — el sitio cabe de sobra en un plan compartido y el VPS duerme la mayor parte del tiempo.
- Hacia el compartido: sin competencia de administración — nadie en el equipo puede aplicar un parche de kernel o de PHP en el día.
- Hacia el compartido: guardia superior al valor — las horas de mantenimiento superan lo que el cliente paga por el sitio.
Migrar limitando la interrupción: seis pasos
Hacer copia del origen
Haga una copia completa de los archivos y de la base de datos, y compruebe que se restaura en una máquina de pruebas antes de tocar nada.
Reducir el TTL del DNS
Al menos 24 a 48 horas antes del cambio, baje el TTL de los registros a 300 segundos y compruebe con
dig +short your-domain.com.Montar el destino
Instale la pila en el VPS, o cree la cuenta cPanel, copie los archivos y la base de datos y reproduzca la configuración de PHP y las tareas programadas.
Probar antes del cambio
Pruebe el destino sin tocar el DNS con
curl -I --resolve your-domain.com:443:IP_CIBLE https://your-domain.com/y recorra formularios, pago y envío de correo.Cambiar
Congele las escrituras en el origen si el sitio las recibe, haga una copia final de la base de datos y cambie el registro A. Mantenga el TTL corto durante el cambio.
Vigilar y cerrar
Vigile los registros durante 48 horas, conserve el origen intacto unos días, vuelva a subir el TTL y retire el entorno antiguo.
Regla de arbitraje para una cartera
Parta del compartido para cada sitio nuevo de cliente, y pase al VPS solo ante una señal escrita: un límite alcanzado, una necesidad de root, una exigencia de aislamiento. Lleve una tabla por cliente con el modelo, la fecha de la última actualización del kernel y de PHP, y la última restauración probada. Un VPS cuya fila no está al día es una deuda que usted carga en lugar del cliente.
La documentación oficial
Aviso de seguridad de PHP2Shell (GitHub, proyecto PHP) : https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
Ficha de Debian sobre Fragnesia : https://security-tracker.debian.org/tracker/CVE-2026-46300
Cobertura de Fragnesia en Security Affairs : https://securityaffairs.com/192145/security/linux-kernel-bug-fragnesia-allows-local-root-access-attacks.html
Versiones de PHP con soporte : https://www.php.net/supported-versions.php
