Por que 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 configuracion del servidor web, la renovacion de TLS, las reglas de firewall, y el daemon de base de datos. Cualquiera de ellos desviandose rompe el sitio, y la mayoria de ese trabajo no tiene nada que ver con tu aplicacion. La plataforma PHP administrada te da un runtime PHP 8 soportado con las extensiones habituales ya presentes, asi que tu responsabilidad se reduce al codigo, sus dependencias, y su configuracion — las partes que en verdad son tuyas.
Amigable con frameworks para Laravel y Symfony
Los frameworks modernos esperan un layout especifico: un document root public/, un directorio storage o var escribible, dependencias administradas por Composer, y un lugar para ejecutar migraciones de base de datos en cada deploy. La plataforma se ajusta directamente a eso — defines el document root en public/, mantienes el resto del arbol privado, y conectas composer install y comandos de migracion de artisan/console en los pasos de deploy. Redis esta disponible para cache, colas y sesiones, que es exactamente lo que quiere un queue worker de Laravel o un cache pool de Symfony.
MySQL y Redis administrados sin ser DBA
Levantar MySQL y Redis tu mismo significa afinado, backups, gestion de usuarios, y mantenerlos parcheados. Aqui ambos son add-ons administrados: los aprovisionas, y su host, puerto, usuario y contraseña se inyectan en el entorno de la app en lugar de pegarse en un archivo de configuracion. Eso mantiene los secretos fuera de tu historial de Git, te permite rotar una contraseña de base de datos sin redesplegar codigo, y significa que el almacen de datos se mantiene por separado de tu runtime de aplicacion.
Despliega de la forma en que tu equipo ya trabaja
No todo proyecto PHP esta en Git todavia, y esta bien. Un sitio pequeño o una app legacy se puede subir por el file manager y estar en vivo en minutos. Un equipo con un repositorio conecta Git o GitHub y obtiene push-to-deploy con pasos de build definidos — composer install, un build de front-end, migraciones — asi que los releases son repetibles en lugar de un arrastrar-y-soltar por SFTP donde alguien olvida un archivo. El estado de deploy y la hora del ultimo deploy son visibles en el panel.
Cache edge y WAF delante de PHP dinamico
Las aplicaciones PHP gastan CPU real renderizando paginas, asi que servir respuestas cacheables desde el edge protege directamente tu runtime de la carga. Decides que rutas son seguras de cachear — un catalogo publico o un articulo — y cuales siempre se ejecutan, como un dashboard con sesion iniciada o un endpoint POST. El WAF se ubica en el edge delante de la aplicacion, filtrando trafico de inyeccion y de escaneres antes de que llegue a PHP, y Auto SSL mantiene el HTTPS valido sin un cron de renovacion.
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 codigo, 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 codigo que ya no recibe parches de seguridad, asi que la superficie de ataque publica se reduce incluso antes de que el codigo este completamente limpio.
Como desplegar, paso a paso
Crea la app PHP y elige el runtime
En el panel abre Platform, elige PHP, y selecciona la version de PHP 8 y el plan. El runtime viene con las extensiones comunes que las apps PHP esperan — PDO, mbstring, GD, OpenSSL, y la extension de Redis — asi que no tienes que abrir tickets para habilitar una extension.
Sube tu codigo a la plataforma
Usa el file manager integrado para una subida rapida, o conecta un repositorio Git/GitHub para que un push despliegue la app. Para apps de framework defines el document root en el directorio public/ y defines los pasos de build y migracion una sola vez.
Conecta una base de datos administrada y Redis
Aprovisiona una base de datos MySQL administrada y, si la app necesita cache, colas o sesiones, una instancia de Redis administrada. Los valores de conexion se inyectan en el runtime como variables de entorno, asi que las credenciales quedan fuera de tu .env versionado y se pueden rotar desde el panel.
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 trafico ahora llega primero al edge de cdn.com.tr, donde ocurre la terminacion SSL antes de que las solicitudes se proxien a tu runtime PHP.
Define cache, WAF, y pasos de deploy
Define que rutas son cacheables en el edge y cuales siempre llegan a PHP, aplica un perfil de WAF, y fija el pipeline de deploy — por ejemplo composer install, un build de assets, y migraciones de base de datos — para que cada release ejecute los mismos pasos y termine con un purge automatico.
Escenarios de ejemplo
Una app Laravel se despliega desde GitHub con composer install y migraciones, usa MySQL administrado y una cola de Redis, y se sirve detras de Auto SSL y WAF.
Un viejo portal de CMS a medida se traslada a PHP 8 con una base de datos administrada, se pone detras del WAF, y se moderniza ruta por ruta sin tiempo fuera de linea.
Una API PHP escrita a mano corre en el runtime administrado con Redis para estado de rate-limit y sesion, expuesta en un dominio con terminacion SSL en el edge.
Preguntas frecuentes
Que extensiones de PHP estan disponibles en el runtime?
El runtime PHP 8 viene con las extensiones de las que dependen las apps tipicas — PDO y drivers de MySQL, mbstring, GD para manejo de imagenes, OpenSSL, cURL, y la extension de Redis usada para cache, sesiones, y colas. Como el conjunto de extensiones es estandar, Laravel, Symfony, y la mayoria de los paquetes de Composer se instalan sin un build a medida.
Puedo correr un queue worker de Laravel o tareas programadas?
Si. Redis esta disponible como backend de cola, y la plataforma ejecuta tu app en un runtime persistente en lugar de un sandbox por solicitud, asi que el procesamiento en segundo plano y los trabajos programados encajan en el modelo. Defines los comandos como parte de la configuracion de la app en lugar de editar un crontab del sistema en un servidor que de otro modo tendrias que administrar.
Como llegan las credenciales de base de datos a mi .env sin comitear secretos?
Los detalles de conexion de la base de datos administrada y Redis se inyectan en el entorno del runtime. Tu framework los lee del entorno de la forma en que ya lee valores .env, asi que nunca comiteas host, usuario, o contraseña a Git, y rotar una contraseña en el panel no requiere un cambio de codigo.
Mi app apunta a PHP 7 — correra en PHP 8?
La mayoria del codigo mantenido corre en PHP 8 con ajustes menores, pero PHP 8 elimino algo de comportamiento deprecado. El enfoque correcto es traer el codigo 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 raiz web al directorio public/ para que el resto del arbol de la aplicacion — incluyendo .env, vendor, y storage — quede fuera de la ruta servida al publico. Las apps legacy que sirven desde su directorio de nivel superior tambien son compatibles; defines la raiz en consecuencia.
Como 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 traves del CDN en lugar del runtime. Eso mantiene los deploys rapidos y sin estado, y significa que un redeploy o un evento de escalado nunca pone en riesgo los archivos subidos.