Cron jobs and background workers without a separate dyno

The usual PaaS framing treats a cron job and a background worker as separate products from your web app — a different dashboard tab, sometimes a different pricing line. They’re not actually separate things. They’re processes of the same app, which is the part worth taking seriously rather than treating as a technicality.

What the Workers tab actually offers

It only shows job runners it can actually find in your repository — not a generic list you configure from scratch: processes declared in Procfile/Procfile.dev/app.json, or runners already in your dependencies (Sidekiq, Solid Queue, GoodJob, Resque, Celery, RQ, Laravel’s queue or Horizon, an npm run worker script). Add one in a click, or point at any long-running command yourself if nothing’s detected. Each worker runs the app’s own image and scales independently of the web process.

That last part matters more than it sounds: a worker isn’t a smaller, separate deployment that drifts out of sync with web — it’s the same build, same release, same rollback, just a different process type scaled on its own number.

Workers that sleep too

A worker-only app — no web process at all, just a queue consumer — can still use Sleep when idle under Settings → General. It stops once its reported CPU has been idle long enough, and Railyard wakes it on its own schedule specifically to drain anything that’s queued up, then lets it go back to sleep. The pattern that usually gets built by hand (a cron job that pings a worker awake, a lambda that checks a queue depth) is just a checkbox here.

Cron, separately

Cron runs a command in the app’s own image on a schedule (0 3 * * *), with run history kept — no separate container, no separate image to keep in sync with the app’s actual code, because it’s literally the same image everything else runs.

Why this is worth noticing

The alternative — a cron job defined somewhere outside the app’s deploy pipeline, pointing at an old image because nobody updated it when the app last deployed — is a specific, common failure mode in platforms that treat scheduled work as a second-class citizen. Running cron and workers as process types of the one app means a deploy that fixes the app fixes its scheduled jobs and its workers at the same time, by construction, not by remembering to.

Full reference: Workers and scheduled jobs.