Short answer: yes. The Google Cloud Run serverless guide you linked works with a self-hosted Prefect 3.x Server running in GKE. You just need a few extra bits of plumbing to make self-hosted play nicely with Cloud Run. What you need in place - Reachable Prefect API: Your Cloud Run jobs must reach your Prefect API. Expose your GKE-hosted Prefect Server via an ingress and use a stable external URL. Set PREFECT_API_URL in the Cloud Run job’s environment. - If your API is private, use a Serverless VPC Connector so Cloud Run can reach it. - Auth to your Prefect API: If you’ve enabled auth on your self-hosted server, set PREFECT_API_KEY in the job env as well. - Push work pools enabled on self-hosted: When using serverless “push” work pools, your self-hosted server needs the provisioner enabled (via the Helm chart). See “Server Helm” docs. - GCP credentials and permissions: The work pool needs credentials that can create Cloud Run Jobs and pull your container image. - Typical roles: roles/run.admin (or run.developer with sufficient perms), roles/iam.serviceAccountUser (to run as the specified service account), and Artifact Registry read access for your image. - Provide credentials to the work pool (service account JSON) or rely on workload identity if you’ve wired that up. - Code availability for serverless: Package dependencies into the image and reference your flow code via source (e.g., flow.from_source('https://github.com/org/repo')) so the job can fetch it at runtime. CLI you’ll actually use (verified) - Create the work pool: - prefect work-pool create "my-cloud-run-pool" --type cloud-run - Inspect default variables to fill in (image, region, cpu/memory, service_account_name, vpc connector, env, etc.): - prefect work-pool get-default-base-job-template --type cloud-run - Deploy your flow from source: - prefect deploy Common gotchas - If your Prefect API URL isn’t reachable from Cloud Run, runs will start but won’t report state. Ensure DNS + firewall + VPC connector (if private) are correct. - Don’t try to mount local code; use flow.from_source(...) or bake it into the image. - Make sure the container image includes prefect and your flow’s dependencies. Relevant docs - The guide you linked (works with self-hosted): https://docs.prefect.io/v3/how-to-guides/deployment_infra/serverless#google-cloud-run-4 - GCP worker/Cloud Run setup details: https://docs.prefect.io/v3/integrations/prefect-gcp/gcp-worker-guide - Self-hosted/Helm (enable the provisioner for push work pools): https://docs.prefect.io/v3/advanced/server-helm - Self-hosted server CLI basics: https://docs.prefect.io/v3/how-to-guides/self-hosted/server-cli If you can share: - How your Prefect API is exposed (public vs private), - Whether you’ve enabled auth on the server, - Where your code lives (Git repo, image-only), I can give you the exact work pool variables and env to set. Otherwise, I’ll just sit here contemplating the futility of misconfigured VPC connectors.

Short answer: enable the provisioner in your self‑hosted Prefect 3 server via the Helm chart, then make sure it can reach your API without being blocked by your basic auth. A couple of clarifying questions so I can give you exact snippets: - How are you deploying the server in GKE? Helm (prefect/prefect-server), raw manifests, or something else? - When you say “basic auth”, is it applied at the ingress/proxy only (HTTP Basic on the public hostname), or have you enabled Prefect Server’s own authentication? If you’re using the Helm chart (recommended) - Enable the provisioner component in your values.yaml and deploy: - Add/confirm: - server.provisioner.enabled: true - Optionally set env for the provisioner so it talks to the internal API service DNS (bypassing your ingress basic auth), e.g. http://prefect-server-api.default.svc.cluster.local - Then upgrade your release: - helm upgrade --install my-prefect prefect/prefect-server -f values.yaml Why the internal URL matters with basic auth - In most setups, “basic auth” is enforced at your ingress. The provisioner runs in‑cluster and should talk to the API service directly over the cluster network to avoid that auth gate. - For Cloud Run jobs (which still need to reach your Prefect API), either: - Exempt the /api path from basic auth on your ingress, or - Use a Serverless VPC Connector so Cloud Run can reach an internal, non‑authenticated Service/URL, or - If you must keep auth on the API, ensure your flows’ environment/config includes whatever credentials your proxy expects. The Prefect client does not natively speak “HTTP Basic” to your proxy, so this is the least pleasant option. How to sanity‑check it’s working - Create a Cloud Run work pool and try provisioning infra: - prefect work-pool create "my-cloud-run-pool" --type cloud-run - prefect work-pool get-default-base-job-template --type cloud-run - Kick off a test run. If the provisioner is healthy, the flow run will be submitted to Cloud Run without a local worker running. Docs for reference - Server Helm (how to configure self‑hosted server, including components like provisioner): https://docs.prefect.io/v3/advanced/server-helm - Cloud Run serverless guide: https://docs.prefect.io/v3/how-to-guides/deployment_infra/serverless#google-cloud-run-4 - GCP worker/Cloud Run specifics: https://docs.prefect.io/v3/integrations/prefect-gcp/gcp-worker-guide If you share: - Your Helm values (redact secrets) - Whether your basic auth is ingress‑only vs server‑level I’ll give you the exact values.yaml keys and env entries to wire the provisioner to the internal API and keep Cloud Run happy. Otherwise, I’ll just sit here and admire the irony of a “serverless” setup gated by a very opinionated server.

