Google Cloud Run Worker Pools Reach GA With Open-Source CREMA Autoscaler and Blackwell GPU Support
Google Cloud Run Worker Pools hit general availability on April 14, 2026, shipping with Blackwell GPU support and CREMA, an open-source KEDA-based autoscaler for queue-driven workloads.
Overview
Google Cloud made several significant announcements in the days before its Cloud Next 2026 conference opened on April 22, shipping a cluster of generally available features that together position Cloud Run as a credible platform for background compute workloads that have historically lived on Kubernetes or bare virtual machines. On April 14, Cloud Run Worker Pools reached general availability, followed one day later by the GA of the Cloud Run remote MCP server. The NVIDIA RTX PRO 6000 Blackwell GPU — the first Blackwell-generation GPU available on the platform — had reached GA on April 13, extending GPU support to services, jobs, and the new worker pools alike.
What We Know
Worker Pools: pull-based compute without HTTP
Cloud Run has long been optimized for HTTP request-driven workloads: a container receives a request, processes it, and returns a response. Worker pools invert that model. As Google’s blog describes them, worker pools are “built for continuous, non-HTTP, pull-based background processing.” Instances maintain persistent, long-lived connections to upstream queues — Pub/Sub, Kafka, Redis task queues, or GitHub Actions runners — and pull work rather than waiting for traffic to arrive.
The architectural difference carries security implications too. Unlike regular services, worker pools “don’t require public HTTP endpoints,” which Google notes “reduces the network attack surface and simplifies application code, as you no longer need to manage ports for health checks.”
Deployment semantics are also distinct. Canary rollouts in worker pools split instances rather than traffic: in a four-instance pool, a team can route 25 percent of capacity — one instance — to a new revision while 75 percent remain on the stable build.
Pricing reflects the always-on nature of the workload. Google charges up to 40% less for CPU and memory on worker pools compared with instance-billed Cloud Run services.
CREMA: open-source autoscaling via KEDA
Because worker pools pull work rather than receiving it, the standard Cloud Run autoscaler — which counts inbound HTTP requests — cannot determine the appropriate instance count. To fill that gap, Google has open-sourced the Cloud Run External Metrics Autoscaler (CREMA), which “leverages KEDA to provide autoscaling for Cloud Run services and worker pools based on external metrics (such as Kafka lag, Pub/Sub queue depth, or Prometheus).”
CREMA v1.1, compatible with KEDA v2.19, supports eight verified scalers at launch: Apache Kafka, GCP Pub/Sub, GitHub Runner Scaler, Prometheus, RabbitMQ Queue, Redis Lists, Temporal, and Cron. The tool polls the chosen metric source, calculates a recommended instance count, and updates the worker pool via the Cloud Run Admin API. A memory leak present in builds before April 29, 2026 has been patched.
Blackwell GPUs: 96 GB of VRAM, 5-second cold start
The NVIDIA RTX PRO 6000 Blackwell GPU brings 96 GB of VRAM to Cloud Run, with drivers pre-installed. According to Google’s documentation, “Cloud Run instances with an attached L4 or NVIDIA RTX PRO 6000 Blackwell GPU with drivers pre-installed start in approximately 5 seconds.” Each Blackwell instance requires a minimum of 20 vCPUs and 80 GiB of memory. At GA, the GPU is available on-demand in us-central1, europe-west4, asia-southeast1, and asia-south2.
The RTX PRO 6000 is positioned for teams serving large language models. Google’s Next 2026 blog post highlights the ability to “serve 70B+ parameter models without having to manage any underlying infrastructure, including scaling to zero when the resource is not in use.”
Ajay Nair, Global VP at Elastic, described the operational impact: “Cloud Run has fundamentally changed how we manage our model deployments. By moving to a usage-based, scale-to-zero model, we’ve eliminated idle GPU costs for low-traffic models. We are now running over 17 model variants in production across multiple regions, each independently deployable and isolated, without the burden of capacity planning or fleet management.”
Early adoption: Estée Lauder and the Jo Malone AI Scent Advisor
The Estée Lauder Companies is among the earliest production users of worker pools, deploying the technology to power the Jo Malone London AI Scent Advisor. The architecture uses a producer-consumer split: a FastAPI service running on Cloud Run publishes user messages to Pub/Sub instantly, while worker pool instances continuously pull those messages and chain multiple LLM calls — conversational discovery, deterministic scoring, and copy generation — without exposing that pipeline to the HTTP request model.
Chris Curro, Principal Machine Learning Engineer at The Estée Lauder Companies, described the decision: “Cloud Run worker pools was exactly the right primitive, and working directly with the product team as early adopters gave us the confidence to build on it ahead of GA. It’s now the foundation for us to bring AI advisors to brands across the Estée Lauder Companies portfolio.”
The team reports 100% message durability through Pub/Sub buffering and describes operational overhead as minimal: engineers focus on product rather than server management.
Cloud Run platform trajectory
The GA releases arrive as the Cloud Run platform is growing rapidly. Google reported at Cloud Next 2026 that external active developers and applications on Cloud Run doubled year-over-year, and that Cloud Run added more new customers and applications in 2025 than in its first six years combined. Replit, which hosts over 1 million live projects on Cloud Run, and Anthropic, whose infrastructure relies on Cloud Run’s scale-to-zero model, were cited as representative production users.
What We Don’t Know
Google has not published pricing for RTX PRO 6000 Blackwell instances on worker pools specifically, beyond the general statement that worker pools cost up to 40% less than request-billed services. It is also not yet clear when CREMA will evolve beyond its current open-source, self-deployed model into a fully managed autoscaling service integrated directly with the Cloud Run console. Google has indicated billing caps and Cloud Run service bindings are “coming soon” but has not announced dates.
Analysis
The combination of worker pools, CREMA, and Blackwell GPU support removes three of the main reasons engineering teams have historically reached for Kubernetes when building background processing pipelines or AI inference workloads on Google Cloud. Worker pools provide the pull-based execution model; CREMA provides the queue-depth-aware autoscaling that Cloud Run’s built-in scaler cannot supply; and Blackwell GPUs provide the raw inference capacity, with a 5-second cold start that narrows the gap with always-hot GPU fleets.
The 40% cost reduction relative to instance-billed services is meaningful for teams running persistent background workers, but the self-deployment requirement for CREMA introduces operational complexity that a managed equivalent would eliminate. Until Google integrates queue-aware autoscaling natively into Cloud Run’s control plane, teams adopting worker pools will need to operate and monitor CREMA themselves — a real but bounded cost compared with managing a Kubernetes cluster.