Hosting Compartido de OVH en 2026: Qué Puede (y Qué No) Ejecutar con PHP 8.3

El hosting compartido de OVH en 2026 ejecuta PHP 8.3 perfectamente para un sitio renderizado en el servidor, pero no es un servidor que tú controles. Recibes un contenedor Apache + PHP gestionado, una raíz de documentos en /www/ y un menú fijo de versiones y límites. No tienes root, no puedes mantener un proceso vivo y tu horario de cron está racionado. Si tu aplicación cabe dentro de "llega una petición, PHP renderiza HTML, la petición termina", es un hogar excelente, barato y duradero. Si necesitas un demonio, un websocket o Postgres, ya lo has superado. Este es el mapa honesto del terreno, trazado desde ejecutar amplifiedcreations.com exactamente en esta pila.

Qué puede ejecutar el hosting compartido de OVH con PHP 8.3

En resumen: cualquier cosa que sea sin estado y acotada a la petición. Una aplicación PHP clásica al estilo LAMP, un CMS renderizado en el servidor, un híbrido estático-más-PHP, WordPress, Laravel en sus configuraciones más modestas, una instalación de Cockpit CMS sobre SQLite — todo viable. Ejecutamos una aplicación PHP 8.3 sin paso de build: las peticiones llegan a Apache, PHP renderiza HTML, la respuesta vuelve a través de Cloudflare. Sin proceso Node, sin PM2, sin Redis. El hosting hace exactamente la única cosa en la que el hosting compartido es bueno.

Lo que realmente obtienes en un plan compartido de OVH actual:

• PHP 8.0 hasta 8.3, seleccionable, con las extensiones comunes presentes: pdo_sqlite, pdo_mysql, gd, curl, mbstring, intl, opcache.
• Apache con sobrescrituras por .htaccess — tus reglas de reescritura, redirecciones y cabeceras viven aquí, no en un vhost que no puedes tocar.
• Bases de datos MySQL/MariaDB (en número limitado según el plan) y el sistema de ficheros, lo que significa que SQLite "simplemente funciona".
• Cron, FTP/SFTP y SSH en la mayoría de los planes — pero un SSH muy recortado frente a un VPS.

Esto cubre la inmensa mayoría de sitios de contenido, sitios corporativos, pequeño comercio electrónico y sitios de marketing basados en CMS. Es genuinamente suficiente.

Fija tu versión de PHP con .ovhconfig — no confíes en el panel

El fichero más importante de una cuenta compartida de OVH es .ovhconfig a nivel de la raíz de documentos. Fija el runtime para que un interruptor del panel o un cambio de valor por defecto del lado de OVH no te muevan silenciosamente a otra versión de PHP entre despliegues. El nuestro tiene cinco líneas:

app.engine=php
app.engine.version=8.3
http.firewall=none
environment=production
container.image=stable64

Trata .ovhconfig como código y versiónalo en tu repositorio. Unas cuantas notas de campo aprendidas a las malas:

• container.image=stable64 selecciona la imagen de contenedor de 64 bits. La generación de la imagen determina qué point-releases y extensiones de PHP están realmente disponibles — si una versión "no está", la imagen suele ser el motivo.
• http.firewall=none desactiva el cortafuegos de aplicación al estilo ModSecurity heredado de OVH. Lo desactivamos porque producía falsos positivos en cuerpos POST legítimos; si lo dejas activado, cuenta con depurar 403 misteriosos.
• Los cambios en .ovhconfig no son instantáneos. La propagación puede tardar unos minutos. No supongas que tu edición falló solo porque la primera recarga aún muestra la versión antigua.

Si solo te llevas una cosa de este artículo: el desplegable del panel es una sugerencia, .ovhconfig es la fuente de la verdad.

Sin root, sin procesos persistentes — diseña en torno a ello

El hosting compartido es compartido. Eres un inquilino entre varios en un contenedor, así que no tienes root, no tienes systemd y no tienes forma de mantener un proceso vivo entre peticiones. Esta es la restricción que decide si la plataforma encaja, así que sé brutalmente honesto contigo mismo al respecto.

En concreto, lo siguiente queda descartado:

• Demonios y workers. Sin consumidor de cola en un bucle, sin servidor Node, sin aplicación Python ASGI. Si entras por SSH y arrancas algo, el watchdog lo mata. No hay supervisor que lo reinicie.
• WebSockets / SSE mantenidos abiertos. Las conexiones están acotadas a la petición y al tiempo. Las funciones en tiempo real necesitan un servicio externo (Pusher, Ably, una función serverless en otro sitio).
• Instalar paquetes de sistema. Sin apt, sin compilar una extensión propia. Usas las extensiones PHP que OVH proporciona, punto. Si necesitas imagick y no está habilitada, te adaptas a gd o te vas.
• Módulos Apache personalizados o un php.ini ajustado a nivel de sistema. Sobrescribes por directorio mediante .htaccess y .user.ini, dentro de los límites que permite el hosting.

El modelo mental que te mantiene cuerdo: cada unidad de trabajo debe empezar y terminar dentro de una única petición HTTP o una única invocación de cron. Ningún estado vive en memoria entre ellas. Diseñamos nuestra aplicación para que sea completamente sin estado precisamente para que esta restricción nunca muerda — el contenido dinámico vive en el CMS y en SQLite, nunca en un proceso de larga duración.

Cron en OVH: racionado, no libre

Tienes cron, y para una aplicación PHP sin estado el cron es como haces todo el trabajo "en segundo plano". Pero los límites son reales y deberías planearlos:

