Processos

Workers de longa duração e tarefas agendadas vivem no seu repositório — não há criação nem escalonamento pelo dashboard ou pela API.

1. Exemplo completo

Dois arquivos, prontos para copiar. Processos de longa duração vão no Procfile; tarefas agendadas vão no .jatai.yml.

Procfile

# Procfile — processos de longa duração
worker: bin/jobs

.jatai.yml

processes:
  worker:
    instances: 2

cron:
  - name: relatorio-diario
    command: bin/rails prospectos:daily_report
    every: daily
    at: "06:00"

Dica: nada disso precisa existir antes do primeiro deploy. Faça jatai up com os dois arquivos no repositório e a aba Processos é populada automaticamente a partir do deploy.

2. O que aparece na aba Processos depois do deploy

A aba Processos do app é somente leitura: mostra origem, custo e estado de cada processo. Nada é criado, escalado ou removido por ali nem pela API — tudo vem do deploy do seu repositório.

Nome Origem Tipo Schedule / Instâncias Custo mensal Deploy
worker Procfile Worker 2 instâncias R$ 118,00/mês Deployado
relatorio-diario .jatai.yml Cron diariamente às 06:00 R$ 0,08 (acumulado no mês) Deployado

Exemplo com o Hex Escala 1: cada réplica de worker custa um Hex inteiro, R$ 59,00/mês — o mesmo degrau que o web. O cron do exemplo somou cerca de 1 hora de execução no mês; esse valor é acumulado a cada execução, não uma estimativa fixa.

3. Referência de campos

O cron do .jatai.yml não usa sintaxe cron. every aceita exatamente três valores:

every at Comportamento
10min não aceita at executa a cada 10 minutos — a menor frequência possível na plataforma
hourly "MM" (padrão "00") executa uma vez por hora, no minuto informado
daily "HH:MM" (obrigatório) executa uma vez por dia, no horário informado

Horários são interpretados no fuso America/Sao_Paulo. Não existe sintaxe cron (* * * * *) e não há como expressar nada mais frequente que 10 minutos — isso é proposital: quem precisa de mais frequência quer um worker no Procfile, não um cron.

Cobrança: declarar um cron é grátis. Cobra-se apenas pelo tempo em que ele de fato executou, na mesma taxa por minuto do worker do Hex do app. Um Hex é um Hex: a réplica de worker custa o mesmo que a do web — Hex Base R$ 29, Hex Escala 1 R$ 59, Hex Escala 2 R$ 119 por réplica/mês.

As linhas web:, release: e console: no Procfile são ignoradas — a plataforma já tem mecanismo próprio para cada uma. O log de deploy avisa quando alguma delas aparece, para você saber que aquela linha não fez nada.

4. Por stack

Rails

Antes de declarar um segundo worker só para separar filas, prefira várias filas dentro do mesmo processo: o Solid Queue já suporta isso nativamente em config/queue.yml, com um único supervisor coordenando vários workers internos.

production:
  dispatchers:
    - polling_interval: 1
      batch_size: 500
  workers:
    - queues: [ default, mailers ]
      threads: 3
      processes: 1
    - queues: [ relatorios ]
      threads: 2
      processes: 1

Um worker: bin/jobs no Procfile já sobe esse supervisor único com todas as filas do queue.yml. Só use um segundo processo/pod quando uma fila específica precisar de isolamento de recursos que o queue.yml não resolve.

Laravel

O agendador do Laravel roda como worker, não como cron. Declare schedule:work no Procfile — ele fica de pé e dispara as tarefas do seu Schedule internamente:

# Procfile
worker: php artisan schedule:work

Nunca declare um cron de minuto em minuto chamando schedule:run — não existe sintaxe cron no .jatai.yml e o formato não aceita frequência abaixo de 10 minutos, então essa tentativa não roda como o tutorial padrão do Laravel sugere. Isso não é uma limitação a contornar: schedule:work como worker é o jeito certo aqui, sem gerar um pod novo a cada minuto.

Node

Filas como bullmq, bull ou agenda precisam do próprio processo consumidor rodando continuamente — declare-as como worker, nunca dentro do processo web:

# Procfile
worker: node worker.js

O worker.js é o arquivo que instancia o Worker do bullmq/bull ou o processador do agenda e fica em loop consumindo a fila — o mesmo processo pode consumir várias filas, uma por Worker instanciado.

Próximos passos