The open-source Temporal execution platform is rapidly becoming a foundational layer of modern software infrastructure — especially for orchestration in distributed systems and AI agent workloads. However, deploying and scaling workers in Temporal comes with unique challenges. Workers poll for tasks instead of serving requests, so request-driven serverless platforms can be an awkward fit. This often results in running worker fleets on Kubernetes or VMs, which you have to manage and pay for continuously. You build a metrics pipeline and tune autoscaling triggers, and scaling still trails bursts because of metrics lag. Every deployment means juggling upgrades and versions, and you pay for that compute whether or not there's work in the queue.

We built Cloud Run worker pools for exactly this kind of pull-based work: Your instances connect to a queue or stream, take the next item, and process it. Starting today, Temporal Cloud , which is the fully managed version of Temporal’s open-source platform, can scale them for you. Currently in preview, Temporal Serverless Workers on Cloud Run let you deploy your workers as a worker pool, and Temporal sizes the pool to match the work on your task queues. When there's no work, it can scale the pool to zero. There's no cluster or autoscaler to run, and your worker code stays the same.

A worker pool is Cloud Run's resource for continuous background work. It has no public endpoint, and each instance is allocated CPU for its whole lifetime, which matches how a Temporal worker runs. Temporal manages your Cloud Run worker pools as follows:

Your Temporal workers run as Cloud Run worker pool instances in your project and poll Temporal Cloud for tasks.

Temporal Cloud tracks your task queues and sets the worker pool's instance count through the Cloud Run Admin API, using the IAM permissions you grant. Temporal never opens a connection to your instances, so you don't need to open ports or add firewall rules for it.

You run each build version as its own Cloud Run worker pool. An older build's worker pool can sit at zero instances until a workflow that started on it needs it again.

Your Temporal workers run in your project, under your service account, and on your network. Temporal decides how many of them run.

The combination of Cloud Run worker pools with Temporal Serverless Workers opens up a variety of interesting use cases: