Thanks for flagging this — you’ve likely hit a regression introduced in 3.4.21. What we’re seeing - In 3.4.21,

prefect.runtime.deployment.parameters

can be empty even when you set parameters on the deployment (e.g., via

flow.serve(parameters=...)

), while

prefect.runtime.flow_run.parameters

is still correctly populated. - This behavior matches the reports here: - prefect#19328 - prefect#19329 Impact - Your flow continues to receive the correct parameters via the run context, but

runtime.deployment.parameters

no longer reflects them in 3.4.21. - Prior to 3.4.21 (e.g., 3.4.20),

runtime.deployment.parameters

contained the expected values. Workarounds you can use now - Prefer

flow_run.parameters

in your flow code:

from prefect import flow
  from prefect.runtime import flow_run

  @flow
  def my_flow(...):
      params = flow_run.parameters
      # use params["..."]

- If you specifically need the deployment object’s persisted defaults (distinct from the run’s final parameters), you can fetch them from the API as a temporary workaround:

from prefect.runtime import flow_run
  from prefect.client.orchestration import get_client

  @flow
  async def my_flow(...):
      async with get_client() as client:
          dep = await client.read_deployment(flow_run.deployment_id)
          deployment_params = dep.parameters  # persisted on the deployment

- Alternatively, pin Prefect to 3.4.20 until a fix lands:

pip install "prefect==3.4.20"

Next steps - Can you share a bit more about your setup? - How are you defining the deployment (e.g.,

flow.serve(parameters=...)

,

flow.from_source(...).deploy(parameters=...)

, or

prefect deploy

)? - Are you reading

prefect.runtime.deployment.parameters

directly in your flow? - Prefect Server vs Cloud? I’ll keep an eye on the linked issues and update you when a fix is released. In the meantime, using

flow_run.parameters

is the safest path since it contains the full, resolved parameter set for the current run.

Great questions — here’s how these pieces fit together in Prefect 3.x. Short answers - Is each deployment a different pipeline? In Prefect terms, a “pipeline” is a flow. A deployment always targets exactly one flow. You can create multiple deployments for the same flow (e.g., different schedules/infra/params), but a single deployment does not span multiple flows. - Do I need a deployment for every pipeline? You need at least one deployment for each flow you want Prefect to run remotely, on a schedule, or via the UI/API. If your “pipeline” is multiple steps, you can model them as subflows under one parent flow and create a single deployment for that parent. - One work pool or more than one per deployment? Exactly one. A deployment specifies a single

work_pool_name

. If you want the same flow to run on different pools (e.g., k8s and docker), create multiple deployments. - Is a work pool a set of workers? Close: a work pool is a logical queue plus an infrastructure template. You attach one or more workers of the same type to that pool; those workers poll the pool and execute runs. For “push”/managed pool types, a separate worker process isn’t needed. Helpful details - Multiple workers can attach to the same work pool for scaling and HA. - Within a work pool, you can optionally route to a specific work queue for prioritization or concurrency limits. - Typical setup: - Define a flow (your pipeline code) - Create one or more deployments of that flow, each targeting a single work pool - Run one or more workers that poll that pool (for hybrid pool types like Docker/Kubernetes/ECS) Docs - Flows: Flows concept - Deployments: Deployments concept - Work pools: Work pools concept - Workers: Workers concept - Creating deployments: How to create deployments If you can share how you define “pipeline” in your project (single flow vs. multiple coordinated flows), I can suggest the cleanest deployment pattern.