Cron jobs e workers em segundo plano sem um dyno separado

A abordagem usual de PaaS trata um cron job e um worker em segundo plano como produtos separados da sua aplicação web — uma aba diferente no painel, às vezes uma linha de preço diferente. Eles não são de fato coisas separadas. São processos da mesma aplicação, que é a parte que vale levar a sério em vez de tratar como um detalhe técnico.

O que a aba Workers realmente oferece

Ela só mostra job runners que consegue de fato encontrar no seu repositório — não uma lista genérica que você configura do zero: processos declarados no Procfile/Procfile.dev/app.json, ou runners que já estão nas suas dependências (Sidekiq, Solid Queue, GoodJob, Resque, Celery, RQ, a queue do Laravel ou o Horizon, um script npm run worker). Adicione um com um clique, ou aponte você mesmo pra qualquer comando de longa duração se nada for detectado. Cada worker roda a própria imagem da aplicação e escala de forma independente do processo web.

Essa última parte importa mais do que parece: um worker não é um deploy menor e separado que vai saindo de sincronia com o web — é o mesmo build, o mesmo release, o mesmo rollback, só um tipo de processo diferente escalado com o próprio número.

Workers que também dormem

Uma aplicação só de worker — sem processo web nenhum, só um consumidor de fila — ainda pode usar Sleep when idle em Settings → General. Ela para quando a CPU reportada fica ociosa por tempo suficiente, e a Railyard a desperta no próprio horário especificamente pra drenar qualquer coisa que esteja na fila, e depois deixa ela voltar a dormir. O padrão que normalmente é montado manualmente (um cron job que desperta um worker com um ping, uma lambda que checa a profundidade de uma fila) é só uma caixinha de marcar aqui.

Cron, separadamente

Cron roda um comando na própria imagem da aplicação num horário agendado (0 3 * * *), com o histórico de execuções mantido — sem container separado, sem imagem separada pra manter sincronizada com o código real da aplicação, porque é literalmente a mesma imagem que tudo mais roda.

Por que vale a pena notar isso

A alternativa — um cron job definido em algum lugar fora do pipeline de deploy da aplicação, apontando pra uma imagem antiga porque ninguém atualizou quando a aplicação fez deploy da última vez — é um modo de falha específico e comum em plataformas que tratam trabalho agendado como cidadão de segunda classe. Rodar cron e workers como tipos de processo de uma aplicação só significa que um deploy que arruma a aplicação arruma os jobs agendados dela e os workers dela ao mesmo tempo, por construção, não por alguém lembrar.

Referência completa: Workers and scheduled jobs.