Comparativo: Nginx Unit vs PHP‑FPM para executar aplicações PHP monolito em containers

Por Kevin Marcondes · Publicado em 28/10/2026 · 8 min de leitura

Contêineres marítimos azuis empilhados contra um céu limpo — Representa topologias e deploys em ambientes conteinerizados. Foto: Jan van der Wolf / Pexels

Este comparativo Nginx Unit vs PHP‑FPM para executar aplicações PHP monolito em containers explica diferenças reais de arquitetura, performance, operação e segurança. Você verá critérios práticos para escolher cada um, impactos no deploy e na observabilidade, e caminhos de migração com baixo risco para seu ambiente conteinerizado.

Arquitetura e modelo de processos: como cada um trabalha

Nginx Unit é um servidor de aplicações com roteamento embutido e API de configuração dinâmica. Ele recebe HTTP diretamente e gerencia processos da aplicação PHP internamente, sem precisar de um Nginx separado para o dinâmico.

PHP‑FPM é um gerenciador de processos FastCGI para PHP. Ele exige um servidor web na frente (como Nginx ou Traefik) para receber HTTP, servir estáticos e fazer proxy para o pool FPM via socket ou TCP.

Em containers, o padrão comum com FPM é ter dois containers: um para o web server e outro para o PHP‑FPM. Com Unit, costuma-se usar um único container para servir HTTP e PHP; ainda assim, você pode colocá-lo atrás de um proxy reverso se quiser recursos adicionais.

Ambos adotam múltiplos workers para concorrência. A eficiência depende de OPcache, I/O, número de workers e do perfil de carga.

Unit: servidor de aplicações com HTTP/TLS e API de config.
PHP‑FPM: precisa de web server à frente (Nginx/Traefik).
Containers: Unit pode simplificar a topologia; FPM separa responsabilidades.

Performance e latência: o que influencia de verdade

Sem microbenchmarks padronizados, não há um vencedor universal. Em workloads de monólitos PHP, latência e throughput tendem a depender mais de OPcache, banco de dados e I/O do que do runtime em si.

Nginx Unit elimina uma hop FastCGI e pode reduzir cópia de dados em alguns cenários. PHP‑FPM, quando bem ajustado, entrega throughput estável e previsível por meio do dimensionamento dos pools.

Em ambos, aqueça o OPcache e ajuste o número de workers conforme CPU e memória do container. Observe p95/p99 e não apenas média de latência.

Aqueça e valide OPcache antes de testes.
Meça p95/p99 sob carga representativa.
Tuning de workers conforme CPU/memória do container.
Evite I/O síncrono desnecessário em requests.

Configuração, DX e reconfiguração sem downtime

Nginx Unit oferece uma API REST para configurar rotas, listeners e aplicações. Mudanças são aplicadas de forma dinâmica, sem reload de processo, o que facilita ajustes finos e automações em ambiente de containers.

No PHP‑FPM, mudanças no pool ou no php.ini exigem reload do serviço; é possível fazê-lo de forma graciosa, mas há um passo operacional extra. Em troca, a configuração é simples e amplamente conhecida.

Se você usa um proxy reverso dedicado, compare opções em Traefik e Nginx conforme seu cenário em Traefik vs Nginx como reverse proxy.

Unit: alterações via API, atômicas e dinâmicas.
FPM: reload gracioso do master process para aplicar configs.
Automação: Unit facilita mudanças frequentes sob orquestração.

Observabilidade, logs e métricas

Com Unit, você tem logs estruturados e uma API de status. Integrar com Prometheus costuma requerer um exporter ou coleta via sidecar; padronize o formato de logs para seu stack.

No PHP‑FPM, a página /status e o slowlog ajudam no diagnóstico. Há exporters maduros para Prometheus e Grafana. Veja um passo a passo de exposição de métricas em expor métricas do PHP‑FPM para Prometheus.

Para logs de aplicação, centralize e correlacione com seu proxy reverso. Para traços, o impacto é semelhante em ambos os runtimes; foque em instrumentação do código.

FPM: status page, slowlog, exporters amplamente usados.
Unit: status API e logs estruturados; use exporter/sidecar.
Padronize correlação de request ID entre proxy e app.

Segurança e isolamento em containers

Ambos funcionam bem como usuário não-root dentro do container e podem isolar processos por app/pool. Em containers, chroot adicionais costumam trazer pouco ganho além do isolamento já fornecido pelo runtime do container.

Nginx Unit pode terminar TLS diretamente. Com PHP‑FPM, o TLS fica no servidor/proxy à frente. Em ambos, mantenha superfícies mínimas na imagem e atualize dependências do PHP com frequência.

Ajuste permissões de diretórios de upload/cache e restrinja extensões executáveis no FPM. No Unit, isole rotas administrativas e minimize superfícies de API de configuração.

Execute como usuário não-root.
Minimize pacotes e módulos na imagem.
Separe volumes de upload e cache do código.

Quando escolher cada um: critérios práticos

Use critérios de operação, time e requisitos não funcionais. Abaixo, sinais de escolha mais segura em cada direção.

