Por qué un runtime PHP administrado supera a un VPS crudo
En un VPS desnudo eres dueño de todo el stack: actualizaciones del sistema operativo, el pool de PHP-FPM, la configuración del servidor web, la renovación de TLS, las reglas de firewall, y el daemon de base de datos. Cualquiera de ellos desviándose rompe el sitio, y la mayoría de ese trabajo no tiene nada que ver con tu aplicación. La plataforma PHP administrada te da un runtime PHP 8 soportado con las extensiones habituales ya presentes, así que tu responsabilidad se reduce al código, sus dependencias, y su configuración — las partes que en verdad son tuyas.
Amigable con frameworks para Laravel y Symfony
Los frameworks modernos esperan un layout específico: un document root public/, un directorio storage o var escribible, y dependencias administradas por Composer. La plataforma se ajusta directamente a eso — defines el document root en public/ y mantienes el resto del árbol privado. La extensión phpredis está disponible en el runtime, así que una app que se conecta a su propio Redis funciona sin un build a medida; si quieres una instancia de Redis administrada aprovisionada para ti, eso es un add-on de Container Apps.
Una base de datos MySQL administrada sin ser DBA
Levantar MySQL tu mismo significa afinado, backups, gestión de usuarios, y mantenerlo parcheado. Aquí la base de datos viene administrada con la cuenta: se aprovisiona por ti, las credenciales se muestran en el panel, y tu las pegas en la configuración de tu app. Rotar la contraseña es una acción del panel, y el almacen de datos se mantiene por separado de tu runtime de aplicación.
Despliega de forma simple — y sabe donde vive el pipeline de Git
No todo proyecto PHP está en Git, y un sitio pequeño o una app legacy subida por el file manager puede estar en vivo en minutos — ese es el flujo de trabajo alrededor del cual está construida esta plataforma. Cuando un proyecto lo supera y quiere push-to-deploy, pasos de build y logs de deploy, el hogar correcto es Container Apps con GitHub Deploy: pones la app en un contenedor una vez y obtienes allí el pipeline completo de Git.
caché edge y WAF delante de PHP dinámico
Las aplicaciones PHP gastan CPU real renderizando páginas, así que servir respuestas cacheables desde el edge protege directamente tu runtime de la carga. Decides que rutas son seguras de cachear — un catálogo público o un artículo — y cuáles siempre se ejecutan, como un dashboard con sesión iniciada o un endpoint POST. El WAF se ubica en el edge delante de la aplicación, filtrando tráfico de inyección y de escáneres antes de que llegue a PHP, y Auto SSL mantiene el HTTPS valido sin un cron de renovación.
Un camino controlado para modernizar PHP legacy
Las aplicaciones antiguas escritas para PHP 5 o un CMS sin mantenimiento son riesgosas de tocar, pero no pueden quedarse en un runtime end-of-life para siempre. La plataforma te da un lugar para traer el código, mover su base de datos a MySQL administrado con el character set correcto, y ejecutarlo en PHP 8 donde puedes encontrar y corregir las deprecaciones. Validas en una URL temporal y pones el WAF delante de una base de código que ya no recibe parches de seguridad, así que la superficie de ataque pública se reduce incluso antes de que el código esté completamente limpio.
Cómo desplegar, paso a paso
Crea la app PHP y elige el runtime
En el panel abre Platform, elige PHP, y selecciona la versión de PHP 8 y el plan. El runtime viene con las extensiones comunes que las apps PHP esperan — PDO, mbstring, GD, OpenSSL, y la extensión de Redis — así que no tienes que abrir tickets para habilitar una extensión.
Sube tu código a la plataforma
Sube tu aplicación a través del file manager integrado — para apps de framework defines el document root en el directorio public/ y mantienes el resto del árbol privado. Si tu equipo quiere push-to-deploy con Git y pasos de build, ese flujo de trabajo es para lo que existe Container Apps con GitHub Deploy; la plataforma PHP mantiene el despliegue deliberadamente simple.
Conecta la base de datos MySQL administrada
Una base de datos MySQL administrada se aprovisiona con tu cuenta de hosting. Su host, nombre, usuario y contraseña se muestran en el panel — tu los pones en el .env o la configuración de tu app tu mismo, y puedes resetear la contraseña desde el panel en cualquier momento sin tocar el servidor de base de datos, porque no hay un servidor de base de datos que tengas que correr.
Apunta el dominio y emite Auto SSL
Conecta tu dominio o un subdominio name.cdn.com.tr, y Auto SSL emite y renueva el certificado para el apex y www. El tráfico ahora llega primero al edge de cdn.com.tr, donde ocurre la terminación SSL antes de que las solicitudes se proxien a tu runtime PHP.
Define el caché edge y las reglas de WAF
Define que rutas son cacheables en el edge y cuáles siempre llegan a PHP, y aplica un perfil de WAF. Las respuestas cacheables se sirven desde el edge sin despertar tu runtime, y un purge desde el panel o la API las limpia al instante después de que subes un release nuevo.
Escenarios de ejemplo
Una app Laravel corre en el runtime PHP 8 administrado con la base de datos MySQL administrada, servida detrás de Auto SSL, caché edge y WAF.
Un viejo portal de CMS a medida se traslada a PHP 8 con una base de datos administrada, se pone detrás del WAF, y se moderniza ruta por ruta sin tiempo fuera de línea.
Una API PHP escrita a mano corre en el runtime administrado con la base de datos MySQL administrada, expuesta en un dominio con terminación SSL en el edge y filtrado WAF delante.
Preguntas frecuentes
Qué extensiones de PHP están disponibles en el runtime?
El runtime PHP 8 viene con las extensiones de las que dependen las apps típicas — PDO y drivers de MySQL, mbstring, GD para manejo de imágenes, OpenSSL, cURL, y la extensión phpredis para apps que se conectan a un Redis propio. Como el conjunto de extensiones es estándar, Laravel, Symfony, y la mayoría de los paquetes de Composer se instalan sin un build a medida.
Puedo correr un queue worker de Laravel o tareas programadas?
No en la plataforma PHP — ejecuta tu app por solicitud web y no tiene un gestor de workers ni de cron. Si tu app depende de queue workers o de trabajos programados, ejecútala como una Container App en su lugar: los contenedores son procesos de larga duración, y esa plataforma además ofrece Redis administrado como backend de cola.
Cómo llegan las credenciales de base de datos a mi app?
Las credenciales del MySQL administrado — host, nombre de base de datos, usuario, contraseña — se muestran en el panel. Tú las pones en tu .env o archivo de configuración en la plataforma (fuera de la ruta servida al público), así que nunca necesitan comitearse a Git, y puedes resetear la contraseña desde el panel sin un ticket de soporte.
Mi app apunta a PHP 7 — correrá en PHP 8?
La mayoría del código mantenido corre en PHP 8 con ajustes menores, pero PHP 8 eliminó algo de comportamiento deprecado. El enfoque correcto es traer el código a la plataforma, correrlo en una URL temporal, y corregir las deprecaciones que encuentres antes de cambiar el dominio — el runtime administrado te da un lugar seguro para hacer exactamente eso.
Defino el document root en public/?
Si. Para Laravel, Symfony, y frameworks similares apuntas la raíz web al directorio public/ para que el resto del árbol de la aplicación — incluyendo .env, vendor, y storage — quede fuera de la ruta servida al público. Las apps legacy que sirven desde su directorio de nivel superior también son compatibles; defines la raíz en consecuencia.
Cómo manejo subidas de archivos que deben sobrevivir a un redeploy?
La app tiene un volumen persistente para datos de usuario, y para apps con mucho contenido multimedia puedes descargar las subidas a object storage y servirlas a través del CDN en lugar del runtime. Eso mantiene los deploys rápidos y sin estado, y significa que un redeploy o un evento de escalado nunca pone en riesgo los archivos subidos.