Como manter processos Node.js ativos no servidor

Um processo Node.js ativo é aquele que continua em execução enquanto a aplicação atende requisições, tarefas agendadas ou conexões com outros serviços. Em desenvolvimento, basta executar o comando no terminal. Em produção, however, isso costuma ser insuficiente, porque uma falha de código, uma reinicialização do servidor ou o encerramento da sessão podem interromper o serviço.

A solução mais segura combina um supervisor de processos, que reinicia a aplicação quando ela para, com mecanismos do sistema operacional para recuperar o processo depois de uma reinicialização. Neste guia, você vai entender as opções mais comuns, configurar o PM2 e o systemd, diagnosticar problemas e evitar decisões que comprometam a estabilidade da aplicação.

Este conteúdo tem caráter informativo. Decisões técnicas devem ser tomadas com profissional especializado.

O que é manter processos Node.js ativos

Node.js é o ambiente de execução do JavaScript no servidor. Quando você inicia uma aplicação com um comando como node app.js, o processo fica associado à sessão atual do terminal. Se a conexão SSH for encerrada, o servidor for reiniciado ou o processo encontrar um erro não tratado, a aplicação pode parar.

Um processo ativo deve continuar operando de forma previsível. Isso envolve três Requirements básicos:

• Disponibilidade, para que a aplicação responda durante falhas previsíveis e reinícios controlados.
• Recuperação, para que o processo volte a funcionar depois de uma interrupção.
• Observabilidade, para que você consiga identificar a causa da queda sem depender de suposições.

O supervisor de processos é o componente responsável por manter o Node.js em execução. Ele observa o processo, registra o estado e pode reiniciá-lo quando necessário. Em sistemas Linux, o systemd e o PM2 são alternativas frequentes. Em arquiteturas baseadas em contêineres, o Docker ou o Kubernetes geralmente cuidam da reinicialização do contêiner, enquanto o supervisor interno da aplicação pode ser evitado.

A escolha depende da infraestrutura, da forma de publicação do código e do nível de controle necessário. Não existe uma configuração universal que funcione igual em um VPS simples, uma hospedagem compartilhada e uma plataforma gerenciada de contêineres.

Opções para manter a aplicação em execução

systemd

O systemd é o sistema de inicialização e gerenciamento de serviços usado por grande parte das distribuições Linux modernas. Ele permite definir um serviço que inicia junto com a máquina, reinicia quando o processo falha e grava os registros em um sistema centralizado.

Para uma aplicação Node.js, o systemd costuma ser uma escolha nativa do servidor. Ele não exige a instalação de um gerenciador adicional e integra o serviço ao comando systemctl, utilizado para iniciar, parar, consultar e reiniciar unidades.

A principal vantagem é o controle direto do ciclo de vida da aplicação. A desvantagem aparece quando a equipe não conhece a criação de arquivos de unidade ou precisa de uma interface visual para acompanhar processos, uso de memória e reinícios.

PM2

O PM2 é um gerenciador de processos Node.js que funciona em Linux, macOS e Windows. Ele mantém aplicações em execução, oferece comandos para consultar logs, reiniciar serviços e limitar a memória consumida. Também pode ser configurado para iniciar junto com o sistema operacional.

O PM2 é útil quando o projeto usa Node.js de forma intensa ou quando a equipe quer uma interface administrativa mais simples. Uma limitação é que a configuração de inicialização no Linux pode variar conforme a versão e o método de instalação. Na prática, o ideal é seguir a documentação oficial do projeto e conferir o serviço gerado no sistema.

Contêineres

Contêineres empacotam a aplicação e suas dependências em um ambiente isolado. Quando o contêiner para, a plataforma pode criar outro contêiner com a mesma imagem. Docker Compose, Kubernetes e serviços de hospedagem gerenciada usam mecanismos parecidos.

Essa abordagem facilita a padronização entre ambientes, mas não elimina a necessidade de configurar reinícios, limites de recursos e verificações de saúde. Um contêiner que reinicia continuamente pode esconder um erro na aplicação, por isso o log e a saúde do serviço precisam fazer parte do projeto.

