Google and Anyscale introduce experimental gVisor sandboxes for Ray

Google and Anyscale introduced an experimental library that brings gVisor-backed sandboxes into distributed Ray clusters. The August 26 announcement says the integration starts with Ray 2.58 and represents each high-level sandbox through a Ray Actor, allowing the scheduler to place it and reserve resources.

Isolation joins the scheduling model

The library connects sandbox creation, command execution, files, and lifecycle management to Ray’s existing distributed programming model. Google describes gVisor as the initial runtime and identifies other runtimes as future work. This is an experimental release, not a declaration that every Ray deployment now provides the same isolation boundary.

For teams executing generated or otherwise untrusted code, the architectural benefit is a clearer place to account for each execution environment. The scheduler can manage where work runs while the sandbox runtime governs its interaction with the host.

That division should remain visible in the application design. Resource scheduling alone is not an authorization decision about credentials, network destinations, or customer data.

Evaluate failure behavior first

A useful trial should include a sandbox that exhausts memory, a command that never exits, a lost worker, and a caller that retries after a timeout. Record which operations can safely repeat and which need an application-level execution identifier.

Credential delivery deserves a separate review. Give the sandbox only the inputs required for its task and avoid inheriting a broad worker environment merely because the process starts inside Ray.

Teams already using Ray can evaluate the library without first designing a separate placement service. They should nevertheless pin the experimental API, document cleanup ownership, and verify host compatibility before relying on it for production execution.