Alojamiento PHP (experimental)

Capacidad experimental

El alojamiento PHP está en estado experimental. La interfaz, el alcance del soporte de .htaccess y la compatibilidad con tecnologías específicas pueden cambiar sin previo aviso. No se recomienda para cargas productivas críticas hasta el anuncio de disponibilidad general. Si querés probarlo, coordinalo con el equipo de Host Admin.

Qué hace

Tero Services puede servir una aplicación PHP de forma directa, sin necesidad de un nginx/Apache intermedio. Admite dos modos de servir PHP (ver más abajo) e incluye un analizador de .htaccess que entiende RewriteRule y RewriteCond lo suficiente como para servir WordPress, Laravel, Symfony, CodeIgniter y la mayoría de las aplicaciones PHP convencionales.

Modos: clásico o acelerado

El modo se elige por ruta (por defecto, el clásico). Los aceleradores in-process del intérprete —OPcache, JIT, precarga, APCu— se configuran del lado del backend y son transparentes para vos.

Modo	Cuándo conviene
Clásico (por defecto)	Sitios PHP convencionales, alojamiento compartido, WordPress y similares.
Acelerado	Aplicaciones de alto tráfico con front controller único (Laravel, Symfony) que se benefician de mantener el framework en memoria entre solicitudes, sobre servidores como RoadRunner, FrankenPHP, Swoole/OpenSwoole o NGINX Unit.

En modo acelerado, los archivos estáticos reales se sirven directamente desde el borde y el resto de las solicitudes las atiende el servidor de aplicación con su propio front controller. La caché de estáticos puede cachear sus respuestas igual que con cualquier otro origen.

Cuándo usarlo

• Sitios PHP existentes que ya traen su .htaccess.
• WordPress, Joomla, Drupal.
• Aplicaciones Laravel o Symfony con public/index.php como controlador frontal.
• Migraciones desde un alojamiento compartido a Host Admin sin reescribir reglas.

Cómo se configura

Se solicita al equipo:

• Dominio.
• Modo: clásico (por defecto) o acelerado, según el perfil de tu aplicación.
• Ruta raíz del sitio (por ejemplo, el public/ en Laravel). En modo acelerado, habilita servir los estáticos desde el borde.
• Versión de PHP (si tu plan permite varias).
• Variables de entorno sensibles (base de datos, claves de API) — entregadas por canal seguro, nunca en la solicitud abierta.

El .htaccess se lee desde la ruta raíz. Los cambios en .htaccess se detectan automáticamente (la caché se invalida en unos segundos).

Directivas soportadas

Directiva	Soporte
RewriteEngine On	Sí
RewriteBase	Sí
RewriteRule	Sí (con marcas más comunes: L, R, QSA, NC)
RewriteCond	Sí (%{REQUEST_FILENAME}, -f, -d, encabezados, etc.)
Options -Indexes	Equivalente: el directorio no se lista
AuthBasic	No (usar control intermedio externo)
DirectoryIndex	Parcial — el controlador frontal suele resolver esto

Si tu aplicación usa una directiva poco común y no funciona, contactá al equipo: se evalúa caso por caso.

Aplicaciones probadas

• WordPress — sitio único y multi-sitio (subcarpeta, subdominio).
• Laravel ≥ 8 con public/index.php.
• Symfony ≥ 5 con public/index.php.
• CodeIgniter 3 y 4.
• Magento 2 — bajo coordinación, requiere ajustes de tiempos de espera.

Limitaciones

• No es un Apache completo: si el .htaccess depende de módulos exóticos (mod_security personalizado, mod_xsendfile, etc.), pedinos revisión.
• El alojamiento PHP corre sobre infraestructura gestionada por Host Admin; las versiones y recursos disponibles dependen de tu plan.

Preguntas frecuentes

• ¿Puedo subir el código yo? Sí, vía SFTP/Git según tu plan. La estructura de carpetas la coordina el equipo al dar de alta el sitio.
• ¿Hay opcache? Sí, corre con opcache habilitado. Tras una publicación podés solicitar el reinicio de la aplicación.
• ¿Qué modo me conviene? Para WordPress y sitios PHP clásicos, el modo clásico. Para Laravel/Symfony de alto tráfico, el modo acelerado mantiene el framework caliente entre solicitudes y rinde mejor bajo carga.