Temporal Serverless Workers on Cloud Run introduce automatic, demand‑driven scaling for pull‑based Temporal workers. Instead of maintaining Kubernetes clusters or VMs that poll queues continuously, the preview integration lets Temporal Cloud adjust the size of a Cloud Run worker pool in real time, scaling to zero when no work is pending.
How the Integration Works
Cloud Run worker pools are a Cloud Run construct designed for continuous background processing. Each instance receives dedicated CPU for its lifetime and has no public endpoint, matching the execution model of a Temporal worker.
- Worker code is packaged and deployed as a Cloud Run worker pool in the user’s project.
- Temporal Cloud monitors the associated task queues and calls the Cloud Run Admin API to set the desired instance count, using IAM permissions granted by the user.
- Temporal never initiates inbound connections to the instances, so no additional firewall rules or port openings are required.
- Each build version can be deployed to its own worker pool; older versions remain at zero instances until a workflow that started on that version needs to resume.
Operational Benefits and Trade‑offs
Practitioners gain several concrete advantages:
- Cost efficiency: Instances exist only while there are queued tasks, eliminating idle compute charges.
- Instant burst handling: Temporal can spin up new instances as soon as queue depth increases, avoiding the lag inherent in metric‑based autoscaling.
- Simplified lifecycle: No separate autoscaler or cluster management layer; version upgrades are handled by deploying a new worker pool.
- GPU support: Workers can be attached to GPUs for inference workloads and still scale to zero when idle.
Potential considerations include the preview status of the feature, which may affect SLA expectations, and the need to monitor Cloud Run quota limits for rapid scaling events.
Security and Permission Considerations
The model keeps the worker instances within the customer’s project, running under the customer’s service account and network configuration. Temporal Cloud only requires permission to invoke the Cloud Run Admin API to adjust instance counts. Because no inbound connections are opened, the attack surface does not expand beyond the existing Cloud Run permissions model. Practitioners should verify that the granted IAM role follows the principle of least privilege and that service‑account keys are managed according to their organization’s secret‑handling policies.
Related CloudNinjas coverage: Google Cloud.
What This Means For Practitioners
Adopting Temporal Serverless Workers on Cloud Run lets AI engineers, platform engineers, and SREs replace always‑on worker fleets with a demand‑driven, zero‑idle model. Evaluate the preview’s stability for production workloads, audit the IAM role granted to Temporal Cloud, and set up monitoring for Cloud Run instance counts and queue depth to ensure scaling behaves as expected. For security teams, confirm that the service account’s permissions are scoped narrowly and that network policies remain unchanged.