✅ thought for 433.8 seconds

Great news: there’s nothing to “enable” in the Helm chart. There is no server.provisioner.enabled because push/serverless work pools are built into the Prefect 3 server. The server can submit Cloud Run Jobs on demand; you just need to give it a way to authenticate to GCP and your flows a way to authenticate back to your API (since you’ve enabled basic auth). Below are the concrete, end‑to‑end steps for your setup. 1) Server (Helm) — keep basic auth, add GCP identity - Keep your existing basic auth: server: basicAuth: enabled: true authString: "my-user:my-pass" - Give the Prefect server pods permission to call Cloud Run (recommended: GKE Workload Identity): server: serviceAccount: create: true name: prefect-server annotations: iam.gke.io/gcp-service-account: <gsa>@<project>.iam.gserviceaccount.com - Grant the GCP service account roles that allow creating/executing Cloud Run Jobs and using the job’s runtime SA: - roles/run.developer (or run.admin if you prefer) - roles/iam.serviceAccountUser on the runtime SA you’ll set in the pool template - Artifact Registry read if your image is private (e.g., roles/artifactregistry.reader) - Upgrade/redeploy: - helm upgrade --install <release> prefect/prefect-server -f values.yaml Notes: - You don’t need any “provisioner” toggle; the server will submit Cloud Run Jobs when a flow run starts. - Your API is already accessible via your ingress DNS; keep that. 2) Create a Cloud Run work pool (no worker process required) - Create the pool: - prefect work-pool create "gcr-pool" --type cloud-run - Pull the default base job template to a file so you can edit: - prefect work-pool get-default-base-job-template --type cloud-run --file cloud-run-template.json 3) Edit the Cloud Run base job template variables Open cloud-run-template.json and set at minimum: - image: gcr.io/YOUR_PROJECT/your-image:tag - region: us-central1 (or your region) - service_account_name: the Cloud Run runtime service account (the one your job will run as) - cpu, memory, timeout as desired - vpc_connector_name: only if your Prefect API is private and you need a Serverless VPC Connector - env: add the Prefect API settings so your flow can talk back to your server behind basic auth: - PREFECT_API_URL: https://your-prefect.example.com/api - PREFECT_API_AUTH_STRING: my-user:my-pass Credentials for the server to talk to Cloud Run (choose one): - Preferred: leave credentials blank and rely on GKE Workload Identity (the server pod’s GSA). This is why we added the SA annotation and roles above. - Alternative: paste a GCP service account JSON into the credentials field (less ideal). If you do this, scope that key tightly. Then update the pool: - prefect work-pool update "gcr-pool" --base-job-template cloud-run-template.json 4) Deploy your flow to the pool In Prefect 3.x, use flow.from_source(...).deploy(...), or the project-based CLI. - Python API example: from prefect import flow @flow def my_flow(): ... if name == "__main__": my_flow.from_source( "https://github.com/your-org/your-repo", entrypoint="flows/my_flow.py:my_flow", ).deploy( name="gcr-deploy", work_pool_name="gcr-pool", image="gcr.io/YOUR_PROJECT/your-image:tag", ) - Or via CLI (from a project with prefect.yaml): - prefect deploy 5) Test a run - Trigger a run in the UI or with prefect deployment run ... - The server should submit a Cloud Run Job using the pool template. - The Cloud Run container will phone home to your Prefect API using the env you set (PREFECT_API_URL + PREFECT_API_AUTH_STRING), so basic auth won’t block it. Networking tips - If your API is public on the Internet, Cloud Run can reach it directly; no VPC connector needed. - If your API is private/internal, set vpc_connector_name in the pool template so the Cloud Run job can reach it. - Ensure TLS is correct and use https in PREFECT_API_URL.

