Deploying and scaling Temporal workers is awkward on request-driven serverless platforms because workers poll for tasks rather than serving requests. Teams end up running worker fleets on Kubernetes or VMs, paying continuously, building metrics pipelines, and still lagging behind bursts due to metrics lag. Cloud Run worker pools are designed for this pull-based work: instances connect to a queue or stream, take the next item, and process it. The new preview, Temporal Serverless Workers on Cloud Run, lets Temporal Cloud manage those worker pools directly. Temporal tracks task queues and sets the pool’s instance count via the Cloud Run Admin API using IAM permissions you grant, and it never opens a connection to your instances. Workers run in your project, under your service account, on your network, while Temporal decides how many run. Each build version lives in its own worker pool; an older build can stay at zero instances until a workflow that started on it needs it again.

Three use cases are highlighted. Autoscaled agentic workers: AI agents running multi-step chains of LLM reasoning and tool calls use Temporal’s durable execution, with workers spinning up instantly for LLM steps, embeddings, or API calls, then scaling to zero. Workers get keyless access to Google Cloud AI APIs and can attach GPUs for inference, with GPU workers still scaling to zero. Temporal runs each model and tool call as a durable activity, so if a worker disappears mid-step, the activity retries on another worker. Long-running Workflows use the Entity Pattern, where a workflow represents the state of a real-world resource. Compute needs vary: short steps, long steps, or sleeping while waiting for human or external input. Worker pools provide flexible compute, with individual steps able to run as long as needed and Temporal scaling the pool down when no work remains. Bursty batch work: since worker pools bill only while instances run, an idle pool at zero costs nothing. For billing runs or media transcoding, Temporal scales the pool out as batches arrive and back in once the queue drains, and your maximum instance count caps what you pay for; extra tasks wait in the queue rather than being dropped.

Previously, running Temporal workers on Cloud Run services required workarounds: an HTTP listener, instance-based billing that kept CPU between requests, and minimum instances to avoid scaling to zero. Worker pools remove those: there is no endpoint or load balancer to lock down, no health-check port, and instances don’t idle or throttle. Worker pools list at almost 40% less per vCPU-hour and GB-hour than instance-billed Cloud Run services. Changing the instance count doesn’t create a new revision, so Temporal can resize the pool as often as load changes.

Temporal sizing is driven by one main signal: the delay between a task landing in the task-queue backlog and a worker picking it up. The server detects growing latency, sends a push notification to a worker controller, and the controller adds capacity. Because new instances take time to start and connect, Temporal keeps spare capacity so the pool grows ahead of demand. Scale-in is more conservative: it waits for a stabilization period after the last time a task found no available worker (90 seconds by default) and pauses between reductions. Cloud Run’s configurable graceful shutdown extends from 10 seconds to 10 minutes, giving SIGTERM-aware workers time to finish or checkpoint. The instance count stays between a minimum and maximum you set; if the first task after an idle period can’t wait for an instance to start, set the minimum above zero.

Deploying new workflow code without breaking running executions is hard because Temporal workflows are stateful and deterministic. Serverless Workers on Cloud Run require Temporal Worker Versioning. You don’t patch code with conditional branches; instead, each Worker Deployment Version is its own worker pool deployment, identified by deploymentName and buildId. This lets workflows that started on a particular version continue on that version, and lets each version be scaled and drained individually. As workflows complete, the underlying pool is eventually scaled to zero automatically. You set a versioning behavior per workflow type or as a worker-level default: PINNED keeps a workflow on the build ID it started on (best for short-running workflows, order processing, multi-step APIs), while AUTO_UPGRADE moves a workflow to the new current or target version as you roll it out (best for long-running workflows like subscription billing). Setup takes three steps: containerize the Temporal worker and deploy it as a Cloud Run worker pool with the build ID in the pool name, keep credentials like the Temporal API key in Secret Manager, and connect Temporal by granting it permission to manage the pool and creating a Worker Deployment Version pointing at the pool’s project, region, and name. The feature is in preview, so APIs and configuration may change.