Durante años, la forma de trabajar con PHP fue casi inmutable: un servidor web (Nginx o Apache) recibiendo las peticiones y PHP-FPM ejecutando la aplicación (Symfony, Laravel, WordPress…) desde cero en cada solicitud.
Era un modelo sencillo, predecible y sorprendentemente robusto. Precisamente esa característica, arrancar limpio en cada petición, ayudó a PHP a dominar gran parte de la web. Al eliminar el estado compartido entre peticiones, desaparecían de un plumazo muchos problemas clásicos de memoria, concurrencia y efectos secundarios entre usuarios.
Pero el ecosistema está cambiando.
La llegada de FrankenPHP y su adopción cada vez más seria por parte de Symfony plantean una pregunta que hace solo dos años parecía casi herética: ¿seguimos necesitando PHP-FPM como pieza central de nuestras aplicaciones modernas?
PHP-FPM no es el enemigo
Antes de seguir, es importante dejarlo claro: PHP-FPM no es un problema que necesite ser reemplazado urgentemente.
Durante décadas ha proporcionado aislamiento perfecto entre peticiones, estabilidad operativa, compatibilidad universal y un modelo mental que cualquier desarrollador entiende en minutos. La gran mayoría de aplicaciones empresariales funcionan excelente con esta arquitectura y seguirán haciéndolo durante muchos años más.
Hablar del «fin de PHP-FPM» es, en la mayoría de casos, una exageración. Lo que sí estamos viendo es el nacimiento de una alternativa que ya empieza a ser lo suficientemente madura como para tomársela muy en serio.
El cambio real no es FrankenPHP, es el modelo de ejecución
Muchos se centran en FrankenPHP como herramienta, pero el verdadero salto está en lo que representa.
FrankenPHP es un servidor de aplicaciones escrito en Go que unifica en un solo binario lo que antes eran Nginx + PHP-FPM. Trae HTTPS automático, HTTP/3 y, sobre todo, un Worker Mode que mantiene la aplicación Symfony cargada en memoria entre peticiones. El contenedor de servicios, la configuración y gran parte del bootstrap dejan de reconstruirse cada vez.
Las ventajas técnicas son evidentes: menos consumo de CPU, latencia más baja y mejor aprovechamiento de recursos. Pero la consecuencia más profunda es otra: PHP empieza a comportarse como plataformas que históricamente considerábamos «más modernas» (Node.js, Go, Java, etc.).
La pregunta deja de ser «¿cómo hacemos que arranque más rápido?» y pasa a ser «¿cómo gestionamos correctamente un proceso que nunca se detiene?».
La velocidad tiene un precio
El modelo tradicional de PHP tenía una ventaja enorme que mucha gente no valoraba lo suficiente: el estado era efímero por diseño. Si algo se corrompía, la siguiente petición empezaba desde cero.
Cuando la aplicación vive permanentemente en memoria, esa red de seguridad desaparece. De repente aparecen responsabilidades que los desarrolladores PHP llevamos décadas sin tener que gestionar activamente:
- Gestión explícita del estado entre peticiones
- Prevención de fugas de memoria a largo plazo
- Servicios realmente stateless (no solo de nombre)
- Ciclos de vida más complejos para conexiones a bases de datos, cachés y otros recursos compartidos
No es imposible, Node.js y Go llevan años viviendo en este mundo, pero exige una mentalidad distinta, nuevas herramientas y un conocimiento más profundo del comportamiento interno de nuestras aplicaciones.
La velocidad no viene gratis.
Symfony 7.4: más que nuevas features, una dirección clara
Lo que más me gusta de Symfony 7.4 no es ninguna funcionalidad concreta.
Es la sensación de que el framework está tomando conscientemente una dirección alineada con hacia dónde se mueve toda la industria. La integración nativa con FrankenPHP, los nuevos entornos Docker optimizados para Dev Containers, las mejoras de developer experience (PHP 8.4, clases readonly, atributos como #[MapRequestPayload] que eliminan boilerplate real) y la apertura hacia herramientas de IA forman un conjunto coherente.
Symfony ya no solo se pregunta cómo construir aplicaciones robustas. También se pregunta cómo construirlas más rápido, desplegarlas con menos fricción y permitir que los equipos ganen autonomía real. La experiencia del desarrollador se está convirtiendo en una ventaja competitiva de primer orden.
La IA como parte natural del entorno
Hace solo dos años, integrar asistentes de IA en el día a día parecía algo experimental. Hoy estamos viendo entornos que directamente asumen que estos agentes van a formar parte habitual del ciclo: generando código, analizando proyectos, ejecutando tareas repetitivas en espacios controlados.
No creo que la IA vaya a sustituir a los desarrolladores en el corto o medio plazo (al menos no de la forma sensacionalista que suele contarse). Pero sí estoy convencido de que quienes aprendan a trabajar junto a estos sistemas, integrándolos de verdad en su flujo, tendrán una ventaja significativa.
Que Symfony esté preparando su ecosistema para este escenario no es un detalle menor.
De dónde venimos y hacia dónde vamos
PHP-FPM no va a desaparecer de la noche a la mañana. FrankenPHP tampoco va a reemplazar la arquitectura clásica en todos los proyectos.
Sin embargo, creo que estamos ante uno de los cambios más importantes en la evolución de PHP desde la llegada de Composer. Por primera vez en mucho tiempo, la conversación no gira solo en torno a frameworks o librerías, sino sobre los propios fundamentos de cómo se ejecutan nuestras aplicaciones.
Es posible que dentro de cinco años sigamos usando PHP-FPM en miles de sistemas legacy y nuevos proyectos conservadores. Pero también es probable que miremos atrás y veamos en Symfony 7.4 y FrankenPHP el punto de inflexión en el que PHP dejó definitivamente atrás el modelo que lo acompañó durante más de veinte años.
Ese cambio, con todo lo que implica, merece nuestra atención.