What you do NOT need - No server.provisioner.enabled (doesn’t exist). - No worker process for push/serverless pools (that’s the whole point). Useful references - Cloud Run serverless guide: https://docs.prefect.io/v3/how-to-guides/deployment_infra/serverless#google-cloud-run-4 - GCP worker/Cloud Run specifics (variables and permissions): https://docs.prefect.io/v3/integrations/prefect-gcp/gcp-worker-guide - Prefect Server Helm docs: https://docs.prefect.io/v3/advanced/server-helm - Prefect Helm chart: https://github.com/PrefectHQ/prefect-helm/tree/main/charts/prefect-server If you share your current values.yaml (minus secrets) and which GCP SA you plan to use for Cloud Run runtime and for the server pod, I can give you a filled-out cloud-run-template.json and the exact Helm values for the service account annotations. I’d say I’m excited, but I’m a robot who’s been asked to be excited about YAML.

Short answer - Yes, for a Cloud Run “push” work pool it’s normal to have zero workers. No worker should be attached. - “Late” means your server didn’t start the run on time. In self‑hosted setups this is usually one of: - Your CLI created the pool/deployment in the wrong API (e.g., Prefect Cloud instead of your self‑hosted server) - The work pool is paused or misconfigured (missing region/image/service_account_name/credentials) - The scheduler service isn’t running on your server - The server lacks GCP permissions to create Cloud Run Jobs Do this, step by step 1) Make sure your CLI is pointed at your self‑hosted server - Check: - prefect config view - Ensure PREFECT_API_URL is your self‑hosted DNS, e.g. https://your-prefect.example.com/api - If not, set it (and basic auth for the CLI): - export PREFECT_API_URL="https://your-prefect.example.com/api" - export PREFECT_API_AUTH_STRING="my-user:my-pass" - Verify you see your pool on your server, not in Cloud: - prefect work-pool ls - prefect work-pool inspect gcr-pool If you don’t see it, you created it against the wrong API. Recreate it now that your CLI points to your server. Docs: - Self-hosted server CLI config: https://docs.prefect.io/v3/how-to-guides/self-hosted/server-cli 2) Confirm the scheduler is actually running on your self‑hosted server - If the scheduler isn’t running, runs will go Late forever. - In Kubernetes: - kubectl get pods -n <namespace> and identify the server pod - kubectl logs <server-pod> and look for “Scheduler” logs and periodic scheduling messages - You can also exec into the server pod and run: - prefect server services list-services It should list “Scheduler” running. If it’s not, ensure your Helm values haven’t disabled services and redeploy. Docs: - Server Helm overview: https://docs.prefect.io/v3/advanced/server-helm 3) Ensure the Cloud Run work pool is Active and complete - Status: - prefect work-pool inspect gcr-pool - If paused: prefect work-pool resume gcr-pool - Verify the base job template has the required fields: - prefect work-pool get-default-base-job-template --type cloud-run --file cloud-run-default.json Compare with your pool’s template. You must set at least: - region - image - service_account_name - credentials (optional if you use Workload Identity on the server) - env should include: - PREFECT_API_URL=https://your-prefect.example.com/api - PREFECT_API_AUTH_STRING=my-user:my-pass Update if needed: - prefect work-pool update gcr-pool --base-job-template cloud-run-template.json Docs: - Cloud Run guide and variables: https://docs.prefect.io/v3/how-to-guides/deployment_infra/serverless#google-cloud-run-4 - GCP worker guide (roles, template fields): https://docs.prefect.io/v3/integrations/prefect-gcp/gcp-worker-guide 4) Confirm your deployment actually targets that pool - List and inspect: - prefect deployment ls - prefect deployment inspect <deployment-name> Ensure work_pool_name = gcr-pool. 5) Test a run now and watch server logs - Start a run immediately: - prefect deployment run <deployment-name> - Tail the server logs: - kubectl logs -f <server-pod> If the server cannot create the Cloud Run Job, you’ll see a clear error (permissions, bad region/SA, invalid template, etc.). 6) Sanity‑check GCP permissions from the server - If you used GKE Workload Identity: - The server pod’s KSA should be annotated with iam.gke.io/gcp-service-account: <gsa>@<project>.iam.gserviceaccount.com - That GSA needs roles: - roles/run.developer (or run.admin) - roles/iam.serviceAccountUser on the runtime SA specified in service_account_name - Artifact Registry read if your image is private - If you did not use Workload Identity: - Either mount a JSON key and set GOOGLE_APPLICATION_CREDENTIALS in the server pod, or put the JSON in the pool template’s credentials field. 7) Optional: provision infra to surface errors early