Comparativo entre systemd, PM2 e contêineres

A tabela mostra que não existe uma opção sem responsabilidade. O supervisor escolhe como reiniciar, mas a equipe ainda precisa definir limites, alertas e procedimentos para investigar falhas.

Configurando o PM2 em um servidor Linux

Antes de começar, confirme que o Node.js e o npm estão instalados. O comando node --version mostra a versão disponível e o comando npm --version exibe a versão do gerenciador de pacotes. Em um servidor compartilhado, a instalação pode exigir permissões adicionais ou o uso de um gerenciador de versões.

Instalação do gerenciador

Em projetos globally installed, o comando mais usado é:

npm install -g pm2

O prefixo global significa que o pacote fica disponível para o usuário em um diretório global do Node.js. Em servidores com controle estrito de permissões, pode ser necessário instalar com sudo, mas isso deve ser avaliado com cuidado. Executar comandos como root sem necessidade aumenta o impacto de eventuais erros.

Depois da instalação, verifique o gerenciador:

pm2 --version
pm2 list

Se o comando não for encontrado, verifique se o diretório global do npm está no PATH, que é a lista de pastas em que o sistema procura programas executáveis.

Inicialização da aplicação

Entre na pasta do projeto e execute:

pm2 start app.js --name minha-aplicacao

O nome facilitate a identificação do processo. Se a aplicação usa variáveis de ambiente, carregue um arquivo .env por meio do gerenciador de processos ou configure o serviço no servidor. Nunca versione esse arquivo em um repositório público.

Para acompanhar os registros:

pm2 logs minha-aplicacao
pm2 status

Para parar e iniciar novamente:

pm2 stop minha-aplicacao
pm2 restart minha-aplicacao

O comando reload pode ser mais adequado para aplicações que precisam drenar requisições antes de serem reiniciadas. Isso depende do comportamento da aplicação e da forma como as conexões são gerenciadas. Uma API com trabajos longos deve ser projetada para tolerar o encerramento gradual, em vez de depender de um reinício brusco.

Configuração de reinício

O PM2 pode reiniciar a aplicação quando ela falha. Também é possível definir um limite de reinícios para evitar ciclos intensos em caso de erro de configuração. Consulte a sintaxe da versão instalada antes de aplicar limites, pois as opções evoluem entre versões.

Um arquivo de configuração permite revisar opções como nome do script, ambiente, limite de memória e comportemento de reinício. Ele deve ser mantido no controle de versão quando não contiver segredos. Variáveis de ambiente e valores sensíveis precisam ficar fora do arquivo de configuração ou ser protegidos durante a publicação.

Configuração para iniciar com o servidor

O PM2 oferece o comando pm2 startup, que gera um serviço de inicialização para o sistema operacional. A documentação recomenda executar o comando exibido pelo próprio PM2 com permissões suficientes e, depois, salvar a lista de processos com pm2 save.

O procedimento exato pode depender da distribuição Linux. Após a configuração, reinicie o servidor em um horário controlado e verifique se a aplicação voltou. Testar de fato é mais confiável do que confiar apenas na mensagem de sucesso.

Configurando um serviço com systemd

O systemd é especialmente útil quando a aplicação é publicada em um VPS ou servidor dedicado com Linux. A ideia é criar uma unidade que informa ao sistema operacional qual comando inicia o Node.js, qual usuário executa o processo e como agir em caso de falha.

Criação do usuário e diretório

Evite executar a aplicação como root. Crie um usuário sem privilégios administrativos e uma pasta própria para o projeto. O exemplo abaixo usa nodeapp como usuário e /var/www/minha-app como diretório:

sudo useradd --system --create-home --shell /usr/sbin/nologin nodeapp
sudo mkdir -p /var/www/minha-app

A forma de copiar os arquivos varia conforme o deploy. Git, rsync ou uma ferramenta de publicação podem ser usados. Depois, ajuste a propriedade dos arquivos para o usuário do serviço, sem liberar permissões amplas sem necessidade.

Arquivo de unidade

Um arquivo pode ser criado em /etc/systemd/system/minha-app.service:

