Bun, Node.js e PM2 em produção: quando usar, quando evitar e trade-offs arquiteturais

Ao adotar runtimes modernos como o Bun em conjunto com o Node.js tradicional, uma dúvida frequente surge na arquitetura: se já há o Bun e o Node.js configurados, ainda é preciso manter o PM2 em produção?

A resposta depende diretamente da sua camada de orquestração (VPS direta vs. containers) e de como cada runtime lida com processos e sockets de rede no Linux.

Abaixo, analiso as diferenças de execução, os testes de diagnóstico no sistema operacional e a matriz de decisão para cada ambiente.

1. Process managers vs. capacidades nativas dos runtimes#

Para posicionar cada ferramenta, é necessário entender o ciclo de vida de processos no Node.js e no Bun:

Node.js e o modelo de cluster#

O Node.js executa o código JavaScript em uma única thread principal (Event Loop V8). Para aproveitar múltiplos núcleos de CPU em um servidor, o runtime depende de múltiplos processos paralelos via módulo nativo cluster.

O PM2 resolve isso em servidores tradicionais através do modo cluster (-i max), criando um processo mestre que gerencia os workers e distribui conexões via round-robin no kernel usando SO_REUSEPORT ou IPC.

Bun e a concorrência nativa#

O Bun, construído em Zig sobre a engine JavaScriptCore (JSC), possui um servidor HTTP nativo (Bun.serve) de altíssimo desempenho.

No entanto, o Bun não replica o módulo cluster do Node.js da forma como o PM2 consome. Para escalar o Bun em múltiplos núcleos sem um orquestrador externo, a abordagem nativa utiliza instâncias paralelas escutando no mesmo socket através da opção reusePort: true:

Bun.serve({
  port: 3000,
  reusePort: true,
  fetch(req) {
    return new Response("Bun Worker ativo");
  },
});

2. Por que o PM2 ainda é relevante em VPS e bare metal?#

Fora de ambientes conteinerizados, o runtime isolado não gerencia a resiliência no nível do sistema operacional:

A. Watchdog e auto-recuperação de processos#

Se uma aplicação Node.js sofrer estouro de Heap Memory ou o binário do Bun encontrar uma falha fatal de segmentação (Segmentation Fault), o processo encerra. O PM2 atua como watchdog: intercepta o sinal de término e reinicia o serviço instantaneamente sem necessidade de intervenção manual.

B. Persistência pós-reboot com systemd#

O fluxo do PM2 simplifica a inicialização no boot do Linux:

pm2 save
pm2 startup

O comando gera e registra os serviços no Systemd automaticamente; assim, as aplicações retornam após manutenções ou reinicializações do servidor.

C. Rotação automática de logs#

Redirecionar saídas com >> /var/log/app.log rapidamente causa esgotamento de espaço e inodes em disco se não houver um logrotate dedicado. O módulo pm2-logrotate resolve a rotação e retenção de stdout e stderr nativamente.

3. Quando o PM2 se torna um anti-padrão?#

1. Ambientes com Docker e Kubernetes:

Em containers, o PM2 é prejudicial. O daemon do Docker espera monitorar o processo da aplicação como PID 1. O PM2 dentro do container mascara crashes, impedindo que o Kubernetes detecte a instabilidade do container e reinicie a réplica com falha.

1. Ambientes de desenvolvimento:

As flags nativas --watch e --hot do Bun entregam recarregamento instantâneo superior ao pm2-dev.

4. Diagnóstico de processos e limites no Linux#

Para inspecionar como os processos do Bun e Node.js interagem com o sistema operacional:

Rastrear chamadas de rede e forks com strace#

Para verificar se o processo está gerando erros de concorrência de portas (EADDRINUSE) ao escalar instâncias:

strace -f -e trace=network,process -p <PID>

Inspecionar sockets ativos com lsof#

lsof -nP -p <PID> | grep LISTEN

Limite de descritores de arquivo (limits.conf)#

Como o Bun atinge taxas elevadas de requisições concorrentes por segundo, o limite de arquivos abertos (nofile) configurado para o usuário pode ser atingido rapidamente. Ajuste /etc/security/limits.conf:

usuario soft nofile 65535
usuario hard nofile 65535

Diretrizes práticas para a escolha da stack#

Em servidores virtuais ou dedicados sem orquestradores de containers, o PM2 continua sendo uma camada indispensável de proteção para manter alta disponibilidade, gerenciar logs e garantir recuperação automática.

Veja também

Desenvolvimento Atualizando o Vite no Laravel: do inotify do kernel ao manifest.json

Desenvolvimento Do erro de módulo ao Bun-only: o guia real de troubleshooting do prisma no Linux

Desenvolvimento Node.js para Bun: transição com benchmark real, compatibilidade e rollback

Este post está licenciado sob CC BY-NC.