Bringing gVisor sandboxes to distributed Ray clusters

Google Cloud and Anyscale announced an experimental library for Ray that brings native gVisor-based sandboxing to distributed Ray clusters, starting in Ray 2.58. The library represents sandboxes as Ray Actors, enabling secure execution of untrusted, model-generated code for agentic and reinforcement learning workloads. It uses gVisor, Google's open-source application kernel, to provide OCI-compatible isolation with sub-second startup and low memory overhead.

The reinforcement learning RL ecosystem is rapidly adopting Ray as the unified compute runtime for complex post-training workflows. Across Google Cloud, we see customers using Ray for workloads ranging from multimodal data pipelines to frontier RL. But as agentic and reasoning models evolve, a critical bottleneck has emerged: orchestrating secure, isolated sandboxes at scale to safely execute dynamic rollouts, code generation, and multi-turn tool interactions. Today, in partnership with Anyscale https://www.anyscale.com/blog/announcing-native-sandboxing-in-ray , we are excited to introduce an experimental library for Ray that leverages agentic AI technologies being developed at Google to bring native, high-performance sandboxing directly into distributed Ray clusters. Ray has become a common runtime for orchestrating post-training workloads. Frameworks including veRL, NeMo-RL, SLIME, MILES, and SkyRL already use Ray to coordinate distributed trainers, inference engines, rollout workers, and other components. When we designed Ray Sandboxing, an important goal was to make it fit naturally into the existing Ray programming model rather than introduce a separate abstraction for isolated execution. A sandbox has many of the same properties as other resources managed by Ray: it needs to be placed on a machine, assigned resources, created and destroyed, recovered from failures, and scaled with the surrounding workload. This led us to represent each high-level sandbox through a Ray Actor: The Ray scheduler decides which node should run a sandbox and reserves the corresponding CPU and memory resources. The sandbox Actor manages its lifecycle, while gVisor provides the isolated execution environment on that node. Starting in Ray 2.58, framework authors and researchers can manage sandboxed environments using the same Ray APIs and patterns they already use for the rest of their workload. For example: This creates a gVisor sandbox from an OCI-compatible image and returns a Ray Actor handle. Calls to exec are normal Ray Actor calls, so the sandbox can live anywhere in the cluster. The created actor is a proxy that will forward the operations to gVisor. The sandbox API https://docs.ray.io/en/master/ray-core/api/sandboxes.html covers the basic lifecycle needed by agentic workloads: Create environments from OCI container images Set CPU and memory limits Configure environment variables, working directories, and networking Execute commands Read, write, upload, and download files Inspect sandbox state Terminate or delete environments. For lower-level use cases, SandboxRuntime provides direct access to local gVisor sandboxes and lets users modify the OCI specification before it is handed to gVisor. Here is an example how this API can be used to build a pool of local sandboxes inside of an actor: Running model-generated code means treating the code inside the environment as untrusted. Ray Sandboxing uses gVisor https://gvisor.dev/ , Google's open-source application kernel, as its initial sandbox runtime. gVisor implements a substantial portion of the Linux system-call interface in userspace, putting an additional isolation boundary between workloads and the host kernel. It is OCI-compatible, works with standard container images, and does not require exposing a Docker daemon or host Docker socket to the sandbox. This combination is particularly useful for agentic workloads: environments remain lightweight enough to create dynamically while providing stronger isolation than executing generated code directly in ordinary containers. gVisor also provides sub-second sandbox startup and low per-sandbox memory overhead, making it possible to use sandboxes as relatively fine-grained distributed resources. In future versions of Ray, we plan to extend support to other sandboxing runtimes such as Agent Substrate https://github.com/agent-substrate/substrate or Kata Containers. Check out the Ray documentation to learn more about Ray Sandboxes https://docs.ray.io/en/master/ray-core/sandboxes.html . To try out these sandboxing capabilities on GKE, head over to the Ray sandboxing User Guide https://docs.ray.io/en/master/cluster/kubernetes/examples/ray-sandboxing.html . Have feedback or ideas? Join the discussion on the GitHub https://github.com/ray-project/ray/issues/65352 issue to collaborate on the future of Ray for reinforcement learning.