Cron jobs y workers en segundo plano sin un dyno aparte
El enfoque habitual de los PaaS trata un cron job y un worker en segundo plano como productos separados de tu app web —una pestaña distinta en el panel, a veces una línea de precio distinta. En realidad no son cosas separadas. Son procesos de la misma app, y eso es justo lo que vale la pena tomarse en serio en vez de tratarlo como un detalle técnico.
Qué ofrece realmente la pestaña Workers
Solo muestra ejecutores de jobs que puede encontrar de verdad en tu repositorio —no una lista genérica que configuras desde cero: procesos declarados en Procfile/Procfile.dev/app.json, o ejecutores que ya están en tus dependencias (Sidekiq, Solid Queue, GoodJob, Resque, Celery, RQ, la cola de Laravel o Horizon, un script npm run worker). Agrega uno con un clic, o apunta tú mismo a cualquier comando de larga duración si no se detecta ninguno. Cada worker corre la misma imagen de la app y escala de forma independiente del proceso web.
Esa última parte importa más de lo que suena: un worker no es un despliegue más chico y separado que se desincroniza del web con el tiempo —es el mismo build, el mismo release, el mismo rollback, solo un tipo de proceso distinto que escala con su propio número.
Los workers también se duermen
Una app que solo tiene worker —sin proceso web alguno, solo un consumidor de cola— también puede usar Dormir si está inactivo en Settings → General. Se detiene en cuanto su CPU reportada lleva suficiente tiempo inactiva, y Railyard lo despierta con su propio horario específicamente para vaciar lo que haya en cola, y después lo deja volver a dormir. El patrón que normalmente hay que armar a mano (un cron job que le hace ping a un worker para despertarlo, una lambda que revisa la profundidad de una cola) aquí es solo una casilla.
Cron, por separado
Cron corre un comando en la misma imagen de la app según un horario (0 3 * * *), con historial de ejecuciones guardado —sin contenedor aparte, sin imagen separada que mantener sincronizada con el código real de la app, porque es literalmente la misma imagen con la que corre todo lo demás.
Por qué esto vale la pena notarlo
La alternativa —un cron job definido en algún lugar fuera del pipeline de despliegue de la app, apuntando a una imagen vieja porque nadie lo actualizó la última vez que la app se desplegó— es un modo de falla específico y común en plataformas que tratan el trabajo programado como ciudadano de segunda clase. Correr cron y workers como tipos de proceso de una sola app significa que un despliegue que arregla la app arregla sus jobs programados y sus workers al mismo tiempo, por construcción, no porque alguien se acordó.
Referencia completa: Workers y jobs programados.