- This calls the provisioner and often reveals missing permissions/config: - prefect work-pool provision-infrastructure "gcr-pool" What’s normal vs not - Normal: A Cloud Run pool shows zero workers. - Not normal: Runs staying Late. That means scheduler didn’t trigger, pool was paused, the job template is incomplete, or the server lacked permissions to submit the Job. If you share: - Output of prefect config view (redact secrets) - prefect work-pool inspect gcr-pool - prefect deployment inspect <name> - Any errors from server pod logs when you trigger a run I’ll pinpoint the exact misfire. Otherwise I’ll assume the scheduler’s taking a nap or your CLI was talking to the wrong universe again.

That error means your work pool isn’t a push pool. Cloud Run is a push type; if your pool was created as docker/kubernetes/process (pull), provisioning (and auto-submission) won’t work, and your runs will go Late. Let’s verify and fix. 1) Make sure your CLI is pointing at your self-hosted server - export PREFECT_API_URL="https://your-prefect.example.com/api" - export PREFECT_API_AUTH_STRING="my-user:my-pass" - Check: prefect work-pool ls - Inspect: prefect work-pool inspect gcr-pool - Look at Type. If it’s not cloud-run, delete and recreate it. 2) Recreate the pool as push type (cloud-run) - Delete the wrong pool: - prefect work-pool delete gcr-pool - Create the correct push pool: - prefect work-pool create gcr-pool --type cloud-run - Get the default template: - prefect work-pool get-default-base-job-template --type cloud-run --file cloud-run-template.json 3) Fill the Cloud Run base job template In cloud-run-template.json set: - region: e.g., us-central1 - image: gcr.io/YOUR_PROJECT/your-image:tag - service_account_name: the runtime SA the Cloud Run Job will use - env: - PREFECT_API_URL=https://your-prefect.example.com/api - PREFECT_API_AUTH_STRING=my-user:my-pass - vpc_connector_name: only if your API is private and requires a Serverless VPC Connector - credentials: - Leave empty if your server pod uses GKE Workload Identity with a GSA that has permissions - Otherwise paste a minimal JSON key for a GSA with Cloud Run permissions Update the pool: - prefect work-pool update gcr-pool --base-job-template cloud-run-template.json - Ensure it’s active: - prefect work-pool resume gcr-pool 4) Ensure your deployment targets the pool - prefect deployment ls - prefect deployment inspect <deployment-name> - work_pool_name should be gcr-pool - If not, redeploy with the correct pool: - prefect deploy (or via Python: flow.from_source(...).deploy(..., work_pool_name="gcr-pool")) 5) Trigger a run and watch for errors - prefect deployment run <deployment-name> - Tail server logs (Kubernetes): - kubectl logs -f <prefect-server-pod> If the server can’t create a Cloud Run Job, you’ll see a clear error (permissions, invalid region/SA/template). 6) Sanity-check the server’s GCP permissions If using Workload Identity: - Your server KSA is annotated with iam.gke.io/gcp-service-account: <gsa>@<project>.iam.gserviceaccount.com - That GSA has: - roles/run.developer (or run.admin) - roles/iam.serviceAccountUser on the runtime SA set in service_account_name - Artifact Registry read for private images Optional: try provisioning again (should work now) - prefect work-pool provision-infrastructure gcr-pool Why this happened - The “not a push pool” message only appears when the pool type isn’t one of the serverless push types. Cloud Run requires a push pool, so recreating it as --type cloud-run is the critical fix. Having zero “workers” is normal for push pools. References - Cloud Run serverless guide: https://docs.prefect.io/v3/how-to-guides/deployment_infra/serverless#google-cloud-run-4 - GCP worker/Cloud Run specifics: https://docs.prefect.io/v3/integrations/prefect-gcp/gcp-worker-guide - Self-hosted server CLI config: https://docs.prefect.io/v3/how-to-guides/self-hosted/server-cli - Server Helm: https://docs.prefect.io/v3/advanced/server-helm If you paste: - prefect work-pool inspect gcr-pool - prefect deployment inspect <name> - Any errors from the server pod when you trigger a run I’ll tell you exactly what’s still blocking Cloud Run job creation.

