Short answer: there isn’t a built-in “warm container” feature in Prefect Cloud (2.x or 3.x). By design, each flow run executes in a fresh, isolated container/pod/task. The worker process stays warm, but it’s not the execution environment. That said, you can significantly reduce cold-start time depending on your infrastructure. A few patterns: First, can you share: - Which work pool type are you using (Kubernetes, Docker, ECS, ACI, Cloud Run, etc.)? - What “cold start” you’re seeing (image pull time, node/provisioning time, import/dependency load, etc.)? - How frequently your jobs run and any latency/SLA targets? General optimizations (apply everywhere) - Pre-bake a slim image with all dependencies and your code — avoid on-run installs. - Keep your image in a registry colocated with your compute (same region/VPC). - Use task-level caching + remote results to skip expensive work on subsequent runs: Task caching - Keep the worker process always-on; it polls continuously so scheduling is immediate once infra is ready: Workers in Prefect 3 Kubernetes (pull work pool) - Keep nodes warm: set a non-zero min size on your node group or provisioner so you don’t scale from zero. - Pre-pull images on nodes with a DaemonSet and set `imagePullPolicy: IfNotPresent`; this avoids cold image pulls. - If you need truly warm Python processes, run a persistent Dask or Ray cluster and point your flow’s task runner at it; the heavy libs stay loaded on the cluster workers. Docker (pull work pool) - Run the worker on an always-on host where your image is already pulled; new containers start very quickly when the image is cached locally. - Keep layers/cache stable (pin base image, avoid frequent rebuilds that bust the cache). ECS (pull or push) - Prefer images in ECR in the same region; enable VPC endpoints for faster pulls. - If you’re on EC2 capacity providers, keep a small base capacity “warm” so tasks don’t wait for instances to spin up. - Pre-bake the task definition image with everything needed; avoid runtime installs. - Docs: Prefect ECS guide Cloud Run / other serverless push platforms - Some platforms support keeping instances warm (e.g., Cloud Run “min instances”). Whether you can leverage this depends on whether you’re launching Services vs Jobs and your specific Prefect integration. If you’re using Cloud Run, tell me which one and I can advise how to configure min instances on your revision. Advanced: custom worker - It’s technically possible to build a custom worker that implements container pooling/reuse, but it’s non-trivial and shifts more infra responsibility to you: Developing a custom worker References - Managing work pools - Work pools and workers (blog) If you can share your work pool type and what part of startup is slow, I’ll tailor exact steps and example configs.