Short answer: one worker is enough. Details: - A single Prefect 3.x worker can run multiple flow runs concurrently on a bare‑metal machine. Each run is executed in its own subprocess (for the Process worker). - Control per‑worker concurrency with the worker’s concurrency limit. Start your worker with a higher limit to allow multiple simultaneous runs, e.g.:

prefect worker start -p my-baremetal-pool --limit 4

- The work pool’s concurrency limit caps total concurrency across all workers in that pool. Effective concurrency = min(pool limit, sum of worker limits). - You’d only need multiple workers if you want isolation (different environments), different queues, or to spread load across hosts. Not required for simple local parallelism. If you’re on a single box and just want multiple flows at once: 1 pool + 1 worker with

--limit > 1

will do the job—assuming your machine can keep up.

@Marvin Thank you! If limit is not specified, what is the default?

By default, a worker runs 1 flow run at a time. If you want concurrency, set it explicitly when starting the worker, e.g.:

prefect worker start -p my-pool --limit 4

Pool-level concurrency is unlimited unless you set it, so the effective cap is: - per‑worker:

--limit

(default 1) - per‑pool: pool concurrency limit (default unlimited) - actual concurrency = min(pool limit, sum of worker limits, your machine’s patience)

i think by default there's no subprocess concurrency limits

ope https://github.com/prefecthq/prefect/blob/main/src/prefect/settings/models/runner.py#L52-L55

let me make sure that's the right setting rq

ah i was right the first time default behavior without an explicit limit is unlimited for process worker, not the runner's limit (which would apply if you were using .serve)

notably, tasks are free to call other tasks or flows (unlike prefect 2.x) so you can

.serve

tasks that call other flows etc