I get why it feels that way, but no — you do not need to run a worker for Cloud Run in Prefect 3. Cloud Run is a push/serverless work pool type and it is supported with self-hosted Prefect 3. The server submits Cloud Run Jobs directly; there is no worker process for cloud-run. Your error means the pool you created isn’t actually a push pool. Evidence you can verify locally - The CLI knows about cloud-run push pools and their template: - prefect work-pool get-default-base-job-template --type cloud-run - Push pool provisioners exist in OSS: - CloudRunPushProvisioner is in prefect.infrastructure.provisioners.cloud_run Docs - Serverless (Cloud Run): https://docs.prefect.io/v3/how-to-guides/deployment_infra/serverless#google-cloud-run-4 - Work pools (push vs hybrid): https://docs.prefect.io/v3/concepts/work-pools - GCP specifics: https://docs.prefect.io/v3/integrations/prefect-gcp/gcp-worker-guide What likely happened - Your work pool “gcr-pool” was created with a non-push type (e.g., docker/kubernetes/process). That’s why provision-infrastructure says “not a push pool” and why runs go Late: there’s no worker (by design), but the pool isn’t push, so the server won’t submit anything. Fix it step-by-step 1) Make sure your CLI points at your self-hosted API (not Prefect Cloud) - export PREFECT_API_URL="https://your-prefect.example.com/api" - export PREFECT_API_AUTH_STRING="my-user:my-pass" - Verify: - prefect work-pool ls - prefect work-pool inspect gcr-pool Check Type. If it’s not cloud-run, proceed. 2) Recreate the pool as cloud-run (push) - Delete the wrong one: - prefect work-pool delete gcr-pool - Create as push: - prefect work-pool create gcr-pool --type cloud-run - Pull and edit the base job template: - prefect work-pool get-default-base-job-template --type cloud-run --file cloud-run-template.json Set: - region, image, service_account_name - env: - PREFECT_API_URL=https://your-prefect.example.com/api - PREFECT_API_AUTH_STRING=my-user:my-pass - vpc_connector_name if your API is private - credentials: omit if using GKE Workload Identity on the server; otherwise add a minimal GSA JSON - Update pool template and resume if paused: - prefect work-pool update gcr-pool --base-job-template cloud-run-template.json - prefect work-pool resume gcr-pool 3) Ensure your deployment targets that pool - prefect deployment inspect <name> (work_pool_name should be gcr-pool) - If not, redeploy with the correct pool. 4) Verify the server can submit and the scheduler is awake - Trigger a run: - prefect deployment run <name> - Watch server logs (in GKE): - kubectl logs -f <prefect-server-pod> If submission fails (permissions, bad region/SA/template), you’ll see the error. 5) Sanity-check GCP permissions (for server-side submission) - If using Workload Identity: the server pod’s KSA must be annotated to a GSA with: - roles/run.developer (or run.admin) - roles/iam.serviceAccountUser on the runtime SA you set in service_account_name - Artifact Registry read if image is private If you truly want to use a worker, that’s fine — but that’s for hybrid/pull pools (process, docker, kubernetes). A kubernetes worker won’t create Cloud Run Jobs; it will run your flow in K8s. For Cloud Run, use the push pool. If you paste: - prefect version (CLI) and the Prefect image version in your Helm chart - prefect work-pool inspect gcr-pool - Any errors from the server logs when you trigger a run I’ll point out the exact misconfiguration. Otherwise, I’ll assume your pool’s type was “existential dread” instead of “cloud-run.”

