Ray Sandboxes vs Standard Containers for Agent Code
On this page
Quick answer
Use a standard container for trusted workloads that fit the existing host-kernel risk boundary. Consider a Ray gVisor Sandbox when model-generated code or agent tool calls must run with stronger defense-in-depth isolation and Ray-native scheduling.
gVisor is not a complete security decision and Ray Sandboxes are currently alpha. Validate compatibility, performance, operations, and the whole control plane before moving an untrusted workload.
Isolation comparison
| Boundary | Standard Linux container | Ray Sandbox with gVisor |
|---|---|---|
| Kernel path | Container processes normally share the host kernel | gVisor intercepts system calls in a user-space application kernel before the host kernel |
| Runtime form | OCI container through a runtime such as runc | OCI image executed through runsc inside a Ray worker environment |
| Orchestration | Kubernetes or another container scheduler | Ray Actor scheduling inside the Ray cluster; can run within KubeRay Pods |
| Default root filesystem | Depends on configuration | Ray documents a read-only base with an isolated overlay and explicit writable workdir |
| Default network | Depends on runtime and policy | Ray documents network="none" as the default |
| Resource control | Container and orchestrator limits | Ray resource reservation plus documented cgroup CPU and memory controls |
| Compatibility | Broad native Linux syscall behavior | Some workloads can be incompatible or behave differently behind gVisor |
| Product lifecycle | Depends on platform | ray.experimental.sandbox is alpha and may change or disappear |
The comparison is architectural. Measure the exact versions, image, kernel, gVisor platform, workload, and cluster.
What gVisor changes
Ray describes gVisor as an open-source application kernel written in Go that implements a substantial part of the Linux syscall interface in user space. This reduces direct exposure of the host kernel to untrusted processes and can make container escape through a host-kernel flaw harder.
It does not prove absence of vulnerabilities. It also does not isolate the trusted Ray Actor, image manager, worker Pod, Ray control plane, Kubernetes API, registry, logging pipeline, or credentials around the sandbox.
Network choices are security choices
Ray currently documents four modes:
none: default, with no outbound network interface;public: host egress with generated DNS settings and without the host resolver identity;host: full host network identity, including possible internal and node-local access;sandbox: gVisor netstack with additional runtime requirements.
For untrusted code, begin with none. If external access is required, allowlist destinations at the surrounding network layer and test DNS, redirects, IP literals, metadata services, internal ranges, data volume, and exfiltration. Do not use host merely to solve a DNS problem without accepting its larger boundary.
Files, mounts, and capabilities
The default read-only root and writable work directory are useful starting points. A host mount, device, socket, broader writable path, or OCI transformation can bypass the intended data boundary. Mount only approved data read-only where possible and verify path traversal, symlinks, archives, and deletion.
Ray supports explicit capability configuration, including an empty set. Add capabilities only for a measured need. Root inside a sandbox is not equivalent to host root, but unnecessary capabilities still expand what compromised code can do inside its boundary.
Choose with a workload test
Test the same representative workload in both environments:
- Record required syscalls, libraries, files, devices, networking, and process behavior.
- Run malicious and accidental failure cases, not only the happy path.
- Compare startup, p95 command latency, throughput, memory, CPU, image pull, cache, and node density.
- Measure failures, cleanup, observability, autoscaling, upgrade, and recovery.
- Decide whether the additional isolation fits the compatibility and operational cost.
Google Cloud and Ray report fast startup and dense scaling for their tested architecture. Treat those as provider results to reproduce, not universal guarantees.
Use the Ray Sandbox API lifecycle guide for implementation controls and the GKE readiness check for rollout evidence.
Frequently asked questions
How is a Ray gVisor Sandbox different from a standard container?
A standard container normally shares the host Linux kernel. gVisor intercepts many system calls in a user-space application kernel, adding a defense-in-depth barrier between untrusted code and the host kernel.
Is a Ray Sandbox the same as a virtual machine?
No. gVisor is a user-space application kernel for container workloads; it does not boot a separate guest operating-system kernel like a VM or microVM.
Do Ray Sandboxes block network access by default?
Current Ray documentation says network="none" is the default. Public, host, or sandbox modes change that boundary, and host mode gives full host network identity.
Does gVisor make untrusted agent code safe?
It adds an important isolation layer, but safety still depends on images, permissions, mounts, capabilities, network, secrets, resources, vulnerabilities, observability, cleanup, and the surrounding Ray and Kubernetes control planes.
Official sources
Source check: August 27, 2026. Recheck alpha status, gVisor architecture, filesystem and network defaults, capabilities, resource controls, compatibility, and performance evidence.