Google Cloud & Temporal launch serverless workers. Fri, 16th Oct 2026 (Today) Google Cloud and Temporal have introduced Temporal Serverless Workers on Cloud Run, now in preview on Temporal Cloud. The offering lets developers run Temporal workers in Cloud Run worker pools that scale with activity in Temporal task queues. Temporal Cloud manages instance counts through the Cloud Run Admin API, while the worker code continues to run in the customer's own Google Cloud project, under the customer's service account and network settings. Temporal is an open-source execution platform for orchestrating distributed systems and AI agent workloads. Its workers poll for tasks rather than wait for incoming web requests, which has often pushed users towards Kubernetes clusters or virtual machines that stay provisioned even when queues are idle. Cloud Run worker pools are designed for background jobs without a public endpoint. In this setup, Temporal workers poll Temporal Cloud for tasks, and Temporal tracks queue conditions before adjusting worker pool size. Scaling model Temporal uses backlog-to-worker latency as its main scaling signal. When the delay between a task entering a queue and a worker picking it up crosses a threshold, the Temporal server notifies a worker controller, which adds capacity to the relevant worker pool. Scale-in is handled more cautiously. Temporal waits through a stabilisation period after the last time a task found no available worker, then reduces capacity in stages rather than cutting instance counts immediately. Instance counts remain within customer-defined minimum and maximum levels. If the first task after an idle period cannot tolerate startup delay, users can keep the minimum above zero. Otherwise, the platform can reduce the pool to zero when no work is pending. A central change is the removal of some workarounds previously needed to run Temporal workers on standard Cloud Run services. Those deployments typically required an HTTP listener, instance-based billing to keep CPU available between requests, and minimum instances to avoid scaling fully down. By contrast, worker pools have no public URL and do not require a load balancer. Google Cloud said they are priced at almost 40% less per vCPU-hour and GB-hour than instance-billed Cloud Run services, while also avoiding revision changes when only instance counts are adjusted. Version control The launch also addresses one of the more difficult aspects of operating Temporal workflows: updating worker code without disrupting running executions. Because Temporal workflows are stateful and deterministic, changing code mid-run can create non-determinism errors. To avoid that, the Cloud Run deployment model requires Temporal Worker Versioning. Each Worker Deployment Version runs as its own worker pool deployment, identified by a deployment name and build ID. Older versions can remain at zero instances until a workflow created on that version needs to run again. This allows workflows that started on one worker version to continue on that same version, while newer workflows are directed to a current or target deployment based on configuration. As older workflow executions drain away, the related worker pool can then be reduced to zero automatically. Two versioning behaviours are available. Under PINNED, a workflow stays on the build ID on which it started. Under AUTO_UPGRADE, a workflow moves to the new current or target Worker Deployment Version during rollout. The companies highlighted several use cases, including AI agents, long-running workflows and batch processing. In AI-related workloads, worker pools can scale up to handle bursts of model calls, embeddings or API activity, then scale down once queues empty. The configuration also supports attaching GPUs to workers, with those GPU-backed workers still able to scale to zero. For long-running workflows, the approach is intended to match uneven compute demand. A workflow may alternate between short tasks, long-running steps and periods of inactivity while waiting for external input from a person or another system. Batch jobs are another target. Since worker pools incur charges only while instances are running, organisations can leave a pool idle at zero between periodic runs such as billing cycles or media transcoding jobs, while using maximum instance limits to cap spend during peaks. Tampi Yellapragada, Product Manager at Google Cloud, wrote that the aim was to align Cloud Run worker pools with systems built around pull-based work rather than request-response patterns: "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." He added: "Starting today, Temporal Cloud, which is the fully managed version of Temporal's open-source platform, can scale them for you."

Temporal has acquired the team behind Oso to build agent authorisation into its execution platform. The move addresses a critical security challenge as AI agents gain access to business-critical systems and data. Research shows 96% of permissions go unused by human employees who exercise judgement, but agents lack this restraint. Temporal's platform already powers agents for OpenAI and Cursor, processing over 5 billion actions monthly across 500 namespaces at Netflix alone. The Oso team will help Temporal implement fine-grained access controls that survive the crashes and retries inherent in production environments. Graham Neray, Oso's founder, said agents' value and danger both stem from their system access, requiring precise developer controls. The announcement follows Temporal's September 2026 Series E funding round, which raised $550 million.