loading
loading
Today we’re making VM Sandboxes generally available on Modal, built for those who need to give their agents the power of a full computer.
import modal
app = modal.App.lookup("sandbox-manager", create_if_missing=True)
sb = modal.Sandbox.create(app=app, runtime="vm")
print(sb.exec("uname", "-srn").stdout.read()) # Linux modal 7.2.6
With one flag, you’ll get a fully capable Linux VM with all the niceties that you expect from a traditional modal.Sandbox, and it Just Works™. This brings the same APIs, modal.Images, sub-second cold-starts, and CPU/memory bursting capabilities as previously, all whilst supporting the hundreds of thousands of concurrent Sandboxes that our users are accustomed to.
Why now?
Modal was originally built to achieve the holy grail of Serverless GPUs, with our gVisor-based runtime giving us the ability to quickly scale up lightweight GPU containers, and providing us what we need to create superpowers like fast GPU snapshotting.
Our Sandbox product was also built on gVisor, which has served us well. But earlier this year, we watched as Ramp built an internal agent to drive the entire software development lifecycle on Modal Sandboxes and it became obvious where agents were headed.
Agents, at work or under evaluation, increasingly want to live inside something that looks like a real machine: running Docker stacks, local databases and dev servers, graphical environments and mobile simulators, and even monkeying around with the Linux Kernel itself. In short, agents just want a computer.
At the same time, the ergonomics offered by our container-shaped runtime, such as the exec/FS APIs or the burstable resource model, are core to the Modal experience. When we set off to bring VM Sandboxes to life, we knew we had to support this breadth of use cases out of the box.
import modal
app = modal.App.lookup("sandbox-manager", create_if_missing=True)
probe = modal.Probe.with_exec("docker", "info") # Wait for Docker to be ready
sb = modal.Sandbox.create(
app=app,
image=modal.Image.from_registry("docker:dind"), # Docker-in-Docker image
readiness_probe=probe,
runtime="vm",
)
sb.wait_until_ready()
p = sb.exec("docker", "run", "hello-world")
print(p.stdout.read()) # Hello from Docker! ...
We’ve done a lot of deep engineering work to carry forward the same APIs that support our gVisor Sandboxes, including building out a custom runtime. Starting from the Rust-based Cloud Hypervisor project, we layered on a half dozen innovations spanning our host filesystems, lazy image loading, memory bursting, and snapshotting tech. We’re excited to share deep dives into work we’ve done to make all this possible in the coming weeks.
With VM Sandboxes now available in GA, anyone can now give their agents Sandboxes with local databases or Docker stacks, ready to build complex production systems.
VM Sandboxes in the wild
Over the last couple of months, we've put VM Sandboxes in the hands of early customers, who have already launched over 20 million VMs! Here's what they built.
Linear: coding agents working in your real dev environment
Linear's Coding Sessions let you hand an issue to an agent without ever leaving Linear. Behind the scenes, Linear spins up the user’s full dev environment inside a Modal VM Sandbox.
Having a full-fledged Linux machine gave the Linear team finer control over resource partitioning and networking within each Session, using cgroups and network namespaces to keep the coding agent, the user's dev server, and Linear's own host process from competing for resources. Today, every Linear Coding Session runs on a VM Sandbox.
Legora: Long-horizon legal agent evaluations
Legora builds legal agents that work for hours at a time across legal projects with thousands of documents. They use VM Sandboxes to power their evals, building the full Legora app in each Sandbox, including Postgres, a DOCX editor, and the agent's own code sandboxes.
Snorkel: mocking the real world
Snorkel, a frontier AI data lab, develops and validates complex datasets for training and evaluating frontier AI systems on realistic tasks. They run millions of agent simulations a month with Harbor, testing agents on scenarios like zero-downtime database migrations, hot-swapping services under load, and debugging applications backed by multiple services.
So, should I switch everything over?
Short answer: it depends! If your workload runs happily on Modal Sandboxes today, it'll continue running happily on gVisor, which currently remains as our default runtime.
Reach for runtime="vm" when you butt against the walls of userspace: Docker, FUSE filesystems, or niche Linux kernel features. We’ve made switching as simple as flipping a flag, with both runtimes sharing the same APIs, Images, and usage-based pricing.
What's next?
VM Sandboxes today are intentionally container-shaped, which allows us to offer them as a drop-in runtime, fully compatible with your existing code. Looking forward, we're excited to build out new primitives that take advantage of the expanded capability set and programming model that VMs offer. At the same time, we're working on making VMs even more elastic and lightweight.
Agents just want a computer. Starting today, VM Sandboxes are generally available on Modal, ready to support the next trillion Sandboxes.document fetched 2026-10-24 10:06