Yes — your impression is basically right. Short version: if you're using repo-based/source-based deployments, installing dependencies at run time is a normal pattern, but it is inherently less reproducible than baking them into an image. So if you're seeing flaky behavior from runtime installs, that usually means you're hitting one of the tradeoffs of that approach rather than misusing Prefect. In Prefect 3.x, the modern source-based API is

flow.from_source(...).deploy(...)

(not old 2.x deployment build patterns). Example:

python
from prefect import flow

@flow
def my_flow():
    import pandas as pd
    print(pd.__version__)

if __name__ == "__main__":
    my_flow.from_source(
        source="<https://github.com/my-org/my-repo.git>",
        entrypoint="flows/my_flow.py:my_flow",
    ).deploy(
        name="my-flow",
        work_pool_name="my-pool",
    )

A few important points: What repo/source deployments are good at - Pulling the latest code from git/storage at run time - Fast iteration - Avoiding image rebuilds for every code change *What they are not great at* - Ensuring identical Python environments every run - Installing native/system deps reliably - Avoiding startup-time package resolution/install issues - Preventing drift if your requirements are not tightly pinned So if your current setup is: - worker starts - repo is cloned - dependencies get installed during the run - weird intermittent import/build/version issues happen ...that is a common failure mode of runtime dependency installation. Recommended mental model - Source deployment controls where code comes from - Image controls what environment executes it Those are separable. You do not have to choose between: 1. repo deployments with unstable runtime installs, or 2. fully copying code into images with heavy CI/CD A very practical middle ground is: Best-practice compromise - Keep using

from_source(...)

/ git-based code retrieval - Build a base image that already contains your Python/system dependencies - Let Prefect pull only the flow code from git at run time That gives you: - reproducible runtime environment - flexible code updates from git - less CI churn, because you only rebuild the image when dependencies change So instead of baking your app code into every image, you can bake only: - Python version - OS packages - libraries from

requirements.txt

/

pyproject.toml

Then Prefect still pulls the latest repo contents at runtime. This is usually the sweet spot for teams that want flexibility and consistency. When fully image-based deployments make more sense Use full image builds if: - dependencies change frequently alongside code - you need strict reproducibility - you have compiled/native deps - startup speed matters a lot - you want the exact code + env versioned together When source-based deployments are still fine They can still be fine if: - deps are small/simple/pure Python - requirements are tightly pinned - worker environment is already mostly prepared - occasional slower startup is acceptable If you stay with runtime installs, reduce flakiness by - pinning exact versions - avoiding unpinned transitive deps - preinstalling build tools/system libs on the worker image - minimizing per-run installation work - using a lockfile / reproducible resolver flow where possible If you want, I can show you one of these two concrete setups: 1. Git-based deployment + stable base image for dependencies 2. Fully image-based Prefect 3 deployment Relevant docs: - Store flow code / source-based deployments - Deploy flows - `flow.from_source()` reference If you share your work pool type too (

process

,

docker

,

kubernetes

, etc.), I can recommend the least-painful pattern for your setup.