[Unit]
Description=Aplicacao Node.js
After=network.target

[Service]
Type=simple
User=nodeapp
Group=nodeapp
WorkingDirectory=/var/www/minha-app
Environment=NODE_ENV=production
EnvironmentFile=-/var/www/minha-app/.env
ExecStart=/usr/bin/node /var/www/minha-app/app.js
Restart=on-failure
RestartSec=5
TimeoutStopSec=30
KillSignal=SIGTERM

[Install]
WantedBy=multi-user.target

O ExecStart deve usar o caminho completo do Node.js instalado no servidor. Nem toda instalação coloca o executável em /usr/bin/node. Para descobrir o caminho, use which node. O EnvironmentFile carrega as variáveis do arquivo .env quando ele existe, por isso o prefixo - evita a falha de inicialização caso o arquivo ainda não esteja presente, embora a aplicação deva receber as variáveis obrigatórias de outra forma durante o deploy.

Ativação e diagnóstico

Após criar o arquivo, atualize o systemd:

sudo systemctl daemon-reload
sudo systemctl enable minha-app
sudo systemctl start minha-app
sudo systemctl status minha-app

Para acompanhar os logs em tempo real:

sudo journalctl -u minha-app -f

Para ver os últimos registros:

sudo journalctl -u minha-app -n 100 --no-pager

Para reiniciar depois de uma alteração no arquivo de unidade:

sudo systemctl restart minha-app

O daemon-reload informa o systemd que o arquivo mudou. Sem essa etapa, o serviço pode continuar usando a definição anterior.

Diagnosticando processos que param ou reiniciam

Quando a aplicação cai, a primeira tentativa costuma ser olhar apenas o erro final. Isso pode esconder a causa real. Uma investigação útil começa pelo histórico do serviço, pelo estado do processo e pela saúde da aplicação.

Verifique o estado do processo

Com systemd:

sudo systemctl status minha-app
sudo journalctl -u minha-app --since "30 minutes ago"

Com PM2:

pm2 status
pm2 logs minha-aplicacao --lines 100

O status mostra se o processo está ativo, parado, reiniciando ou com erro. Os logs revelam mensagens de inicialização, falhas de conexão, erros de sintaxe e motivos de encerramento.

Confirme porta e conectividade

Se a aplicação deveria escutar em uma porta, verifique se o processo realmente está escutando nela. O ss mostra sockets do sistema operacional:

ss -ltnp

Teste a resposta local com curl:

curl -i http://127.0.0.1:3000/health

Se o servidor remoto continua sem resposta, teste a rota local primeiro. Isso separa um problema da aplicação daquele relacionado ao proxy, firewall, DNS ou balanceador de carga.

Verifique recursos e dependências

Queda de memória, disco cheio e CPU sobrecarregada podem derrubar o processo. Verifique o uso de memória, a carga do sistema e o espaço disponível. Também confira banco de dados, cache, filas e serviços externos.

Uma falha de dependência não significa necessariamente que o código está quebrado. Um supervisor pode reiniciar a aplicação algumas vezes enquanto o banco ainda está fora do ar. Nesse cenário, reinícios agressivos geram logs ruidosos e não resolvem a causa.

Procure loops de reinício

Um loop de reinício normalmente aparece como vários reinícios em pouco tempo. As causas mais comuns incluem:

• variável de ambiente ausente;
• erro de sintaxe no código publicado;
• porta já ocupada por outro processo;
• dependência externa indisponível;
• falha na migração do banco de dados;
• permissões insuficientes para arquivos ou diretórios.

Não desabilite o supervisor para esconder o sintoma. O objetivo é fazer o processo permanecer ativo com uma configuração saudável, não apenas impedir que o sistema registre a falha.

Boas práticas para processos Node.js em produção

Registre logs de forma estruturada

O processo deve escrever nos streams padrão de entrada e saída, em vez de tentar gerenciar arquivos de log por conta própria. O systemd e o PM2 podem capturar esses fluxos e centralizá-los. Logs estruturados, com horário, nível, código da requisição e contexto da operação, ajudam a localizar falhas.

