Temporal Serverless Workers on Cloud Run: Scale workers ahead of demand
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.
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.
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.
How Cloud Run worker pools fit with Temporal 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.
In context
- Topic: Cloud y Arquitectura — Nube pública, híbrida, costos y decisiones de infraestructura.
- Source: Google Cloud Blog
- Published: 15/10/2026
Continue reading at the original source →
Excerpt published automatically by the site radar. The full text belongs to its publisher and is linked above.
Por qué importa
Después de unos años, casi toda organización que migró a la nube descubre lo mismo: la factura crece más rápido que el negocio. No porque la nube sea cara, sino porque nadie apaga lo que ya no se usa y nadie tiene el incentivo de revisarlo.
Lo que yo miro en estos anuncios es la portabilidad. Mientras más cómoda es una plataforma, más difícil suele ser salir de ella, y esa comodidad se paga en poder de negociación tres años después, justo cuando toca renovar y ya no hay alternativa creíble.
Lo que suele salir mal
Donde suele romperse es en las capacidades del equipo. La plataforma es nueva pero la gente aprendió sobre la marcha, sin tiempo y sin acompañamiento. Terminan replicando en la nube las mismas prácticas del centro de datos, con lo cual se pagan precios de nube por beneficios que nunca llegan.
Qué mirar
- Quién ve la factura y con qué detalle: sin dueño del gasto, el gasto crece solo.
- Dónde quedan físicamente los datos y qué exige la regulación local sobre eso.
- Qué pasa cuando el proveedor tiene una caída, porque la va a tener, y qué queda operando mientras tanto.
Cómo leo esta entrada
Yo lo leería pensando en la salida antes que en la entrada. No porque uno planee irse, sino porque la conversación de cómo saldría es la que revela cuánto se está amarrando. Si nadie en la mesa puede describir ese camino, la dependencia ya es mayor de lo que se cree.
La noticia original está publicada en otro idioma; acá se cita el extracto tal como lo entrega el medio y el comentario se escribe en español.
Comentarios
Todavía no hay comentarios. El primero puede ser el tuyo.
¿Lo estás viviendo en tu equipo?
Abrí el chat y contame cómo lo están manejando. Me interesa comparar notas.
