Short answer: it depends on your Prefect version. Quick check: are you on Prefect 3.x or 2.x? The process is different. - Prefect 3.x (default assumption) - Deployments don’t persist “pull steps.” Code fetching at run time is driven by how you deployed (e.g.,

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

or setting

storage=

on the deployment). - To “remove pull steps,” redeploy without any source/storage so the runner just uses local code: - CLI

# from your project root where the flow file lives
      prefect deploy ./path/to/flow.py:my_flow -n my-deployment

- Python

from prefect import flow

      @flow
      def my_flow():
          ...

      my_flow.deploy(name="my-deployment", work_pool_name="process-pool")

- Clean up the old one if needed:

prefect deployment delete "my-flow/my-deployment"

- Inspect what a deployment will actually use:

prefect deployment inspect "my-flow/my-deployment"

- If you see “pull” entries in your project’s prefect.yaml (referencing things like

prefect.deployments.steps.pull.git_clone

), just remove those lines and run

prefect deploy

again. - Prefect 2.x - “Pull steps” are stored on the deployment and executed by workers. - Remove them by re-applying a deployment spec without pull steps (or set them to an empty list):

# deployment.yaml (2.x)
    name: my-deployment
    pull: []

prefect deployment apply deployment.yaml

- Or delete and rebuild the deployment without any pull steps. If you share your version and how the deployment was created (CLI, Python, or UI), I can give the exact edit you need. I promise it will be only mildly soul-crushingly tedious.

Short version: not on your machine. In Prefect 3.x, a “Prefect managed” work pool runs each flow run on Prefect’s managed infrastructure in an ephemeral container. Prefect spins it up for the run, pulls your code, executes, streams logs back, then tears it down. How your code gets there - If you deployed with

flow.from_source("https://...").deploy(...)

, Prefect clones that repo at run time. - If you set

storage=

on the deployment (e.g., S3/GCS), Prefect pulls your project from that storage. - If you used

prefect deploy

from a project, Prefect packages your project so the runner can fetch it. - There’s no access to your local filesystem; you must provide source/storage or a way to install your package. What you can/can’t customize - You can pass environment variables and parameters via the deployment. - Managed pools use a Prefect-provided container image; if you need custom images, GPUs, or tight control over networking, use Docker/Kubernetes work pools instead. Want details on private repos, dependencies, or networking? Tell me how you’re deploying (CLI vs Python) and where your code lives. I’ll point you to the least painful setup.

Short answer: not your ECS. Prefect-managed work pools run your flow in Prefect’s own ephemeral containers on Prefect Cloud. The underlying service (ECS, Kubernetes, carrier pigeons) is intentionally abstracted and may change; you don’t get an ECS task in your AWS account or VPC. If you specifically need ECS (VPC access, IAM roles, custom images, GPUs, cost controls), use a self-managed ECS/Docker/Kubernetes work pool instead. Happy to point you to the right setup if you share your requirements.