Modal Joins gVisor Maintainers as AI Workloads Push Secure Sandboxing Forward

Modal is joining the maintainers of gVisor as Google transfers the project, including its name and trademarks, to the Cloud Native Computing Foundation (CNCF). The move also shifts gVisor to a maintainer-led governance model, with Modal, Ant Group and Tines joining the maintainer group. OpenAI, Tencent and NVIDIA will continue contributing.

The change matters because gVisor has become a significant runtime for workloads that need both Linux compatibility and stronger isolation than ordinary containers provide. Modal says it launches more than 40 million gVisor containers each day, covering GPU inference, multi-node training, coding agents and software sandboxes.

Modal has used gVisor as its main container runtime since the company began. Its requirements are demanding: customer code runs on shared machines, workloads can start at very high rates, and many of them need direct access to GPUs or high speed networking. The company says it has contributed to gVisor since 2023 and is now assigning a dedicated team to the project.

Why gVisor provides a different security boundary

Standard Linux containers share the host kernel. System calls from every container reach that kernel, so a flaw in the kernel or a reachable interface can create a path out of the container.

gVisor inserts a separate application kernel called Sentry between the container and the host. Written in Go, Sentry implements the Linux system call interface for the application. It then makes a limited set of filtered requests to the host kernel. The application sees a Linux environment, while the host sees a controlled process.

The design uses several layers. Sentry handles the application’s system calls itself, so the application does not communicate directly with the host kernel. Sentry is also isolated with Linux namespaces, which provide private views of processes, networking and mounts. The runtime uses pivot_root to leave Sentry with an empty root filesystem, while cgroups limit CPU, memory and device access.

A narrow seccomp filter restricts the host system calls Sentry can make and checks many of their arguments. An attacker therefore has to defeat Sentry and then escape the surrounding Linux controls before reaching the host. That layered model gives Modal a stronger tenant boundary while retaining the operating system interface its customers expect.

gVisor also avoids hardware virtualization. It can run on ordinary Linux machines, including cloud virtual machines where nested virtualization is unavailable or performs poorly, as well as bare metal GPU servers. For a provider operating across dozens of cloud providers, that portability reduces the need for specialized host environments.

The operating requirements behind Modal’s choice

Modal’s infrastructure needs to scale from zero to a million sandboxes in a minute. It also has to execute code from many customers on shared hardware. That combination makes isolation, startup time, device support and state portability part of the runtime itself.

• Isolation: A shared host kernel is a weak boundary for code that may have been generated moments earlier by an AI system.
• GPU access: gVisor’s nvproxy exposes NVIDIA GPUs through a proxy that validates the driver’s ioctl interface instead of giving the container direct access to the raw driver. GPU computation and memory remain native.
• Fast startup: A gVisor sandbox can start in about 25 milliseconds with approximately 12 MB of memory overhead.
• Portable state: gVisor can checkpoint processes, files and sockets, while cuda-checkpoint adds GPU memory checkpointing. Modal uses this capability for its memory snapshots and GPU memory snapshots.
• Broad hardware support: The runtime does not require nested virtualization or a custom host kernel, allowing the same sandbox model to run across cloud and bare metal systems.

Google has described Modal as one of the few providers offering general purpose gVisor based compute. Modal expects that set of providers to grow as the project gains neutral governance and broader participation.

GPU support has become a core part of gVisor

nvproxy must track the interface between NVIDIA’s user space driver and its kernel driver. Each driver release can add new calls or change existing behavior, so GPU support requires continuing runtime work rather than a one time integration.

Modal has upstreamed support for newer NVIDIA drivers and GPUs, including Blackwell and the RTX PRO 6000. The work also covers multi GPU systems, where GPUs communicate through NVLink and share GPU memory. Those capabilities support NCCL on large H100 and H200 systems, while CUDA MPS allows several processes to share a GPU.

The supported workload range extends beyond model training and inference. gVisor can run Vulkan and headless OpenGL applications, NVIDIA hardware video encoding and decoding, robotics simulators such as MuJoCo, NVIDIA Omniverse workloads and FFmpeg GPU pipelines.

Monitoring and debugging tools are included as well. nvidia-smi and NVIDIA DCGM can report GPU usage inside a sandbox, including per process utilization. NVIDIA Nsight Systems, Nsight Compute, Blackwell hardware tracing and GPU core dumps support profiling and diagnosis.