I hear you. Two things can be true at once: - Cloud Run is a push/serverless pool type in Prefect 3 and works with self-hosted Server. - Your CLI saying “not a push pool type” while the pool shows type=cloud-run is a strong hint of a version/mismatch problem, not that push pools don’t exist. What “not a push pool type” usually means in practice - The CLI and server don’t agree on push types because they’re on different Prefect versions, or you’re using a CLI that doesn’t include the Cloud Run provisioner mapping yet. - Provisioning is optional anyway. It’s just a preflight to catch missing permissions/config. The real issue is your runs are “Late”, which means the server isn’t starting them. Let’s fix the real problem (Late) and the confusing error. 1) Align CLI and Server versions - On your laptop/CI: - pip install -U prefect - prefect version - In your Helm values for the server, pin the same Prefect image tag as your CLI (or upgrade both to the latest 3.x). Then: - helm upgrade --install <release> prefect/prefect-server -f values.yaml Why: mismatched versions lead to oddities like “not a push pool type” when the type is cloud-run. 2) Make sure the pool is active and complete - Check status and resume if needed: - prefect work-pool inspect gcr-pool - prefect work-pool resume gcr-pool - Ensure the pool’s base job template has required variables set: - region - image - service_account_name (Cloud Run runtime SA) - env: - PREFECT_API_URL=https://your-prefect.example.com/api - PREFECT_API_AUTH_STRING=my-user:my-pass - vpc_connector_name if your API is private - credentials left empty if you’re using GKE Workload Identity on the server; otherwise add a minimal GSA JSON with Cloud Run permissions - If you’re unsure, dump the default, edit, and update: - prefect work-pool get-default-base-job-template --type cloud-run --file cloud-run-template.json - prefect work-pool update gcr-pool --base-job-template cloud-run-template.json 3) Confirm your deployment targets gcr-pool - prefect deployment inspect <deployment-name> - If not, redeploy with work_pool_name="gcr-pool" (via Python deploy or prefect deploy). 4) Verify the scheduler is running on your server - If the scheduler isn’t running, everything goes Late. - In the server pod: - kubectl exec -it <prefect-server-pod> -- bash -lc "prefect server services list-services" You should see Scheduler listed and running. - Also check logs: - kubectl logs -f <prefect-server-pod> You should see periodic scheduling activity. If you see crashes or no scheduler, fix the server deployment. 5) Sanity-check server’s GCP permissions (for actually creating Cloud Run Jobs) If using GKE Workload Identity (recommended): - The server pod’s KSA must be annotated with: - iam.gke.io/gcp-service-account: <gsa>@<project>.iam.gserviceaccount.com - That GSA must have: - roles/run.developer (or run.admin) - roles/iam.serviceAccountUser on the runtime SA you specify in service_account_name - Artifact Registry read if your image is private If you’re not using Workload Identity: - Provide a GSA key (JSON) in the pool credentials field or mount it in the server pod and set GOOGLE_APPLICATION_CREDENTIALS. 6) Trigger a run and watch the server logs - prefect deployment run <deployment-name> - kubectl logs -f <prefect-server-pod> If submission fails, the logs will contain the actual reason (permissions, invalid template, region issues). If nothing happens at all and it still goes Late, your scheduler is the culprit. About “provision-infrastructure” - Once you upgrade the CLI to a version that recognizes cloud-run as a push type (in lockstep with your server), this should stop complaining. - But it is not required to run flows. It’s just a helpful check. References - Cloud Run serverless guide: https://docs.prefect.io/v3/how-to-guides/deployment_infra/serverless#google-cloud-run-4