Evite registrar senhas, tokens, cookies ou dados pessoais. A LGPD e boas práticas de segurança exigem atenção especial ao tratar informações de usuários e dados de clientes.

Trate o encerramento com elegância

Ao receber SIGTERM, o processo deve parar de aceitar novas conexões, concluir ou cancelar tarefas de forma controlada e fechar recursos. Node.js oferece sinais do sistema e mecanismos de encerramento para construir esse comportamento.

Para tarefas demoradas, use filas e de repetição com limite. Para tarefas recorrentes, evite que cada instância do aplicativo execute o mesmo agendamento sem coordenação. Em ambientes com várias instâncias, locks ou um serviço dedicado de agendamento são alternativas mais previsíveis.

Mantenha dependências e runtime atualizados

Atualize o Node.js, as dependências do projeto e o sistema operacional com procedimento de teste. Uma aplicação que funciona apenas na máquina local pode falhar no servidor por diferenças de versão, variáveis de ambiente ou bibliotecas nativas.

Mantenha o package-lock.json ou outro arquivo de lock correspondente versionado. Durante o deploy, use a instalação reprodutível prevista pelo projeto e valide a aplicação antes de expor a nova versão.

Configure limites e alertas

Limites de memória, tempo de resposta e quantidade de reinícios ajudam a evitar que uma falha consuma todo o servidor. Os limites devem vir da observabilidade real da aplicação. Um limite muito baixo pode reiniciar um processo saudável; um limite muito alto pode deixar o servidor sem memória.

Crie alertas para sinais relevantes:

• aplicação fora do ar por mais de alguns minutos;
• reinícios repetidos;
• aumento da latência;
• uso excessivo de memória ou CPU;
• fila de mensagens acumulando;
• certificado digital próximo do vencimento.

Teste a recuperação

Um supervisor configurado não deve ser testado somente em teoria. Em uma janela controlada, reinicie o servidor e confirme o retorno da aplicação. Verifique o proxy, as filas, o DNS e as integrações externas. Em alguns casos, é útil simular o encerramento do processo para confirmar que o mecanismo de reinício funciona.

systemd, PM2 ou contêineres, como decidir?

A decisão mais simples costuma começar pelo ambiente. Se o projeto roda em uma máquina Linux e a equipe quer usar os recursos do sistema operacional, o systemd é uma base sólida. Se a equipe quer administrar vários processos Node.js com comandos rápidos e uma interface conhecida, o PM2 reduz a curva de aprendizado.

Os contêineres fazem sentido quando a aplicação já precisa de isolamento, publicação por imagem ou consistência entre ambientes. Eles não devem ser adotados somente porque parecem mais modernos. Uma imagem de contêiner mal configurada pode reiniciar indefinidamente, consumir recursos e dificultar o diagnóstico.

Uma comparação prática fica assim:

Na prática, eu evitaria misturar dois supervisores para o mesmo processo sem necessidade. Por exemplo, um PM2 dentro de um serviço systemd pode ser útil em LEGADO, mas aumenta a quantidade de camadas para diagnosticar. Escolha uma camada principal e documente a responsabilidade de cada parte.

Cuidados com hospedagem compartilhada e provedores de aplicação

Nem todo provedor permite instalar systemd ou executar PM2 com permissões de inicialização. Em hospedagem compartilhada, o painel pode oferecer processos Node.js persistentes, cron jobs ou comandos de reinício. Verifique as regras do contrato antes de escolher a arquitetura.

Em plataformas gerenciadas, como um serviço que já faz build e release do código, o provedor pode cuidar do reinício. Ainda assim, é preciso entender os limites da plataforma, o mecanismo de shutdown e o tratamento de falhas. O procedimento de deploy precisa comunicar à plataforma como iniciar o processo e qual rota verifica sua saúde.

Verifique também se o plano de hospedagem permite manter uma aplicação ativa continuamente. Alguns serviços são voltados a sites e APIs e cobram pelo tempo de execução ou pelo consumo de recursos. O valor e as regras mudam, portanto consulte a documentação atual do provedor.

Checklist de manutenção de processos Node.js

Antes de colocar a aplicação em produção, confirme:

