Cloud Run sandboxes now work inside jobs and worker pools

Google Cloud extended Cloud Run sandboxes to jobs and worker pools on August 5, 2026. Sandboxes had entered public preview for Cloud Run services in July; the expansion means the same isolated code-execution primitive can now be used in run-to-completion jobs and continuous pull-based worker pools. Google documents the sandbox as running inside the same Cloud Run instance as the trusted container while maintaining an isolation boundary for untrusted code.

Many agent and automation workloads do not fit an HTTP request model. Code-generation tasks, data transforms and evaluation runs may be batch jobs, while queue consumers and long-running agents often live in worker pools. Extending the sandbox to those resource types reduces the need to operate a separate microVM or container-cluster isolation layer just to execute untrusted payloads. The trade-offs are important: the feature is still Preview, shares the host instance’s CPU and memory allocation, and does not remove the need to control the trusted container’s own IAM and external credentials.

Google announced Cloud Run sandboxes in public preview in July for services, positioning them as an isolation layer for AI-generated code and other untrusted binaries. On August 5, Cloud Run release notes expanded sandbox support to all resource types, including jobs and worker pools. That opens the primitive to scheduled or run-to-completion work and to continuous non-HTTP workers.

Cloud Run jobs can enable the sandbox launcher through gcloud or YAML. Google explicitly calls out agent code, data transformations and scripts as use cases. The sandbox runs within the job instance and shares its allocated CPU and memory, so builders need to size the host for both trusted orchestration and sandboxed execution.

Worker pools are designed for continuous pull-based work such as queue consumers and other non-HTTP workloads. Sandboxes can now be enabled on those pools as well, allowing an always-on trusted worker to launch isolated executions for untrusted payloads without handing those payloads the worker process itself.

The sandbox boundary is only one layer. The host container still has its Cloud Run service identity, networking and any external credentials the application gives it. Builders should keep sensitive orchestration and secret-bearing logic in the trusted container, expose the minimum interface to sandboxed code and treat Preview semantics and support guarantees as changeable.