• 3 min read
Modal says it can spin up 1M sandboxes in under a minute
Modal rebuilt its sandbox platform to remove central bottlenecks, saying it can now run 1 million concurrent sandboxes and create tens of thousands per second.

Image: Hacker News
Modal says it has rebuilt its sandbox platform to handle a very different class of workload: millions of concurrent sandboxes and tens of thousands of sandbox creations per second. In a benchmark the company published on July 16, 2026, it said it ran 1 million sandboxes concurrently, creating all of them in under a minute.
Modal says demand is being driven by reinforcement learning and fast-growing agent workloads. The company already runs millions of sandboxes per day and supports up to 50,000 concurrent sandboxes per customer, but its earlier system, by its own account, was not built for the bursty, massive-scale patterns these newer use cases require.
The core change is architectural. Modal says it stripped out central coordination from the critical sandbox creation path, replacing a more traditional control-plane design with a fleet of horizontally scaled scheduling servers. Those schedulers make placement decisions using in-memory cached data, then contact worker nodes directly over RPC to create a sandbox. Worker nodes publish state into a Redis stream, and durable writes for metadata and results happen mostly asynchronously rather than blocking creation.

Recommended reading
Google says prompts need builds, not blobs
Why Modal moved away from central coordination
The company argues that conventional container systems hit scaling limits because too many operations grow with the number of containers or nodes. It points to Kubernetes as an example, citing scheduler complexity, heavy reliance on etcd, and node heartbeat traffic that scales with cluster size.
Modal says its own original architecture had similar issues. Like Kubernetes, it relied on strong consistency and put Postgres in the middle of sandbox creation and scheduling, which meant global coordination and O(sandboxes) writes that were hard to shard.
In the new design, Modal says there are no data stores in the critical path for sandbox creation, and no RPCs other than sandbox creation itself that scale with the number of sandboxes. The creation path now takes two network hops and one cheap CPU operation, according to the company.
The work took months, touching the company’s backend, worker management stack, and container runtime. Modal says one issue was that its new schedulers could push containers so quickly that Linux rtnl lock contention during network setup caused startup delays of tens of seconds, forcing changes to container networking.
Performance in the 1 million sandbox test
Modal says individual sandbox time-to-interactivity stayed low even at scale. In its testing, median sandbox start time—from the first client request to the point where user code can run—was less than half a second, while scheduling itself now takes tens of milliseconds.
The company says the latency tail is still longer than it wants, and attributes much of that to kernel and network contention when many sandboxes start simultaneously on the same worker. Even so, Modal says the new system is already available in Beta and will soon back all sandbox scheduling on the platform, with opt-in requiring only a simple code change.
Enterprise Editor
Marcus follows the money. He covers enterprise software, cloud architecture, and the tectonic shifts in Big Tech strategy. He translates dense earnings calls and complex M&A activity into actionable insights about where the industry is actually heading. If a tech giant makes a silent pivot, Marcus is usually the first to notice.
via Hacker News