• O processo inicia com um comando documentado.
• O servidor reinicia a aplicação depois de uma falha.
• A aplicação também retorna após uma reinicialização do servidor.
• Os logs são acessíveis e não contêm segredos.
• O encerramento ocorre de forma graciosa.
• Existe um limite para reinícios repetidos.
• Há alerta para indisponibilidade e consumo excessivo de recursos.
• O deploy foi testado no mesmo tipo de ambiente da produção.
• As dependências externas e a rota de saúde foram verificadas.
• O arquivo de configuração está versionado sem credenciais.

Esse checklist não substitui o teste. Ele ajuda a evitar que uma configuração importante dependa apenas da memória de alguém.

Perguntas Frequentes (FAQ)

Por que meu processo Node.js para ao fechar o terminal SSH?

Um processo iniciado diretamente no terminal pode receber o encerramento da sessão e deixar de acompanhar o servidor. O systemd, o PM2 com inicialização do sistema ou um contêiner gerenciado são formas de manter o serviço disponível fora do terminal.

O PM2 ou o systemd reinicia uma aplicação depois de uma falha?

Sim, quando a política de reinício está configurada. O systemd pode usar Restart=on-failure, e o PM2 permite definir o comportamento de reinício e limites. A aplicação também precisa registrar a causa da falha, porque reiniciar não corrige erros de configuração.

Como descubro por que meu processo Node.js caiu?

Use journalctl para consultar o serviço do systemd ou pm2 logs para ver os registros do PM2. Confira também porta, arquivos de configuração, variáveis de ambiente, memória e dependências externas. O histórico Usually mostra a exceção ou o sinal que encerrou o processo.

É seguro usar npm install -g pm2 no servidor?

O comando instala o PM2 no diretório global do npm. Em servidores compartilhados, confirme as permissões e o diretório de instalação. Quando possível, prefira um usuário específico e evite executar comandos administrativos sem necessidade.

Contêiner substitui systemd ou PM2?

Não necessariamente. O contêiner é uma forma de empacotar e executar a aplicação. O ambiente ainda pode usar um serviço do sistema ou um orquestrador para reiniciar contêineres. Em uma aplicação simples, a equipe pode manter apenas o Docker com política de reinício, mas precisa configurar logs e verificações de saúde.

Como fazer a aplicação voltar depois de reiniciar o servidor?

Crie um serviço do systemd habilitado para inicialização, configure o PM2 para iniciar com o sistema ou publique o contêiner em uma plataforma que aplique sua política de reinício. Depois, reinicie o servidor em uma janela de teste e confirme a aplicação, o proxy e as integrações.

Conclusão

Manter processos Node.js ativos é uma questão de desenho da operação, não apenas de executar node app.js. O processo precisa de um supervisor, política de reinício, logs, limites e um teste de recuperação depois da queda.

O systemd é uma escolha natural em servidores Linux. O PM2 facilita o gerenciamento de aplicações Node.js e oferece uma experiência familiar. Contêineres ajudam quando a publicação por imagem e o isolamento fazem parte da estratégia. O importante é definir quem inicia, quem reinicia, quem observa e quem responde quando algo falha.

Se você precisa de ajuda para colocar isso em prática, a Baita Site tem uma equipe especializada em sites, e-commerce, sistemas e inteligência artificial, com domínio total de WordPress. Fale com a gente e veja como podemos acelerar o seu projeto.

Referências consultadas

• Documentação oficial do systemd: systemd.service, referência para unidades de serviço, reinício e controle de processos.
• Documentação oficial do PM2: Getting Started, guia de instalação, comandos básicos e inicialização do gerenciador.
• Documentação oficial do PM2: Startup, instruções para iniciar o PM2 junto com o sistema operacional.
• Documentação oficial do Node.js: Testes com Node.js, referência oficial sobre recursos de teste do runtime e integração com a aplicação.
• Documentação oficial do Docker: Configure restart policies, explicação das políticas de reinício de contêineres.
• Guia da Alibaba Cloud: Configure a política de reinício de uma instância, material complementar sobre manutenção de serviços em servidores Linux.