O PHP-FPM consolidou uma operação conhecida: recebe requests, distribui processos e encerra o estado de cada execução de forma previsível. FrankenPHP propõe outro pacote. Ele integra o interpretador PHP ao Caddy e oferece HTTPS automático, HTTP/2, HTTP/3, compressão, métricas e um worker mode que mantém a aplicação em memória entre requests.
A PHP Foundation passou a apoiar oficialmente o projeto e anunciou a transferência do código para a organização do PHP no GitHub. Esse apoio reduz uma dúvida importante sobre continuidade, mas não transforma FrankenPHP no substituto imediato de todo ambiente FPM.
A diferença decisiva está no ciclo de vida. Inicializar o framework uma vez economiza trabalho repetido. Também permite que estado inadequado sobreviva por muito mais tempo.
Worker mode troca bootstrap por disciplina de estado
Em uma execução tradicional, o framework carrega autoloader, container e configuração a cada request. O processo pode ser reaproveitado pelo FPM, mas o estado da aplicação é reiniciado. No worker mode, o bootstrap acontece antes do loop e a mesma aplicação atende várias solicitações.
Esse desenho reduz latência e CPU quando a inicialização custa caro. A PHP Foundation citou uma análise da Sylius em que o worker mode reduziu tempos de resposta em 80% e exigiu mais de seis vezes menos máquinas para a mesma carga. O resultado é específico daquele sistema e não deve virar promessa universal.
O ganho depende do peso do bootstrap e da quantidade de trabalho por request. Uma aplicação que passa a maior parte do tempo no banco ou numa API externa pode ver diferença menor. O benchmark útil usa tráfego representativo, dados equivalentes e mede cauda de latência, memória e estabilidade ao longo do tempo.
Estado persistente revela bugs que o FPM escondia
Variáveis globais, singletons mutáveis, caches locais e serviços que guardam o usuário atual podem vazar informação entre requests. Conexões envelhecem, buffers crescem e bibliotecas que pressupõem um processo curto acumulam memória.
A documentação do worker mode pede que cada iteração seja encerrada corretamente e que recursos sejam liberados. Frameworks oferecem integrações para redefinir estado conhecido, mas código da aplicação e dependências continuam sob responsabilidade do time.
Um teste funcional curto pode passar mesmo com vazamento. A validação precisa manter o worker ativo, alternar usuários e tenants, provocar exceções e observar memória. Reinícios periódicos limitam o impacto, mas não substituem a correção da causa.
Essa é a principal barreira para bases antigas. O código não precisa se tornar stateless em sentido absoluto; precisa impedir que estado específico de uma request sobreviva sem intenção. Essa propriedade deve ser demonstrada.
O binário integrado simplifica e concentra
FrankenPHP usa Caddy como servidor web. Certificados, protocolos modernos, compressão, Early Hints, logs e métricas podem entrar no mesmo runtime. Em projetos pequenos, isso reduz arquivos e processos separados de Nginx, proxy e FPM.
Concentração também muda a operação. Atualizar o binário pode alterar servidor e PHP ao mesmo tempo. A imagem de container, módulos compilados e configuração de Caddy precisam de um processo de release claro. Uma stack com componentes separados permite atualizações independentes; uma stack integrada reduz pontos de configuração.
Nenhum modelo é sempre menor. A equipe deve comparar o que realmente mantém hoje. Se a plataforma já gerencia proxy, TLS e observabilidade, retirar Nginx talvez gere pouco benefício. Se cada serviço carrega configuração própria, o binário integrado pode remover trabalho recorrente.
A migração deve começar por um serviço representativo
O melhor piloto não é uma página vazia. Escolha um serviço com framework, banco, autenticação, filas relacionadas e carga conhecida. Execute o mesmo conjunto em FPM e worker mode. Meça throughput, percentis de latência, memória depois de milhares de requests, erros e tempo de deploy.
Inclua testes de isolamento. Alterne contas, idiomas e permissões. Verifique se um request com exceção contamina o seguinte. Force reconexão de banco e rotação de secrets. Essas situações dizem mais sobre prontidão que um pico de requests por segundo.
Também preserve uma rota de retorno. O valor do piloto está em aprender sem tornar o runtime uma decisão irreversível. Container e configuração devem permitir voltar ao FPM enquanto a equipe corrige dependências incompatíveis.
Apoio institucional reduz um risco, não todos
O envolvimento da PHP Foundation melhora manutenção, compatibilidade com novas versões e confiança no projeto. Ele não elimina os riscos particulares de cada aplicação nem define quando o worker mode compensa.
FrankenPHP merece avaliação porque muda simultaneamente desempenho e quantidade de infraestrutura. O teste deve tratar as duas dimensões. Uma aplicação pode ganhar velocidade e perder isolamento, ou simplificar deploy e aumentar o alcance de uma atualização ruim.
O runtime deixa de ser uma peça invisível quando o processo persiste. Equipes que medirem estado, memória e operação junto com throughput poderão decidir se a economia é real na própria carga.
