Flask hosting — 7 options compared

Outside the request, and outside gunicorn. A thread spawned inside a view is bound to a worker process that the platform may recycle at any moment, so the honest options are Celery with a Valkey or Redis broker, or RQ if one queue and one Redis is the whole requirement. The consumer is a separate long-lived process — celery -A app.celery worker or rq worker — built from the same image as the web app so the task code and the view code cannot diverge. On Granite it is a worker resource in the same application, with the broker as a managed Valkey alongside it. When a deploy takes the container away, an unacknowledged task returns to the queue and runs again, so a task that charges a card twice is a bug you have to design out.

APScheduler started inside the app is the shortest path and the one that misbehaves under load: the scheduler lives in every gunicorn worker in every replica, so a nightly export runs four times on one container and twelve across three. Either give it a jobstore with locking, or move the schedule out of the process entirely. A platform cron is the cleaner version — on Granite a cron-job resource runs flask export-reports on a cron expression as a single container, with Forbid or Allow governing an overrunning run, and its output goes to that resource's log rather than into the web app's stream.

Managed on Render, Railway, Koyeb and Granite, an app you run yourself on Fly, and a separate Cloud SQL product on Cloud Run. Granite takes backups on a schedule into external storage and support can run point-in-time recovery for Postgres on request; the interval is not published, so ask before you depend on it. Databases have no public endpoint — the app connects over internal DNS, you connect via novps port-forward database <id> -l 5432. SQLAlchemy's pool is per process, not per application, so a pool_size of five across four gunicorn workers is twenty connections from a single service, and a pooler in front of the database is what stops that becoming an outage.

A push to the tracked branch builds an image and rolls it out, or the platform watches a Docker tag you push yourself. flask db upgrade has to run exactly once per deploy: Render and Railway expose a release command for it, and on Granite you run it from the resource's Console tab or over a forwarded database port before the new image goes live. In the container start command it becomes a race between replicas against one schema. Keep in mind that a rollback restores the image and not the database, so a migration that drops a column takes the previous version down with it.

A web service, an RQ or Celery worker, a small Postgres and a broker, as of 1 September 2026. Render totals $30 — $7 web, $7 worker, $6 for a 256 MB Postgres, $10 for a 256 MB Key Value instance. Fly.io is $3.32 for each 512 MB machine, with the database your responsibility. PythonAnywhere is $10 and includes scheduled tasks, but not a real queue. Granite is $9 with $15 of credits spread across all four pieces, $8 of which the Extra Small Valkey node takes — and Hobby's 1 GiB per service holds a small gunicorn set rather than a generous one.