Rails hosting — 6 options compared

In a second process, never inside Puma. Rails 8 ships Solid Queue, which keeps jobs in the Postgres you already have and needs no broker; Sidekiq remains the popular alternative and does want Redis or Valkey behind it. Either way the runner is a long-lived process started from the same image with a different command — bin/jobs or bundle exec sidekiq — so it cannot drift out of sync with the web code. Render and Railway call that a background worker; on Granite it is a worker resource in the same application, sharing its environment variables. A deploy replaces the container: Sidekiq takes SIGTERM, stops fetching, finishes what it holds and returns the rest to the queue. A crash is a restart and a retry, which is why every job has to be safe to run twice.

Three mechanisms, one of which survives a second replica. The whenever gem writes a crontab, which assumes a machine you can write a crontab on — Kamal on a VPS, not a container platform. Solid Queue's recurring tasks live in config/recurring.yml and are dispatched through the database, so two workers do not double-fire them. Third is a platform cron: on Granite a cron-job resource runs bin/rails runner … on a cron expression as a single container — the type takes no replica count — with an explicit Forbid or Allow choice when the previous run is still going. Its output goes to the resource log: novps resources logs <id> --since 1h -f.

Managed on Render, Railway, Koyeb and Granite — pick the version and a node size and the credentials are generated for you. On Fly the Postgres is an app you run and get paged for. Granite backs databases up on a schedule into external storage and support can run point-in-time recovery for Postgres on request; the schedule is not published, so ask before you depend on an RPO. There is no public endpoint: the app reaches the database over internal DNS, you reach it with novps port-forward database <id> -l 5432. A pooler sits in front, which matters because Rails opens RAILS_MAX_THREADS connections per Puma worker — four workers at five threads is twenty from one service.

Push to the tracked branch and the platform builds and rolls out the image; point it at a Docker tag and it redeploys when the tag moves. Migrations are where they differ. Render and Railway give you a release command that runs bin/rails db:migrate once, after the build and before traffic. Granite has no release-phase hook: run it from the resource's Console tab, or forward the database port and run it from your machine, before the new image rolls. Putting db:migrate in the start command breaks everywhere — three replicas migrate the same schema at once. Rolling an image back does not roll the schema back, so write migrations the previous version can still read.

One web service, one job runner, one small Postgres, as of 1 September 2026. Render: $7 for the Starter web service, $7 for the worker, $6 for a 256 MB Postgres — $20, plus $10 for a 256 MB Key Value instance if you run Sidekiq rather than Solid Queue. Fly.io: two shared-cpu-1x machines at 512 MB, $3.32 each, and a Postgres you operate on a third — cheapest on paper, and you own the restores. Railway bills per second against a $5 monthly minimum on Hobby. Granite is $9 on Hobby with $15 of credits the app, the worker and the database all draw from, capped at 1 vCPU, 1 GiB and one replica per service — a real Puma set beside Sidekiq lands on Advanced at $39.