GPUDirect RDMA allows GPU memory to communicate directly with a network card. That path is useful for distributed training and was also required to run ModelExpress inside gVisor.

RDMA brings multi machine training into the sandbox

When Modal added multi node support, gVisor did not yet support RDMA. The company built and upstreamed rdmaproxy, a device proxy for the RDMA verbs interface modeled on nvproxy. The container receives the network interface’s high speed data path, while gVisor validates the control path.

The implementation supports NVIDIA ConnectX hardware using InfiniBand or RoCE, along with AWS EFA. It builds an RDMA sysfs topology inside the sandbox so NCCL can match each GPU with the appropriate network interface. It also supports UCX based data paths in addition to NCCL.

In NCCL all reduce benchmarks, Modal reports performance of about 99% of native bus bandwidth. That work enabled Modal Clusters to run multi node jobs inside gVisor.

Snapshots reduce the cost of model startup

Model startup often spends much of its time loading weights and preparing runtime state. Modal uses gVisor checkpoint and restore to capture a sandbox after model loading, then restore it on another machine. The company says roughly 670,000 gVisor containers are restored from snapshots each day.

That same mechanism is expanding toward multi GPU workloads. Modal currently supports snapshots for programs using one GPU and is testing snapshots for models spread across several GPUs. Early tests show large models returning several times faster than with a cold start.

Performance work reaches filesystems and memory

Filesystem and I/O behavior has been a long running challenge for gVisor, particularly for AI workloads that move large datasets and scan many files. Modal has contributed changes in several areas.

In a PyTorch DataLoader benchmark using shared memory, recycling huge pages in gVisor’s memory allocator increased throughput from 2.9 GB/s to 22 GB/s, roughly an eightfold improvement, while memory use stayed flat. An optimization to gVisor tmpfs made SQLite 2.7 times faster. Modal has also submitted overlayfs changes intended to reduce file data copy up on common operations.

Application compatibility is another part of the work. Because gVisor implements the Linux interface itself, software that runs on Modal exercises that implementation in real workloads. Recent additions include ClickHouse with its atomic table file swaps, Bun applications such as the OpenCode coding agent, Qt 5.15 desktop applications and Mountpoint for Amazon S3.

Common tools also work inside the sandbox. top and htop can report actual CPU usage, while oneDNN gives CPU inference workloads access to bfloat16 and int8 instructions. Sandboxes remain compact after coding agents scan millions of files.

What the maintainer model needs to deliver

Modal’s stated goal is for gVisor to become a default way to run untrusted Linux programs, particularly AI workloads. Reaching that point depends on several practical targets.

• Performance should approach native I/O closely enough that isolation does not become a routine tradeoff.
• New accelerators and drivers should work when they ship.
• Resource efficiency should support dense fleets of sandboxes for agent workloads.
• Snapshots should capture and restore CPU state, one GPU or many GPUs across machines.
• Neutral, multi vendor governance should give more companies a reason to invest upstream.

Modal’s maintainer role gives it a direct path to move work from its production systems into the shared project. That matters for features such as accelerator support, filesystem performance and checkpointing, where provider specific patches can otherwise remain isolated in private forks.

The next engineering targets

Modal is working on GPUDirect Storage, which lets GPUs read model data directly from fast storage without routing it through the CPU. The company also wants inference servers to restore a small multi GPU snapshot containing compiled kernels, CUDA graphs and key value cache memory, then stream model weights into GPU memory from storage or from other GPUs over RDMA. The target is to bring even large models into service in under a minute.

Other planned work includes GPU sandboxes for cloud gaming and remote desktops, with display servers, 3D applications and video streaming running through the GPU. Modal also lists MIG and vGPU support, Grace Blackwell support and kernel module based performance work.

The CNCF transition gives these efforts a broader home at a time when secure execution, accelerators and portable state are converging. The practical test will be whether gVisor can keep its isolation model while absorbing the hardware and I/O features that modern AI systems increasingly require.

Developers can try gVisor through Modal Functions or Modal Sandbox with runtime="gvisor", inspect the project at github.com/google/gvisor, or contribute directly to the runtime.