Support long-running worker processes alongside FastAPI web apps

[ReyJ94]

First Check

• I added a very descriptive title here.
• I used the GitHub search to find a similar feature request and didn't find it.
• I searched the FastAPI Cloud documentation and didn't find this feature.
• I already checked that this feature is related to FastAPI Cloud and not to FastAPI itself.

Area

Other

Is your feature request related to a problem?

Our FastAPI app needs to accept HTTP requests, create background jobs, and enqueue those jobs through Redis/RQ. The problem is that the API process alone is not enough: a separate worker process must stay running to consume the queue and process the jobs.

Right now, if FastAPI Cloud only runs the FastAPI web/API server, the app can accept a user request and enqueue a job, but there is no separate long-running worker inside the same project to process that job. This can leave jobs stuck in the queue, while the frontend waits for progress or completion events that never arrive.

FastAPI "BackgroundTasks" are not enough for this use case because these jobs may take several minutes, need retries, need crash recovery, and must continue independently of the original HTTP request.

The blocker is therefore a deployment/runtime topology issue: we need one public FastAPI web/API process and one private long-running worker process from the same repository, sharing the same environment variables, secrets, deployment lifecycle, and external Redis instance.

Describe the solution you'd like

FastAPI Cloud should support multiple long-running process types, service roles, or process groups inside a single project, deployed from the same repository and build.

The core use case is a FastAPI backend that needs to run both a public web/API process:

uvicorn app.main:app --host 0.0.0.0 --port 8000

and a separate long-running worker process:

python -m app.commands.rq_worker all

The worker is not an HTTP server and should not receive public traffic. It should run as a private background process that stays alive independently of incoming HTTP requests.

The desired behavior is:

• one FastAPI Cloud project can define both a public web/API process and one or more private worker processes;
• both processes are built from the same repository/codebase;
• both processes share the same environment variables and secrets by default;
• the worker can maintain long-lived Redis connections for queue polling;
• the worker does not stop or scale to zero just because there is no HTTP traffic;
• it is possible to keep at least one worker replica always running;
• web/API and worker replicas can be scaled independently;
• worker logs and runtime status are visible separately from web/API logs;
• deployments restart/update both process types coherently, so stale workers do not keep processing jobs with old code;
• the platform restarts worker processes after crashes;
• ideally, FastAPI Cloud provides worker health/readiness information so the API can know whether job-processing infrastructure is available.

This is different from FastAPI "BackgroundTasks", cron jobs, or request-local async work. The worker needs to be a real continuously running process for queue-based background jobs.

Describe alternatives you've considered

We considered using FastAPI "BackgroundTasks", but that is not suitable for this use case because the work is not request-local. Jobs may outlive the HTTP request, need retries, need crash recovery, and must continue independently from the web server process.

We also considered scheduled jobs or cron-style execution, but our workload is queue-driven rather than time-driven. Jobs should start when users submit work, not on a fixed schedule.

Another workaround is to deploy the FastAPI API on FastAPI Cloud and run the worker elsewhere, such as on a VM, Fly.io, Railway, Render, or another container platform. That would work technically, but it splits one backend into two deployment systems. Secrets, logs, deploys, scaling, runtime status, and rollback behavior would have to be managed separately.

We also considered running the worker inside the same process as the web/API server, but that creates resource contention and makes production behavior harder to reason about. Long-running jobs can interfere with request handling, and worker crashes become entangled with the web process.

Our preferred setup is a single FastAPI Cloud project with separate process roles, for example:

web: uvicorn app.main:app --host 0.0.0.0 --port 8000
worker: python -m app.commands.rq_worker all

This is the common deployment shape for FastAPI apps using Redis/RQ, Celery, Dramatiq, Arq, or similar background job systems.

Additional Context

Our backend uses Redis/RQ for background jobs. Redis would be hosted externally, for example with Redis Cloud, Upstash, or another managed Redis provider. We do not need FastAPI Cloud to host Redis.

The FastAPI API process accepts user requests, creates durable job records in the database, enqueues jobs into Redis/RQ, and exposes streaming endpoints so the frontend can receive job progress.

The worker process consumes jobs from Redis/RQ, runs the long-running processing pipeline, writes results back to the database, and emits progress/completion events.

Some jobs may take several minutes, so the worker must support long-running execution and long-lived Redis connections. The API may also expose long-lived streaming responses, such as Server-Sent Events, for progress updates.

The important failure mode is: if the web/API process is running but the worker process is not running, the API can accept jobs but nothing will process them. Users may then wait for progress or completion events that never arrive.

So the key requirement is not just “background tasks,” but a separate continuously running worker process that shares the same codebase, deployment, secrets, and external Redis instance as the FastAPI web/API process.