Key takeaways
-
- Google Cloud and Temporal launched Temporal Serverless Workers on Cloud Run worker pools in public preview, allowing pull-based background workers to scale to zero instances.
- The Temporal Worker Controller Instance (WCI) monitors queue backlog latency to provision compute capacity ahead of demand, targeting an 80% utilization rate.
- Cloud Run worker pools eliminate HTTP listener workarounds and list at roughly 40% less per vCPU-hour and memory-hour than standard instance-billed Cloud Run services.
- Deterministic workflow execution is preserved through Temporal Worker Versioning, deploying distinct worker pools per build ID with pinned or auto-upgrade routing.
Temporal Technologies and Google Cloud have introduced Serverless Workers for Google Cloud Run in public preview. The managed capability connects Temporal Cloud’s workflow orchestration engine directly to Google Cloud Run worker pools, allowing pull-based worker fleets to scale dynamically with task queue backlog volume and drop to zero instances when queues drain. Rather than maintaining dedicated Kubernetes clusters or virtual machine fleets to poll task queues, platform engineering teams can deploy containerized workers into customer-owned Google Cloud projects while delegating autoscaling to Temporal Cloud. The system monitors backlog queue latency rather than container CPU utilization to provision instances ahead of incoming traffic bursts.
Decoupling Temporal Workers from Always-On Compute
Deploying distributed workflow workers on serverless infrastructure has historically presented an architectural mismatch. Traditional serverless platforms operate on a request-driven model, assuming containers listen on a network port for incoming HTTP traffic. Temporal workers, by contrast, operate via pull-based polling: client instances establish outbound connections to Temporal Cloud to retrieve tasks from designated task queues. Adapting workers to standard Cloud Run services previously required running dummy HTTP listeners to pass health checks, enabling instance-based billing, and setting minimum instance floors to prevent aggressive scaling to zero mid-task.
Operating outside serverless environments created separate operational overhead. Running worker fleets on Google Kubernetes Engine (GKE) or Compute Engine virtual machines required teams to maintain dedicated autoscaling pipelines. Because traditional horizontal pod autoscalers often scale after metric collection intervals register compute saturation, instance provisioning regularly trailed processing bursts. Teams paid for idle compute between batch runs or overnight quiet periods to preserve readiness.
Cloud Run worker pools resolve this structural friction by providing a dedicated resource for continuous background workloads without exposing a public endpoint, listening port, or load balancer. Instances receive allocated CPU throughout their entire execution lifetime rather than facing throttling during polling pauses.
| Operational Factor | Cloud Run Services (Standard) | Cloud Run Worker Pools |
|---|---|---|
| Workload Pattern | Request-driven HTTP services | Pull-based background consumers |
| Endpoint Requirement | Requires ingress port and public or private URL | No public endpoint, ingress port, or load balancer |
| CPU Allocation | Throttled between requests unless instance-billed | Dedicated CPU allocated for full container lifetime |
| Compute Pricing | Standard request or instance billing rates | Lists at ~40% less per vCPU-hour and GB-hour |
| Fleet Scaling | Instance adjustments trigger revision updates | Resizes instance count without revision churn |
Queue-Latency Autoscaling and the Worker Controller
The scaling mechanism between Temporal Cloud and Cloud Run relies on queue-level latency metrics rather than localized host resource telemetry. The Temporal server monitors backlog-to-worker latency—the exact duration a task spends queued before an active worker claims it. When this latency metric crosses trigger thresholds, Temporal sends push notifications to an internal Worker Controller Instance (WCI).
According to Temporal technical documentation, the Worker Controller Instance provisions worker pool capacity to target an 80% default utilization rate. Whenever a synchronous task match failure occurs—indicating zero workers were immediately available to claim an enqueued task—the WCI triggers rapid instance additions via the Google Cloud Run Admin API. Capacity adjustments execute using customer-granted Google Cloud Identity and Access Management (IAM) service account roles. Temporal Cloud communicates exclusively through Cloud Run control plane APIs and never opens inbound connections to running worker containers.
Scale-in operations apply dampening rules to avoid fleet thrashing. Temporal enforces a default 90-second stabilization window following the last unassigned task before scheduling capacity reductions, spacing sequential scale-downs across conservative intervals. For executing workers, Cloud Run’s configurable graceful shutdown extends the termination grace period from the default 10 seconds up to 10 minutes, giving SIGTERM-aware workers sufficient runway to complete or checkpoint in-flight workflow activities.
Worker Versioning and Operational Trade-Offs
Temporal workflows are stateful and deterministic; replaying event histories against altered workflow code can trigger fatal non-determinism errors. To prevent execution corruption during rolling deployments, Serverless Workers on Cloud Run enforce Temporal Worker Versioning. Platform teams deploy each container image version as an independent Cloud Run worker pool labeled with a distinct deployment name and build ID.
Workflows route across versions using two explicit operational policies:
- PINNED: Workflows remain bound to the specific build ID on which they began execution until completion. This strategy protects short-running workflows, payment transactions, and multi-step API integrations from runtime code drift.
- AUTO_UPGRADE: Workflows automatically advance to designated target versions as updates roll out, allowing multi-week entity workflows and recurring subscription billing tasks to adopt new business logic safely.
Because each build ID functions as an isolated Cloud Run worker pool, legacy worker versions scale to zero instances when their active workflow executions finish. Platform teams avoid paying for idle infrastructure while supporting backward compatibility for lingering workflow executions.
This isolation model also benefits emerging agentic AI architectures. Multi-step LLM reasoning chains, vector embedding generation, and tool invocations can run on worker pools configured with attached GPUs and keyless Google Cloud IAM access to model APIs. The worker pool expands during batch reasoning spikes and scales down to zero when tool-calling queues empty.
However, serverless architectures introduce cold-start latency trade-offs. While the WCI provisions ahead of demand, new container instances require initialization time to start, pull configurations, and begin task polling. Organizations operating latency-critical task queues that cannot accommodate cold-start delays must configure a minimum instance count above zero.
What happens next
Temporal Serverless Workers on Cloud Run is currently in public preview. Because the feature remains in preview, Google Cloud and Temporal may refine API specifications, controller scaling intervals, and configuration schemas prior to general commercial availability.
Platform teams evaluating the integration can deploy their initial worker pool through three setup steps:
- Containerize the Temporal worker application and deploy it as a Google Cloud Run worker pool with the build ID embedded in the pool resource name, storing Temporal Cloud API keys in Secret Manager.
- Assign Temporal Cloud’s service principal the necessary IAM roles to manage instance counts via the Cloud Run Admin API.
- Register a Worker Deployment Version in Temporal Cloud pointing to the target Google Cloud project ID, region, and worker pool name.
Engineering teams planning migrations should verify that worker containers handle SIGTERM signals cleanly, assess task queue latency tolerances against cold-start metrics, and test version drainage across active workflows before decommissioning existing virtual machine or Kubernetes worker fleets.
