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 dentro do container do site. 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 dentro do container 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 Supervisor (o gerenciador de processos dentro do container) inicia cada daemon junto com o container, 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.

#Criar um daemon

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

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

Toda operação que muda a configuração de daemons — criar, editar, ligar/desligar ou remover — recria o container do site para aplicar a nova configuração do Supervisor. É 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 servidor estiver rodando uma imagem de runtime anterior ao suporte a daemons, a página exibe um aviso âmbar — os daemons passam a funcionar após a próxima atualização de imagem daquele 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.

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 container, 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 dentro do container do 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 container e recria os processos
• Terminal — inspecionar processos rodando direto no container ou no servidor
• Modo de Pânico — tirar um site do ar sem parar os containers (nem os daemons)