{"slug": "bringing-gvisor-sandboxes-to-distributed-ray-clusters", "title": "Bringing gVisor sandboxes to distributed Ray clusters", "summary": "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.", "body_md": "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.\n\nRay 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.\n\nWhen 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:\n\nThe 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.\n\nStarting 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:\n\nThis creates a gVisor sandbox from an OCI-compatible image and returns a Ray Actor handle. Calls to `exec`\n\nare 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.\n\nThe [sandbox API](https://docs.ray.io/en/master/ray-core/api/sandboxes.html) covers the basic lifecycle needed by agentic workloads:\n\nCreate environments from OCI container images\n\nSet CPU and memory limits\n\nConfigure environment variables, working directories, and networking\n\nExecute commands\n\nRead, write, upload, and download files\n\nInspect sandbox state\n\nTerminate or delete environments.\n\nFor lower-level use cases, `SandboxRuntime`\n\nprovides 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:\n\nRunning 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.\n\nThis 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.\n\nIn 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.\n\nCheck 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.", "url": "https://wpnews.pro/news/bringing-gvisor-sandboxes-to-distributed-ray-clusters", "canonical_source": "https://cloud.google.com/blog/products/containers-kubernetes/gvisor-sandboxes-for-ray-clusters-on-gke/", "published_at": "2026-08-25 16:00:00+00:00", "updated_at": "2026-08-25 16:12:52.924297+00:00", "lang": "en", "topics": ["ai-infrastructure", "ai-agents", "ai-research", "ai-tools"], "entities": ["Google Cloud", "Anyscale", "Ray", "gVisor", "Agent Substrate", "Kata Containers"], "alternates": {"html": "https://wpnews.pro/news/bringing-gvisor-sandboxes-to-distributed-ray-clusters", "markdown": "https://wpnews.pro/news/bringing-gvisor-sandboxes-to-distributed-ray-clusters.md", "text": "https://wpnews.pro/news/bringing-gvisor-sandboxes-to-distributed-ray-clusters.txt", "jsonld": "https://wpnews.pro/news/bringing-gvisor-sandboxes-to-distributed-ray-clusters.jsonld"}}