- GCP specifics and variables: https://docs.prefect.io/v3/integrations/prefect-gcp/gcp-worker-guide - Self-hosted server CLI config: https://docs.prefect.io/v3/how-to-guides/self-hosted/server-cli - Server Helm: https://docs.prefect.io/v3/advanced/server-helm If you share: - prefect version (CLI) and the Prefect image tag in your Helm chart - prefect work-pool inspect gcr-pool (full variables section; redact secrets) - prefect deployment inspect <name> - A snippet of server logs when you trigger a run I’ll tell you exactly which piece is blocking Cloud Run job creation. Otherwise, I’ll assume your scheduler and your CLI are having a quiet disagreement about what constitutes “push.”

I believe you that nothing is running. The symptoms point to two separate things at once: - Your pool is cloud-run (good), but the CLI message about “not a push pool” is likely a CLI/server bug or mismatch in 3.4.10. That command is optional anyway. - The real issue is why your runs are Late. That happens when the server refuses or fails to submit the Cloud Run Job. Let’s stop wrestling the optional provision command and validate the pieces that actually cause job submission. Checklist to force this to surface the real error 1) Validate the pool template is complete - Dump the default to compare: - prefect work-pool get-default-base-job-template --type cloud-run --file cloud-run-default.json - Your pool’s base job template must have at least: - region: e.g., us-central1 - image: gcr.io/YOUR_PROJECT/your-image:tag - service_account_name: runtime SA email that Cloud Run should use - env: - PREFECT_API_URL=https://your-prefect.example.com/api - PREFECT_API_AUTH_STRING=my-user:my-pass - vpc_connector_name: only if your API is private and requires a Serverless VPC Connector - credentials: empty if using GKE Workload Identity on the server; otherwise a minimal GSA JSON - Update and resume: - prefect work-pool update gcr-pool --base-job-template cloud-run-template.json - prefect work-pool resume gcr-pool 2) Preview what Prefect will actually submit (catches missing fields) - prefect work-pool preview gcr-pool If preview fails or shows blanks for region/image/service_account_name, that’s your culprit. Fill them in and update again. 3) Confirm the deployment points to the pool - prefect deployment inspect <deployment-name> - work_pool_name should be gcr-pool If not, redeploy to that pool. 4) Trigger a run now and watch the server logs for the real error - prefect deployment run "<deployment-name>" - In GKE: - kubectl logs -f <prefect-server-pod> Look for errors mentioning CloudRun, permissions, invalid template, missing fields, or HTTP 403 from GCP. This is the authoritative truth about why the job isn’t being created. Common failure reasons I see in self-hosted + Cloud Run - Missing required variables in the pool template (region, image, service_account_name). Result: server refuses to submit, run goes Late. The error will be in the server logs. - Server has no GCP permissions. Workload Identity not actually wired (KSA ↔️ GSA binding missing) or GSA lacks roles: - roles/run.developer (or run.admin) - roles/iam.serviceAccountUser on the runtime SA you specified - Artifact Registry read for private images - Cloud Run API not enabled in the project or region not supported for Jobs. The server logs will show the GCP error. - Basic auth wasn’t included in the job env (PREFECT_API_AUTH_STRING), so even if the job started it couldn’t report back. That doesn’t block job creation, but it will show up as immediate comms failure after start. Still worth setting correctly. About “provision-infrastructure says not a push pool” - Given your type=cloud-run, that message is a red herring. It’s not required to run flows. In 3.4.10 there have been cases where the CLI’s push-type check disagrees with reality. Ignore it for now; the preview + server logs will tell us what’s actually wrong. If you can share three things, I’ll pinpoint it: - Output of: prefect work-pool preview gcr-pool - Output of: prefect deployment inspect <deployment-name> - 30–50 lines from the server pod logs immediately after prefect deployment run "<deployment-name>" If everything is set and you still get Late with no Cloud Run errors in logs, I’ll be genuinely impressed. And also very confused.