You’re seeing that because there is no

--workers

option on

prefect server start

. In Prefect 3.x,

prefect server start

does not expose a worker-count flag — it runs a single Uvicorn process by default. You can confirm with:

prefect server start --help

How to get more concurrency - Run multiple API processes behind a load balancer/reverse proxy. - Easiest: start one full “services” instance, plus N web-only instances: - One services instance (runs scheduler, etc.):

prefect server start --host 0.0.0.0 --port 4200

- Additional web-only instances:

prefect server start --no-services --host 0.0.0.0 --port 4201
      prefect server start --no-services --host 0.0.0.0 --port 4202

- Or run Uvicorn/Gunicorn yourself with multiple workers - Use the Prefect app factory and the Uvicorn

--factory

option:

# web/API replicas (no services)
    export PREFECT_API_SERVICES_SCHEDULER_ENABLED=false
    export PREFECT_UI_ENABLED=true
    uvicorn 'prefect.server.api.server:create_app' --factory --host 0.0.0.0 --port 4200 --workers 4

Then run one separate “services” process (not behind the LB) with the scheduler enabled, e.g.:

export PREFECT_API_SERVICES_SCHEDULER_ENABLED=true
    uvicorn 'prefect.server.api.server:create_app' --factory --host 0.0.0.0 --port 4201 --workers 1

- Important: don’t run the scheduler in more than one process. Use

PREFECT_API_SERVICES_SCHEDULER_ENABLED

(or

--no-scheduler

on the CLI) to ensure only one instance runs it. Notes - If you’re using the default SQLite database, avoid multi-process API scaling; switch to PostgreSQL first for production. - You can configure host/port/logging via env vars like

PREFECT_SERVER_API_HOST

,

PREFECT_SERVER_API_PORT

, etc., but there is no env var for worker count. Docs - Self-hosted/production guidance: Self-hosted Prefect - Settings reference: Prefect settings reference If you can share your goal (local dev vs. production) and which DB you’re using (SQLite vs. Postgres), I can suggest a concrete setup.

Short answer: yes — even if you’re using Redis,

prefect server start

still does not support

--workers

. Details: - Redis doesn’t change the CLI options for Prefect Server. There is no

--workers

flag. - Scaling the API is still done by running multiple API processes (e.g., multiple

prefect server start --no-services

instances) or by running Uvicorn/Gunicorn yourself with multiple workers. - For multi-process/replicated API, the important backing store is a shared database (PostgreSQL). SQLite is not suitable for this; Redis does not replace Postgres for the server’s persistence/coordination. - Run exactly one scheduler/services instance. Use

--no-scheduler

or

PREFECT_API_SERVICES_SCHEDULER_ENABLED=false

for your extra web/API replicas. Example:

# One services instance (scheduler on)
prefect server start --host 0.0.0.0 --port 4200

# Additional API replicas (no services)
prefect server start --no-services --host 0.0.0.0 --port 4201
prefect server start --no-services --host 0.0.0.0 --port 4202

Or with Uvicorn workers for the API-only process:

export PREFECT_API_SERVICES_SCHEDULER_ENABLED=false
uvicorn 'prefect.server.api.server:create_app' --factory --host 0.0.0.0 --port 4200 --workers 4

Docs: - Self-hosted Prefect - Settings reference If by “running with Redis” you meant using Redis for caching/results via a block, the answer is still the same — it doesn’t affect server worker options. If you’re planning to replicate the API, are you on Postgres already?

You’re right — thanks for the correction. The

--workers

flag was added in PR #18876 and shipped in Prefect 3.4.20 (released Sept 25, 2025). If you’re on an older Prefect, you’ll see “No such option: --workers”. What to do - Check your version:

prefect version

- Upgrade to a version that includes the flag (>= 3.4.20):

pip install -U prefect
# or
uv pip install -U prefect

- Then this will work:

prefect server start --workers 4

Notes - The flag vertically scales the webserver (Uvicorn) workers. Background services (scheduler, late runs) still run as part of the server process; ensure you don’t run multiple scheduler instances across separate server invocations. - For production multi-worker setups, use Postgres. SQLite isn’t suitable under high concurrency. - Redis does not affect the presence or behavior of the

--workers

flag; it doesn’t replace Postgres for the server’s persistence. Links - PR #18876: Vertical scale server with workers - Release notes 3.4.20 (mentions the PR) If you share your current version and DB backend (SQLite vs Postgres), I can suggest the safest way to roll this out.