Great question — there’s a tradeoff between “cheapest” and “no startup latency,” especially on serverless GCP. Short answer - If you truly want near-zero startup latency: run a Docker worker on a small always-on GCE VM. It will launch your Artifact Registry image in ~1–2s and costs roughly the VM price (~$7–$20/mo for e2-micro/small). - If you want the absolute cheapest (pay-per-use) and can tolerate a few seconds of cold start: use the Cloud Run v2 worker. It’s fully managed and pulls images from Artifact Registry, but each job has unavoidable cold start (typically 3–15s). Why - Cloud Run v2 (serverless) is cheap and simple but every run is a Cloud Run Job and can’t be pre-warmed. You can’t fully eliminate cold starts. - Docker worker on a GCE VM keeps capacity warm. With your image already pulled and

IfNotPresent

pull policy, container startup latency is very low and predictable. - Kubernetes (GKE) works well but pod scheduling typically adds more latency than Docker on a single VM, and cluster costs are higher than one small VM. - Vertex AI is great for ML/gpu but has higher startup time and cost. Recommended setup for “low-cost + no latency” 1) Provision a small GCE VM with Docker - e2-micro/e2-small is usually enough if your flows are light. - Authenticate Docker to Artifact Registry:

gcloud auth configure-docker us-docker.pkg.dev
  docker pull us-docker.pkg.dev/<PROJECT>/<REPO>/<IMAGE>:<TAG>

2) Create a Docker work pool in Prefect Cloud

prefect work-pool create --type docker gce-docker-pool

- In the pool’s Job Variables (UI), set: - image:

us-docker.pkg.dev/<PROJECT>/<REPO>/<IMAGE>:<TAG>

- image_pull_policy:

IfNotPresent

3) Start the Docker worker on the VM (with concurrency as needed)

prefect worker start --pool gce-docker-pool --limit 2

4) Deploy your flow using your Artifact Registry image

prefect deploy

Notes - This uses your Docker image built from your Poetry project (pyproject.toml + poetry.lock). Keep doing that during image build so dependencies are deterministic in the container. - If you ever need private Artifact Registry auth inside the worker, either keep docker logged in (via

gcloud auth configure-docker

) or configure a Docker registry credentials block in Prefect. If you can tolerate a few seconds of cold start, the cheapest/most managed option - Use the Cloud Run v2 worker with your AR image. Expect 3–15s cold start per job; no servers to manage; cost is per execution second. - Create and start:

prefect work-pool create --type cloud-run my-cloud-run-pool
  prefect worker start --pool my-cloud-run-pool

- Deploy with your AR image in

prefect.yaml

or

flow.deploy(...)

. Helpful links - Workers overview: Workers (concepts) - Docker worker guide: Run with Docker - Kubernetes worker guide: Run with Kubernetes - Serverless (Cloud Run) guide: Run serverless (Cloud Run) - GCP integration and worker guide: Prefect GCP integration and GCP worker guide - Docker worker reference: prefect_docker.worker - Cloud Run v2 worker reference: prefect_gcp Cloud Run v2 Clarifying to tailor this: - How strict is “no latency”? Are 1–2 seconds okay, or do you need sub-second starts? - What’s your typical flow runtime and frequency? If workloads are sparse, Cloud Run may be cheapest; if frequent or latency-sensitive, the GCE + Docker worker is usually the sweet spot.

Short version: - cloud-run-v2 = polling worker. You run a persistent worker process that polls your work pool and submits Cloud Run Jobs when runs are ready. - cloud-run-v2:push = push work pool. Prefect Cloud submits Cloud Run Jobs directly on your behalf; no worker process to run. Key differences - Who submits jobs: - cloud-run-v2: A running worker process (you host it) polls and then calls the Cloud Run API. - cloud-run-v2push Prefect Cloud calls the Cloud Run API directly (no polling worker). - Latency: - cloud-run-v2: Adds polling delay (typically 5–30s, depending on prefetch/poll interval) before your job is submitted. - cloud-run-v2push Near-instant submission from Prefect Cloud (no polling overhead). Note: Cloud Run cold start still applies in both cases. - Cost/ops: - cloud-run-v2: You pay for wherever the worker runs (e.g., a Cloud Run service or VM) even when idle. - cloud-run-v2push No always-on worker, so no idle cost. You only pay for Cloud Run Job executions. - Credentials: - cloud-run-v2: Credentials must be available to the worker process to call GCP APIs. - cloud-run-v2push You store GCP credentials with the pool; Prefect Cloud uses them server-side to create jobs. - When to use: - cloud-run-v2: If you’re self-hosting the Orion API or need a worker process for specific network/runtime constraints. - cloud-run-v2push If you’re on Prefect Cloud and want minimal ops, lower idle cost, and immediate job submission. CLI quick start - Polling worker:

prefect work-pool create --type cloud-run-v2 my-crv2-pool
  prefect worker start --pool my-crv2-pool

- Push pool (no worker to start):

prefect work-pool create --type cloud-run-v2:push my-crv2-push-pool

Then set required job variables (region, service account, image, credentials) in the pool. Helpful links - Workers overview: Workers (concepts) - Cloud Run v2 worker reference: prefect_gcp Cloud Run v2 - GCP worker guide: GCP worker guide - Serverless how-to (Cloud Run): Run serverless (Cloud Run) If your goal is “cheap and no extra latency from Prefect,” cloud-run-v2:push is usually the best fit on Prefect Cloud. It won’t remove Cloud Run’s own cold starts, but it removes the worker polling delay and any idle worker cost.