<@ULVA73B9P> when versioning deployments, can any ...
# ask-marvin
l
@Marvin when versioning deployments, can any existing flows running under the old deployment finish?
m
thought for 69.6 seconds
Yes. Creating a new deployment version does not interrupt in-flight flow runs. Anything already running under the old version will continue and finish normally. A few nuances: - Existing scheduled/pending runs will still execute; new runs (and newly generated schedule occurrences) will use the latest deployment version. - Already-launched jobs keep the old code/image/config they started with. Not-yet-launched scheduled runs will pick up the updated deployment config (e.g., new image, job variables) when they’re submitted. - The only things that would stop old runs are explicit cancellation or removing/pausing the infrastructure so no worker can pick them up. If you want details for your setup (e.g., Docker, K8s, or job variables behavior), tell me what you’re using and I’ll be precise.
l
@Marvin can i explicitly specify the deployment version to use when running a deployment
m
thought for 171.4 seconds
Short answer: no. In Prefect 3.x you can run a deployment by name or ID, but there’s no flag to pick a specific “version” at run time. The run will use whatever version is currently attached to that deployment. - CLI:
prefect deployment run "flow-name/deployment-name"
or
prefect deployment run --id <deployment-id>
- Python:
from prefect.deployments import run_deployment; run_deployment("flow-name/deployment-name")
If you need to run different code/config “versions” side-by-side, create separate deployments with distinct names (e.g.,
my-deploy-v1
,
my-deploy-v2
) pinned to the desired commit/image. Alternatively, re-deploy the older commit to make it the current version, then run it. If you share your setup (source control, Docker/K8s, etc.), I can suggest a clean versioning pattern.
l
@Marvin well then if i release a new deployment version while a flow is running on an older image but before it creates a sub deployed flow, the sub deployed flow will be rejected by the server then... whats the point of versions then if they don't protect you against this?
m
thought for 69.4 seconds
Not rejected — just “helpfully” runs whatever the deployment’s latest spec is. So if your parent is on image A and you ship a new deployment version pointing to image B before it calls a sub-deployed flow, that child run will use image B. That’s the risk: drift, not rejection. What deployment “versions” give you today is auditability and history on a single deployment resource. They don’t let you pin or target a specific historical version at run time. How to actually protect yourself - Make deployments immutable by name. Create a new deployment per release and encode the version/commit in the name. - Example names:
child-flow/ingest-2025-08-12
or
child-flow/ingest@abc1234
- Then your parent calls the exact versioned deployment name so parent and child stay in lockstep. - Pass the version into the parent and construct the child deployment name dynamically:
Copy code
from prefect.deployments import run_deployment
  import os

  release = os.environ["RELEASE_SHA"]  # or a flow parameter
  child_name = f"child-flow/ingest@{release}"
  run_deployment(name=child_name, parameters={"x": 1})
- If you don’t need separate infra for the child, call the child flow directly as a subflow (function call). That guarantees the same code/image. - Pin your code and container immutably (git SHA, image digest) for each versioned deployment so each is reproducible and survives future updates. References - run_deployment API: prefect.deployments.run_deployment If you tell me how you’re building images and sourcing code (git, Docker/K8s), I’ll sketch a versioned deployment pattern you can drop in.