PHP-FPM consolidó una operación conocida: recibe requests, distribuye procesos y reinicia el estado de la aplicación de forma previsible entre ejecuciones. FrankenPHP propone otro paquete. Integra el intérprete PHP en Caddy y ofrece HTTPS automático, HTTP/2, HTTP/3, compresión, métricas y un worker mode que mantiene la aplicación en memoria entre requests.
La PHP Foundation comenzó a apoyar oficialmente el proyecto y anunció el traslado del código a la organización de PHP en GitHub. Este apoyo reduce una duda importante sobre continuidad, pero no convierte a FrankenPHP en sustituto inmediato de todos los entornos FPM.
La diferencia decisiva está en el ciclo de vida. Inicializar el framework una vez evita trabajo repetido y también permite que un estado inadecuado sobreviva mucho más tiempo.
Worker mode cambia bootstrap por disciplina de estado
En una ejecución tradicional, el framework carga autoloader, container y configuración en cada request. FPM puede reutilizar el proceso, pero el estado de la aplicación comienza de nuevo. En worker mode, el bootstrap ocurre antes del loop y la misma aplicación atiende muchas solicitudes.
Este diseño reduce latencia y CPU cuando la inicialización es costosa. La PHP Foundation citó un análisis de Sylius en el que worker mode redujo tiempos de respuesta en un 80% y necesitó más de seis veces menos máquinas para la misma carga. El resultado pertenece a ese sistema y no debe convertirse en promesa universal.
La ganancia depende del peso del bootstrap y del trabajo de cada request. Una aplicación que pasa la mayor parte del tiempo en la base o en una API externa puede ver una diferencia menor. Un benchmark útil usa tráfico representativo y datos equivalentes, y mide cola de latencia, memoria y estabilidad a lo largo del tiempo.
El estado persistente revela defectos que FPM ocultaba
Variables globales, singletons mutables, cachés locales y servicios que guardan al usuario actual pueden filtrar información entre requests. Las conexiones envejecen, los buffers crecen y las bibliotecas que presuponen procesos cortos pueden acumular memoria.
La documentación de worker mode exige terminar correctamente cada iteración y liberar recursos. Las integraciones de frameworks reinician estado conocido, mientras el código de la aplicación y sus dependencias continúan bajo responsabilidad del equipo.
Una prueba funcional corta puede pasar pese a una fuga. La validación debe mantener vivo al worker, alternar usuarios y tenants, provocar excepciones y observar memoria. Los reinicios periódicos limitan el impacto, pero no corrigen la causa.
Esta es la principal barrera para bases antiguas. El código no necesita ser stateless en un sentido absoluto. Necesita impedir que el estado específico de una request sobreviva sin intención. Esa propiedad debe demostrarse.
El binario integrado simplifica y concentra
FrankenPHP usa Caddy como servidor web. Certificados, protocolos modernos, compresión, Early Hints, logs y métricas pueden entrar en el mismo runtime. Los proyectos pequeños pueden retirar archivos y procesos separados de Nginx, proxy y FPM.
La concentración también cambia la operación. Actualizar el binario puede modificar servidor y PHP al mismo tiempo. La imagen de contenedor, las extensiones compiladas y la configuración de Caddy necesitan un proceso de release claro. Una stack separada permite actualizaciones independientes; una integrada reduce puntos de configuración.
Ningún modelo es siempre menor. El equipo debe comparar lo que realmente mantiene. Si la plataforma ya administra proxy, TLS y observabilidad, retirar Nginx quizá aporte poco. Si cada servicio lleva configuración propia, el binario integrado puede eliminar trabajo recurrente.
La migración debe comenzar con un servicio representativo
El mejor piloto no es una página vacía. Elige un servicio con framework, base, autenticación, colas relacionadas y carga conocida. Ejecuta el mismo escenario en FPM y worker mode. Mide throughput, percentiles de latencia, memoria después de miles de requests, errores y tiempo de deploy.
Incluye pruebas de aislamiento. Alterna cuentas, idiomas y permisos. Comprueba si una request con excepción contamina la siguiente. Fuerza reconexión de base y rotación de secrets. Estas situaciones dicen más sobre preparación que un pico de requests por segundo.
Conserva también una ruta de regreso. El piloto aporta valor cuando enseña sin hacer irreversible el runtime. Contenedor y configuración deberían permitir volver a FPM mientras el equipo corrige dependencias incompatibles.
El apoyo institucional reduce un riesgo, no todos
La participación de PHP Foundation mejora mantenimiento, compatibilidad con nuevas versiones y confianza en el proyecto. No elimina los riesgos particulares de cada aplicación ni define dónde compensa worker mode.
FrankenPHP merece evaluación porque cambia rendimiento y cantidad de infraestructura. Las pruebas deben cubrir ambas dimensiones. Una aplicación puede ganar velocidad y perder aislamiento, o simplificar deploy y aumentar el alcance de una actualización mala.
El runtime deja de ser invisible cuando el proceso persiste. Los equipos que midan estado, memoria y operación junto con throughput podrán decidir si el ahorro es real en su carga.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
