Modal Sandboxes: Isolation, Snapshots, Egress and Billing

What Modal Sandboxes are

Modal describes Sandboxes as secure containers for executing untrusted code on its platform, aimed squarely at code an LLM wrote or code a user uploaded. Your backend creates one with Sandbox.create, runs commands in it with exec, reads their output and exit codes, and terminates it. The same interface ships in Modal's Python, JavaScript and Go SDKs.

A Sandbox takes nearly every option a regular Modal Function does: a custom image, Volumes, secrets as environment variables, CPU, memory and GPU requests. Created from outside Modal, it has to belong to an App, which App.lookup(..., create_if_missing=True) provides. Running Sandboxes can be fetched again by ID, given a unique name within a deployed App, and tagged with up to ten key-value pairs to filter Sandbox.list by.

Modal recommends building the image ahead of time and publishing it as a named image, so a new Sandbox never waits on an image rebuild. For an agent product that starts many Sandboxes, that is the first thing to set up.

Isolation: gVisor or a VM

Every Sandbox runs on one of two runtimes, chosen with the runtime parameter or left to Modal:

• gVisor, Google's user-space kernel that intercepts the workload's system calls. Modal calls it strong isolation suitable for most workloads, and it is the only runtime that takes GPUs.
• VM, where the Sandbox gets a virtual machine with its own Linux kernel. Modal points to it for workloads that expect a full Linux environment: running Docker inside the Sandbox, mounting FUSE filesystems, or nested cgroups. Nested virtualization on a VM Sandbox is an Enterprise-plan option.

Which runtime to pick

For code an agent writes and runs once, gVisor's syscall interception is the boundary most teams will want, and it keeps GPUs available. Reach for the VM runtime when the agent's task needs Docker or kernel features gVisor doesn't implement, not by default. Our Firecracker vs gVisor piece sets out what each boundary does and does not stop.

Lifecycle and timeouts

A Sandbox moves through Created, Scheduled, Started, an optional Ready, and Finished. Its default maximum lifetime is five minutes, raised with timeout to at most 24 hours. Modal's answer for work that runs longer is to snapshot the filesystem and start a new Sandbox from it.

An idle_timeout ends a Sandbox that has no command running, no stdin being written and no open connection on its tunnels, which is the setting that stops an abandoned agent session from billing all afternoon. Readiness probes (a TCP port accepting connections, or a command that exits 0) let your code wait until setup inside the Sandbox has finished; they run for at most five minutes and don't terminate the Sandbox when they give up.

Modal does not publish a cold-start figure on these pages. If start time matters to your product, measure it with your own named image and region; our cold-start benchmarks explain what to time and why vendor numbers rarely match.

Networking and egress control

Modal calls Sandboxes secure by default: a new one accepts no inbound connections and has no access to your Modal resources. Outbound is the opposite. By default a Sandbox can reach any public IP address, so an agent that has been prompt-injected can still send data out unless you restrict it. Three settings do that:

• block_network=True drops all outbound traffic.
• outbound_cidr_allowlist allows traffic, on any protocol, only to the listed IP ranges.
• outbound_domain_allowlist (beta) allows TLS traffic on port 443 only to the listed domains, matched on the TLS server name. Modal's own documentation notes it doesn't support Encrypted Client Hello and doesn't by itself stop domain fronting through a shared CDN; it suggests routing traffic through a Sidecar where that matters.
• DNS stays open unless all outbound traffic is blocked. An experimental API swaps the policy on a running Sandbox, but only for allowlist types set when it was created.
• Inbound, Modal recommends Sandbox Connect Tokens for authenticated HTTP and WebSocket requests to a server inside the Sandbox, with port forwarding through tunnels as the alternative and inbound_cidr_allowlist to limit who can connect.

What we'd set for an agent

Start from block_network=True for pure computation, and from a domain allowlist naming only the package index and APIs the task needs when it has to reach out. Our guides to egress controls for agents and egress firewall rules for LLM tool calls cover how to decide that list.

State: Volumes and three kinds of snapshot

Volumes mount into a Sandbox as they do into a Function, for data that should outlive it. For the Sandbox's own state, Modal offers three snapshot types:

• Filesystem snapshots copy the root filesystem and become an Image. Start new Sandboxes from one to resume a session, or start several from the same one to fork an agent's state and try different changes side by side. They don't include mounted Volumes, and they now expire after 30 days unless you set a different TTL or none.
• Directory snapshots capture one directory as an Image that can be mounted into a Sandbox that is already running. Modal pairs them with warm pools: start generic Sandboxes ahead of time, then mount a user's project into one when it is needed.
• Memory snapshots capture memory as well as the filesystem, so a restore is an exact clone. Modal lists real limits: they expire after 7 days, taking one currently terminates the Sandbox, they can't be used with GPUs, open TCP connections close, and a restore must land on the same instance type, which can delay scheduling.

Persisting a session

Snapshots are triggered from outside the Sandbox, so your orchestrator takes one before terminating and stores the snapshot ID against the user or session. For how this compares with other vendors, see snapshot and fork support across providers and which providers keep packages and files between sessions.

Resources and billing

Modal's model differs from most sandbox vendors in two ways. Sandboxes burst above what they request, and you are charged for the larger of what you requested and what the Sandbox used, for both CPU and memory. The default request is 0.125 CPU cores and 128 MiB; the cpu parameter counts physical cores, and one core is two vCPUs.

Leaving the request unset means paying for what is used. Setting one guarantees a minimum and is billed for the Sandbox's whole lifetime whether used or not. Limits cap how far a Sandbox can burst, which Modal suggests when an agent controls what runs inside it and for running evals on fixed resources. GPU Sandboxes can be preempted, so GPU work has to survive interruption.

We don't quote Modal's rates here because they change. Check the current CPU, memory and GPU rates on Modal's pricing page, then model your own workload with our guide to what 500 agent sandboxes a day cost.

Who it fits

• Teams whose agents need a GPU inside the sandbox, on the gVisor runtime.
• Agents that need Docker, FUSE or nested cgroups inside the sandbox, on the VM runtime.
• Products that fork one prepared environment into many parallel attempts, using filesystem snapshots.
• Backends in Python, JavaScript or Go, and teams already running Functions on Modal, since Sandboxes share its images, Volumes and secrets.

What to check before you commit

• Where it runs. If code and data must stay inside your own cloud account, ask Modal what it offers; our list of providers that run in your own cloud account shows what to ask.
• Concurrency. How many Sandboxes your plan can run at once is a plan question for Modal; see how concurrency limits shape scaling.
• Start time. Measure it on your own image rather than trusting a headline figure.
• Lock-in. The Sandbox interface is Modal's own. Keep it behind a thin layer of your code; see what makes a sandbox hard to migrate away from.
• Compliance and uptime. Ask Modal for its current certifications and SLA terms directly; our reliability and SLA comparison lists the questions.