In Prefect, how does a worker get your flow code when a deployment run starts?

## Prefect does not store your code The single most useful sentence here: **`prefect deploy` uploads configuration, not source**. The deployment holds an entrypoint — a file path and a flow function name, `flows/etl.py:etl_flow` — plus a description of how to obtain the file. The Prefect API keeps orchestration metadata; your code stays wherever you keep code. Everything else follows from that. ## Route 1 — pull steps in prefect.yaml `prefect.yaml` has `build`, `push` and `pull` sections. Only **`pull` runs at flow-run time, on the worker**; `build` and `push` run at `prefect deploy` time on your machine or in CI. A typical pull section: ```yaml pull: - prefect.deployments.steps.git_clone: repository: https://github.com/acme/pipelines.git branch: main - prefect.deployments.steps.pip_install_requirements: requirements_file: requirements.txt ``` When a run starts, the worker's infrastructure executes these in order, producing a working directory with your project in it, and then imports the entrypoint. Other steps exist for pulling from remote storage (S3, GCS, Azure) and `set_working_directory` for code that is already present. This is the cheapest setup and the most common one for `process` pools. Its properties: fast to iterate (merge to `main` and the next run picks it up), but the deployment is pinned to a *ref*, not a *build* — if `branch: main` moves, the flow's behaviour moves with it, silently, with no redeploy and no new deployment version. Private repositories need a credential: a token stored in a Prefect Secret/credentials block referenced by the step, or SSH keys mounted on the worker. ## Route 2 — from_source in Python ```python flow.from_source( source="https://github.com/acme/pipelines.git", entrypoint="flows/etl.py:etl_flow", ).deploy(name="nightly", work_pool_name="k8s-prod") ``` `from_source` returns a flow object bound to a remote location; `.deploy()` records that location on the deployment. `source` may be a git URL or a storage block (for example an `S3Bucket` block). Functionally the same as a git-clone pull step, expressed in code — handy when deployments are created from a CI script that also computes the version or the image tag. ## Route 3 — bake the code into an image For `docker` and `kubernetes` pools, the usual production choice is an image that already contains the project: ```yaml build: - prefect_docker.deployments.steps.build_docker_image: image_name: acme/pipelines tag: "{{ $GIT_SHA }}" dockerfile: Dockerfile push: - prefect_docker.deployments.steps.push_docker_image: {} pull: - prefect.deployments.steps.set_working_directory: directory: /opt/prefect/pipelines ``` Now the run's container carries code *and* dependencies together. Nothing is fetched at run time, so there is no dependency on git availability, no per-run install latency, and the artefact is immutable: the same tag always runs the same code. The cost is a build-and-push on every change and an image registry the cluster can read. ## Choosing between them - **Reproducibility** — baked images win outright. A rollback is redeploying an old tag. Git pulls give reproducibility only if you pin a tag or commit rather than a branch. - **Dependency isolation** — pull steps install into a shared environment on the worker host, so two deployments needing different library versions collide. Images isolate cleanly. - **Iteration speed** — git pulls have no build step; a merge is live on the next run. - **Startup latency** — a clone plus `pip install` on every run adds seconds to minutes; images pay that once at build, though a cold image pull is its own cost. - **Secrets** — either way the *worker* needs read access: a git token or registry credentials. Neither is stored in your flow code. ## Failure modes to recognize The classic symptom is a run that reaches `Running` and dies immediately with a `ModuleNotFoundError` or a missing-entrypoint error. Almost always this is code delivery: the entrypoint path is relative to the wrong working directory, the pull step cloned but `pip_install_requirements` was omitted, the image tag is stale, or the worker cannot authenticate to the private repository. The second classic is the mystery change — behaviour differed between two runs of the same deployment because the tracked branch moved underneath it. ## Version note This is the Prefect 3.x model (`prefect.yaml` steps and `from_source`). Prefect 2 originally attached separate **storage blocks** to a deployment to describe where code lived; steps replaced that.