Ray Sandboxes Get gVisor Isolation for Safer RL Workloads

Reinforcement learning is getting wilder by the day, and Ray has become the go-to compute runtime for orchestrating complex post-training workflows. But as agentic and reasoning models evolve, a critical bottleneck has emerged: how do you securely execute dynamic rollouts, code generation, and multi-turn tool interactions at scale? Google Cloud and Anyscale have teamed up to answer that with native sandboxing in Ray, powered by gVisor.

Sandboxes as Ray Primitives

Ray is already the backbone for frameworks like veRL, NeMo-RL, SLIME, MILES, and SkyRL, coordinating distributed trainers, inference engines, and rollout workers. The new Ray Sandboxing feature treats sandboxes as first-class citizens in the Ray programming model—no separate abstraction needed. Each sandbox is represented as a Ray Actor, so it gets placed, resourced, created, destroyed, and scaled just like any other workload component.

Starting in Ray 2.58, you can manage sandboxed environments using the same Ray APIs you already know. Here’s a quick taste:

import ray
from ray.experimental import sandbox

ray.init()
sb = sandbox.create(cpu=1.0, memory="512Mi", image="python:3.12-slim")
result = ray.get(sb.exec.remote("python -c 'import sys; print(sys.version)'"))
print(result.stdout)

The sandbox API covers the essentials: create from OCI images, set CPU/memory limits, configure env vars and networking, execute commands, manage files, and inspect state. For lower-level control, SandboxRuntime gives you direct access to local gVisor sandboxes and lets you tweak the OCI spec before it’s handed off.

Why gVisor?

Running model-generated code means treating it as untrusted. gVisor, Google’s open-source application kernel, implements a big chunk of the Linux syscall interface in userspace, adding an isolation boundary between workloads and the host kernel. It’s OCI-compatible, works with standard container images, and doesn’t require exposing a Docker daemon or socket. Plus, it boots in under a second and has low memory overhead, making sandboxes fine-grained distributed resources.

Future versions of Ray will support other runtimes like Agent Substrate or Kata Containers, but gVisor is a solid start. If you’re building on Google Cloud, this integrates nicely with GKE. And if you’re comparing backend platforms, check out our Supabase review or Firebase review for alternatives.

Try It on GKE

Ready to dive in? Check out the Ray Sandboxes documentation and the Ray sandboxing User Guide for GKE. Have feedback? Join the GitHub discussion and help shape the future of Ray for RL.

Original announcement published on Google Cloud.