Prefira Nginx Unit se: quer configuração dinâmica via API; deseja consolidar web server e PHP no mesmo container; precisa de rotas e listeners mutáveis sem reload.
Prefira PHP‑FPM se: sua equipe já domina Nginx+FPM; precisa de integrações maduras de métricas/slowlog; quer previsibilidade de tuning com pools e processos.
Consideração comum: separe estáticos em um CDN. Para deploy sem downtime, use rotas por versão ou trocas atômicas de containers, como em deploy blue-green com Docker Compose.
Se notar crescimento de memória no FPM, investigue padrões de alocação e OPcache. Veja dicas em vazamento de memória no PHP‑FPM: como resolver.

Tabela comparativa rápida

Resumo lado a lado de pontos de decisão frequentes.

Aspecto	Nginx Unit	PHP‑FPM	Comentário
Arquitetura	Servidor de aplicações com HTTP/TLS e API	Gerenciador FastCGI; precisa de web server/proxy	Topologias diferentes; ambos estáveis em produção
Reconfiguração	Dinâmica via API, sem reload	Reload gracioso do serviço	Unit favorece mudanças frequentes
Deploy sem downtime	Rotas/versionamento configuráveis na API	Troca de containers e reloads graciosos	Blue/Green funciona bem nos dois
Métricas/healthchecks	Status API; precisa de exporter	/status, slowlog e exporters consolidados	Ecosistema de observabilidade do FPM é amplo
Logs	Estruturados; formato configurável	Access/error logs via web server + FPM slowlog	Padronize correlação entre camadas
TLS	Pode terminar TLS nativamente	Terminação no proxy/web server	Em containers, TLS no proxy é comum
Consumo de memória	Processos por app; footprint enxuto	Pools por worker; footprint previsível	Depende de OPcache e workers
Throughput/latência	Competitivo; elimina hop FastCGI	Muito competitivo quando bem ajustado	Perfil de carga e I/O ditam o resultado
Múltiplas versões PHP	Por imagem/binários instalados	Por pools/instalação paralela	Em containers, isole por imagem
Complexidade operacional	Menos peças quando usado sozinho	Separação clara de responsabilidades	Escolha conforme maturidade do time

Caminho de migração e validação de risco baixo

Para testar Nginx Unit, suba um ambiente paralelo apontando para o mesmo banco e storage de staging. Replique variáveis de ambiente e aquecimento do OPcache. Compare p95/p99 e erros.

Implemente validações de rota e headers para redirecionar apenas uma fração do tráfego. Estratégias de canary ou blue/green em containers reduzem riscos sem exigir mudanças no aplicativo.

Documente rollback e mantenha o pipeline reproduzível. Veja também critérios de proxy reverso em Traefik vs Nginx como reverse proxy.

Teste paralelo com dados de staging representativos.
Aqueça OPcache e rode testes de carga controlados.
Planeje rollback simples: trocar tag de imagem ou rota.

Notas técnicas úteis e referências oficiais

Para ajustes finos do PHP‑FPM (pools, pm, slowlog e status), consulte a documentação oficial. Para desempenho, revise a configuração do OPcache e monitore acertos/invalidations sob carga.

PHP‑FPM: configuração e status page em php.net.
OPcache: parâmetros e boas práticas na documentação oficial.

Perguntas frequentes

Nginx Unit é sempre mais rápido que PHP‑FPM?

Não há um vencedor universal. O desempenho depende do seu código, OPcache, I/O e tuning de workers. Meça em staging com tráfego representativo e compare p95/p99, não apenas médias.

Consigo usar Nginx ou Traefik na frente do Nginx Unit?

Sim. Embora o Unit possa atender HTTP/TLS diretamente, muitas equipes preferem um proxy reverso dedicado para centralizar TLS, compressão e roteamento entre serviços.

Como monitorar PHP‑FPM em produção?

Ative a página /status, o slowlog e colete métricas com um exporter para Prometheus. Padronize rótulos e correlação com o proxy reverso. Há um passo a passo em nossa página de métricas do FPM.

Migrar para Unit exige mudar meu código PHP?

Na maioria dos monólitos, não. A aplicação continua sendo PHP. Ajustes costumam ficar na camada de configuração do servidor e de caminhos/rotas. Teste integrações com upload, cache e headers.

Qual é o melhor para deploy sem downtime em containers?

Ambos suportam bem blue/green e canary. Com Unit, você pode ajustar rotas via API. Com FPM, a troca atômica de containers e reload gracioso do web server são estratégias consolidadas.

O OPcache funciona igual nos dois?

Sim. OPcache é um componente do PHP, não do runtime web. Ajuste parâmetros como memory_consumption e validade de cache e verifique métricas de acerto sob carga.

Quer validar a melhor opção para o seu monólito PHP em containers?

Converse sobre sua arquitetura, métricas atuais e requisitos. Podemos montar um plano de teste com cenários de carga, critérios de rollback e estimativa de esforço para migração ou tuning.

Falar sobre sua arquitetura PHP