• El número de tareas cron está limitado por el plan — a menudo un puñado, no ilimitado. Acabarás multiplexando varias tareas lógicas en una sola entrada de cron que llama a un script despachador.
• La frecuencia mínima está limitada. Los crons por minuto no están garantizados en planes compartidos; trata el suelo realista como unas pocas veces por hora y no construyas nada que asuma precisión por debajo del minuto.
• Cada ejecución está limitada en tiempo de reloj igual que una petición web. Un cron no es el lugar para ejecutar un lote de seis horas. Trocea el trabajo, persiste el progreso y deja que la próxima invocación continúe.

Toda nuestra huella de trabajo programado es una única tarea diaria que poda ficheros de caché generados:

php /www/lib/cache_prune.php

Ese script elimina ficheros de caché de OpenGraph y de imágenes redimensionadas con más de 60 días, tocando solo una lista explícita de subdirectorios bajo storage/cache, y devuelve recuentos para que la salida del cron sea inspeccionable. Cualquier cosa más pesada que una tarea de ordenar-y-salir tiene la forma equivocada para el cron compartido. Cuando necesitamos automatización de verdad — minificar, subir, purgar caché — la mantuvimos en nuestra propia máquina en un script de despliegue, no en el hosting.

SQLite frente a una base de datos gestionada

Esta es la decisión que la gente complica de más. En el hosting compartido de OVH tienes dos opciones sensatas, y la correcta suele ser la más simple.

SQLite es un único fichero en disco leído y escrito por el proceso PHP. Sin ida y vuelta por la red, sin credenciales, sin un segundo servicio que monitorizar. Ejecutamos Cockpit CMS v2 sobre SQLite y es la decisión correcta para un sitio de contenido: el volumen de lecturas es alto, el de escrituras es bajo (un editor guardando un artículo, ocasionalmente) y Cloudflare absorbe la mayoría de las lecturas antes de que lleguen a PHP. SQLite es excelente para cargas con muchas lecturas y pocas escrituras, con una sola aplicación escribiendo en él.

Dónde SQLite deja de ser la respuesta:

• Escritores concurrentes. SQLite serializa las escrituras con un bloqueo de fichero. Un puñado de editores está bien; una aplicación transaccional con muchas escrituras topará con SQLITE_BUSY.
• Copias de seguridad y portabilidad. Hacer backup de SQLite en hosting compartido significa copiar el fichero cuando ninguna escritura está a medias. Tomamos un snapshot como parte de la rutina en lugar de confiar en una copia en caliente.
• Escalar en varios servidores. Un fichero en el disco de un contenedor no escala a varios servidores de aplicación. El día que necesites eso, ya has superado el hosting compartido de todos modos.

El MySQL/MariaDB incluido en OVH es el paso correcto cuando tienes concurrencia real de escrituras, varias aplicaciones compartiendo datos, o un framework que espera una base de datos cliente/servidor. Es un servicio gestionado — no lo ajustas, solo recibes una cadena de conexión. Para la mayoría de los sitios basados en CMS es más de lo que necesitas; para aplicaciones transaccionales es el mínimo.

Cuándo dar el salto a un VPS

Somos partidarios de quedarnos en el hosting compartido mientras realmente encaje — es barato, el hosting parchea el SO y no hay un servidor que puedas dejar inseguro. Pero hay una línea clara. Pásate a un VPS en el momento en que tu arquitectura necesite algo que el PHP acotado a la petición no puede expresar. La checklist honesta:

• Necesitas un proceso de larga duración: un worker de cola, un servidor websocket, una tarea programada más fina de lo que permite el cron, o algo que deba mantener estado en memoria.
• Necesitas software que el hosting no proporciona: una extensión PHP específica, un runtime distinto (Node, Python, Go) sirviendo tráfico, Redis, Elasticsearch, un navegador headless para renderizado.
• Necesitas precisión de cron de verdad o muchas tareas programadas.
• Has topado con contención de escrituras de SQLite y un MySQL gestionado no resuelve la necesidad de concurrencia subyacente.
• Necesitas control sobre el servidor web — configuración Nginx propia, ajuste de HTTP/3, terminación TLS propia, fail2ban.

El compromiso es real y va en ambos sentidos: un VPS te da root y elimina todos los límites de arriba, pero ahora eres tú quien parchea el kernel, configura el cortafuegos y es dueño de cada caída a las 3 de la madrugada. Para un sitio que es fundamentalmente "renderizar HTML por petición", eso es una bajada en fiabilidad y una subida en tu carga de mantenimiento. Hemos mantenido amplifiedcreations.com en hosting compartido a propósito.

En resumen

• ¿Ejecuta PHP 8.3? Sí — fíjalo en .ovhconfig, no en el panel.
• ¿Ejecuta un CMS? Sí — Cockpit sobre SQLite es ideal para sitios de contenido con muchas lecturas.
• ¿Ejecuta workers en segundo plano / websockets? No. Sin root, sin procesos persistentes.
• ¿Es usable el cron? Sí, para tareas de ordenar-y-salir — pero está racionado en número y frecuencia.
• ¿SQLite o MySQL? SQLite para muchas lecturas/pocas escrituras; MySQL gestionado para concurrencia de escrituras.
• ¿Cuándo me voy? En el instante en que necesites un proceso de larga duración, software no proporcionado o control del servidor web. Entonces es hora de VPS.

El hosting compartido se descarta como un nivel para principiantes. No lo es. Es una restricción deliberada y, para un sitio renderizado en el servidor que respeta la restricción, es uno de los lugares más fiables y baratos donde puedes publicar. Sé exactamente dónde están las paredes, construye dentro de ellas, y durará más que tres ciclos de hype de frameworks.