Google Cloud Run Worker Pools Reach General Availability
Google Cloud announced that Cloud Run worker pools are now generally available, bringing a purpose-built resource type for pull-based, non-request-driven workloads to the fully managed serverless platform. Unlike Cloud Run services — which spin up in response to HTTP traffic and scale to zero — worker pools are "always-on" environments designed for tasks that continuously pull from queues, run background AI inference, or handle distributed training workloads without an inbound request trigger. The GA release adds NVIDIA L4 and RTX PRO 6000 Blackwell GPU support, making worker pools viable for serverless LLM inference and distributed model fine-tuning jobs.
The cost efficiency story is notable: worker pools are approximately 40% cheaper than equivalent request-driven Services or Jobs for long-running background workloads, because they avoid the cold-start and scaling overhead optimized for latency-sensitive request handling. This positions Cloud Run worker pools as a direct competitor to Kubernetes job queues and managed batch services for teams that want serverless operational simplicity without the per-request pricing model. Native integrations with Pub/Sub, Kafka, GitHub Actions Runners, and Redis task queues are supported at GA, enabling seamless migration from manually managed worker fleets.
The Estée Lauder Companies is cited as an early production adopter, running distributed supply chain processing workloads on worker pools at scale. For development teams that have been workarounding Cloud Run's request-driven model with Cloud Tasks or Cloud Scheduler hacks to run background jobs, worker pools provide a first-class solution that doesn't require maintaining Kubernetes clusters or GKE node pools.
Read more — Google Cloud Blog
Docker AI Governance Brings Centralized Control for Agent Deployments
Docker announced Docker AI Governance on May 12, 2026, a centralized control plane for organizations deploying AI agents and autonomous workflows (including "Claws" — always-on background agents that act across business applications). The product addresses the fundamental governance gap that emerges when multiple developers run AI agents with different permission scopes across laptops, CI runners, and production clusters: there is no consistent enforcement layer below the agent itself.
Docker AI Governance manages four control planes simultaneously: network and filesystem access (allow/deny rules for domains, IPs, CIDRs, and filesystem mounts with read-only or read-write scoping), credential access (which tokens and secrets agents may use, scoped to session duration, with exfiltration blocked at the runtime level), MCP tool availability (organization-wide policies controlling which MCP servers agents can call, with unapproved servers blocked by default), and role-based access via SAML/SCIM integration (team-specific policy layers on top of organization-wide guardrails). Structured event logs ship to SIEM and compliance systems for auditability.
The design principle is "governance invisible to developers, visible to admins": a developer running an agent on their laptop gets the same policy enforcement as the same agent running in a CI pipeline or a production job, without having to configure anything. For organizations operating in regulated environments (financial services, healthcare, government), this shifts AI agent security from a developer discipline to an infrastructure control — analogous to how IAM policies govern cloud resource access regardless of which developer wrote the service.
Read more — Docker Blog
Apigee Emulator v2.0.0 Released Independently from Hybrid
Google Cloud released Apigee Emulator v2.0.0 on May 22, 2026, marking the first version of the emulator that is versioned and released independently from Apigee hybrid. Previously, emulator updates — including security patches — were bundled with Apigee hybrid releases, creating delays between vulnerability discovery and fix delivery whenever the hybrid cycle was not ready to ship. Starting with v2.0.0, the emulator follows its own release cadence, enabling the Apigee team to push security patches and emulator improvements without waiting for a hybrid release window.
The emulator image remains available at gcr.io/apigee-release/hybrid/apigee-emulator and continues to be compatible with Apigee hybrid deployments, but its version number now tracks emulator-specific changes rather than the hybrid version. For development teams who use the emulator in local development environments and CI pipelines, this means faster access to fixes and feature updates without needing to upgrade the full hybrid stack. Apigee MCP (which reached GA earlier in 2026) and the emulator can now be updated on separate tracks, reducing the blast radius of emulator changes in production hybrid deployments.
Teams running Apigee local development workflows with VS Code or IntelliJ should update their apigee-emulator container references to v2.0.0 and configure their update pipelines to pull from the emulator's independent release channel rather than tying the version to hybrid. The decoupling also signals that the Apigee team plans to accelerate emulator-specific features — particularly around local debugging, policy simulation, and MCP tool integration — on a faster cadence than the full platform allows.
Read more — Google Cloud Release Notes
Links & Sources
You May Also Enjoy
