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.

Preguntas frecuentes

¿El alojamiento compartido de OVH puede ejecutar PHP 8.3 en 2026?

Sí. La versión se fija con una sola línea en un archivo .ovhconfig en la raíz del sitio, por ejemplo app.engine.version=8.3, y OVH aprovisiona ese runtime para el dominio. El cambio surte efecto en pocos minutos y se confirma con una página phpinfo().

¿Puedo ejecutar un worker en segundo plano o un daemon en el alojamiento compartido de OVH?

No. El alojamiento compartido no da root ni permite procesos de larga duración, así que un worker de cola persistente o un daemon de websocket será terminado. La alternativa admitida es el programador cron de OVH ejecutando un script PHP o shell en un intervalo fijo (hasta una vez por minuto en la mayoría de planes), suficiente para tareas por lotes, reconstrucción de sitemaps y tareas de sondeo.

¿El alojamiento compartido de OVH admite SQLite?

Sí, SQLite funciona en el alojamiento compartido porque es solo un archivo en disco y viene incluido con el PHP del plan, lo que sirve para sitios de bajo tráfico, cachés de lectura intensiva y almacenamiento de CMS embebidos como Cockpit. Para cualquier cosa con escrituras concurrentes conviene usar la base de datos MySQL/MariaDB incluida en el plan, ya que SQLite bloquea todo el archivo en cada escritura.

¿Qué no se puede hacer en el alojamiento compartido de OVH?

No puedes obtener root, instalar paquetes del sistema, ejecutar servicios propios, abrir puertos arbitrarios, usar Docker ni compilar extensiones de PHP que OVH no proporcione ya. Además compartes CPU y memoria con otros inquilinos, así que el procesamiento pesado de imágenes, la transcodificación de vídeo o la inferencia de ML chocarán con los límites.

¿Cuándo debo pasar del alojamiento compartido de OVH a un VPS?

Pasa a un VPS cuando necesites root, un proceso de larga duración, una extensión de PHP o paquete del sistema personalizado, despliegue en contenedores o CPU y RAM garantizadas. Hasta entonces, un plan compartido bien ajustado con PHP 8.3 fijado, cron y SQLite o MySQL cubre sin problema la mayoría de sitios corporativos, blogs y pequeños proyectos basados en CMS.

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.