Daemons e Workers

Toda aplicação real precisa de algo rodando o tempo todo, além do processo web: um consumidor de fila, um servidor de WebSocket, um worker em background. O PrimeForge cobre isso de duas formas complementares. Os Daemons deixam você definir qualquer processo supervisionado que o painel mantém vivo no ambiente do site, como uma unidade systemd dedicada. O escalonamento de workers aumenta o número de processos que consomem a sua fila (incluindo Horizon) em um site não balanceado. Esta página explica cada um e quando usar cada abordagem.

Daemons

Daemons são processos de longa duração que o PrimeForge mantém vivos no ambiente do seu site — consumidores de fila com flags específicas, servidores de WebSocket, workers em background, qualquer coisa que a sua aplicação precise rodando 24 horas por dia. O systemd (o gerenciador de processos do host) inicia cada daemon como uma unidade dedicada, o reinicia caso ele encerre e mostra o estado atual de cada um.

Você gerencia os daemons em Site → Daemons. A página não está disponível para sites do tipo HTML Estático, que não têm um runtime capaz de supervisionar processos.

Página de Daemons de um site, com a lista de processos supervisionados

Criar um daemon

Ao adicionar ou editar um daemon, você preenche estes campos:

Campo Observações
Rótulo (Label) Normalizado para um identificador em minúsculas (letras, números e hífens — até 32 caracteres).
Comando Qualquer binário disponível no servidor. Roda como o usuário Linux dedicado do site e reinicia sozinho se encerrar. É executado diretamente, não por um shell — para usar pipes, && ou expansão de variáveis, envolva em sh -c "seu comando".
Diretório Diretório de trabalho opcional, relativo à raiz da aplicação.
Processos Quantas cópias idênticas o systemd mantém rodando (de 1 a 3).

Você pode ter até 5 daemons por site. A tabela mostra um selo de status ao vivo para cada um (Rodando / Parado / Com falha…) e uma ação Reiniciar por daemon, que executa o comando via systemctl no servidor.

Toda operação que muda a configuração de daemons — criar, editar, ligar/desligar ou remover — re-renderiza as unidades systemd do site e as recarrega (daemon-reload + restart) para aplicar a nova configuração. É uma reinicialização rápida, e o modal de confirmação avisa antes.

Exemplos de comandos

php artisan queue:work redis --queue=payments --timeout=300
node websocket-server.js
sh -c "python worker.py >> storage/logs/worker.log 2>&1"

Repare no último exemplo: como o comando é executado diretamente (sem shell), qualquer redirecionamento (>>), pipe (|) ou encadeamento (&&) precisa ser envolvido em sh -c "...".

Se o agente daquele servidor for anterior ao suporte a daemons, a página exibe um aviso âmbar — os daemons passam a funcionar após a próxima atualização do agente do servidor.

Escalonamento de workers

Para sites Laravel que consomem uma fila (com ou sem Horizon), você pode ajustar quantos processos worker ficam consumindo os jobs. Mais workers significam mais jobs processados em paralelo — útil quando a fila acumula em horários de pico ou quando um job demorado segura os demais.

Você faz esse ajuste pelas configurações do site, no modal de escalonamento de workers.

Modal de escalonamento de workers de fila

Aumente o número de processos quando a sua fila estiver acumulando trabalho e o servidor tiver folga de CPU e memória. Cada worker adicional consome recursos do servidor, então acompanhe o uso em Monitoramento do servidor depois de escalar e não suba mais processos do que o servidor aguenta.

Este escalonamento se aplica a sites que rodam em uma única instância (não balanceados). Ele muda a quantidade de processos de fila do próprio site — não é o mesmo que rodar o site em vários servidores.

Daemons ou workers — qual usar?

As duas ferramentas mantêm processos vivos, mas resolvem problemas diferentes:

  • Use o escalonamento de workers quando você só quer mais capacidade para a fila padrão do Laravel/Horizon. É o caminho direto para processar mais jobs por segundo, sem escrever comando nenhum.
  • Use um daemon quando você precisa de um processo personalizado que o painel não gerencia por padrão: um queue:work apontando para uma fila específica com flags próprias, um servidor de WebSocket próprio, um worker escrito em outra linguagem, um consumidor de eventos. Você controla o comando exato, o diretório e a quantidade de cópias.

Na prática, os dois convivem: você escala os workers da fila principal pelo modal de escalonamento e adiciona daemons para os processos especializados que a sua aplicação tem além disso.

Próximos passos

  • Deploys e Rollback — como o código chega ao servidor e reinicia os processos
  • Terminal — inspecionar processos rodando direto no servidor
  • Modo de Pânico — tirar um site do ar sem parar os processos do site (nem os daemons)