back to microsandbox

compare

microsandboxvsmodal

pick modal for gpu workloads and managed compute. [1] pick microsandbox when agents need to run on employee devices or in microsandbox cloud, with local memory and disk snapshots. [20][21][22]

modal sandboxes run untrusted code in modal's cloud. standard sandboxes use gvisor; beta vm sandboxes provide a full linux kernel for workloads such as docker. [1][2]

microsandbox uses a microvm with its own kernel for each sandbox. run the runtime locally, deploy it to employee devices with administrator settings, or select microsandbox cloud through the same CLI and SDKs. cloud is in private beta with access by request. [20][22][24]

microsandbox
local + cloud
modal
managed cloud compute and sandboxes [1]
primary use case
per-session agent computers · untrusted code
managed functions, sandboxes, gpu compute, and batch jobs [1]
hosting model
local runtime · microsandbox cloud (private beta, access by request) [20]
managed cloud [1]
isolation options
hardware microvm · separate kernel
gvisor by default · beta full-vm sandboxes available [2]
runs offline
local, after provisioning runtime dependencies and images [23]
managed service [1]
languages
rust · typescript · python · go · ruby · cli
python · javascript · go sandbox clients [1]
programming model
embedded local runtime · same CLI and SDKs for hosted cloud [20]
managed app and sandbox api [1]
snapshots
local snapshots save disk state, or disk, memory, and running processes with --full. cloud currently supports disk snapshots from stopped persistent sandboxes and disk restore. [21]
filesystem and directory snapshots · alpha memory snapshots [4]
employee-device deployment
administrator settings deployed to employee devices with Jamf or Intune; supported CLI and SDK releases apply managed overrides [22]
local client calls modal's hosted sandbox service [1]
credentials
credentials are destination-bound. the sandbox works with a placeholder; the real value is substituted host-side into supported intercepted outbound requests, only for destinations on your allow-list. an approved destination still receives the real credential and could reflect or misuse it, so scope your allow-lists accordingly.
modal secrets are supplied to sandboxes as environment variables [1]
network policy
by default, sandboxes can reach the public internet. private, host-local, link-local, and metadata destinations are blocked. egress can be reduced to an allowlist or disabled entirely. in the cloud, the non-public block cannot be lifted, even by you.
managed sandbox networking and egress configuration [1]
gpu support
cpu today · gpu is not offered
documented gpu acceleration and gpu resource selection [1]
readiness and long jobs
application controls lifecycle through the sdk
readiness probes, idle timeouts, detach, and managed job lifecycle [1]
pricing
free locally · private beta pricing is published
published usage pricing and free credit [3]
license
apache 2.0
managed proprietary service [1]
pick modal

choose modal when

  • you need managed gpu resources or batch compute. [1]
  • you want readiness probes, managed job lifecycle, and cloud capacity in one service. [1]
  • your application fits modal's managed app and sandbox model. [1]
  • you need its beta full-vm sandbox for workloads that require a real linux kernel. [2]
pick microsandbox

choose microsandbox when

  • agents must execute on employee devices with administrator-managed settings. [22]
  • you need local disk checkpoints, full memory snapshots, or branches of a running workload. [21]
  • you want every sandbox to use an own-kernel microvm by default.
  • you need destination-bound credentials and a host-enforced network floor.
  • you want the same CLI and SDKs locally and in microsandbox cloud, within the documented cloud feature limits. [20]

02

saving files versus resuming a running agent

modal offers filesystem snapshots and alpha memory snapshots. its memory snapshots expire after seven days, terminate the source on capture, and have restrictions on active exec commands and gpus. [4]

a local microsandbox full snapshot saves disk, memory, and running processes, then resumes a running source after capture. restore creates a new sandbox; it requires compatible runtime and resource settings, and application connections must reconnect. cloud currently supports disk capture from stopped persistent sandboxes. [21]

snapshot types and limitations

03

running agents on employee devices

deploy microsandbox runtime dependencies and a protected managed.json through Jamf or Intune. supported releases apply administrator overrides above user settings and CLI or SDK options. provision approved images and packages for offline work. [22][23]

managed settings apply when new backend instances load them; existing sessions keep their settings. local administrators can remove the policy or replace the runtime. this is device configuration, not a hosted fleet control plane. [22]

managed deployment guide

04

moving from modal

map image setup, command execution, and file access to microsandbox's CLI or SDK. choose the backend explicitly, then check the cloud compatibility table for features your application uses. [20]

keep modal for workloads that depend on its gpu or managed-compute APIs. [1] compare snapshot behavior separately from the basic execution loop before moving a stateful agent.

cloud compatibilitymicrosandbox pricing

common questions

is microsandbox a modal alternative?

yes for agent sandboxes on local machines, managed employee devices, or microsandbox cloud. [20][22] modal also covers functions, batch jobs, and gpus. [1]

does modal sandbox untrusted code?

yes. modal documents sandboxes for untrusted user and agent code. [1] standard sandboxes use gvisor, and beta vm sandboxes provide a full linux virtual machine. [2]

does modal use gvisor or virtual machines?

both paths exist. gvisor is the standard sandbox path, while modal's beta vm option runs a sandbox on a full virtual machine with a real linux kernel. [2]

does modal support gpus?

yes. modal documents gpu acceleration and gpu resource selection. [1] microsandbox does not offer gpu sandboxes today.

can modal run locally?

modal clients can run on your laptop, but their sandboxes execute remotely. [1] microsandbox can execute the microvm on that laptop or use its hosted cloud backend. [20]

primary sources

  1. [1] modal sandbox documentation: clients, lifecycle, images, secrets, networking, and gpu resources · last verified 2026-09-24
  2. [2] modal beta vm sandbox documentation: full virtual machine and real linux kernel · last verified 2026-09-24
  3. [3] modal pricing · last verified 2026-09-24
  4. [4] modal filesystem, directory, and alpha memory snapshots · last verified 2026-09-24
  5. [20] microsandbox cloud availability and backend compatibility · last verified 2026-09-24
  6. [21] microsandbox disk snapshots, full checkpoints, and local branching · last verified 2026-09-24
  7. [22] microsandbox managed deployment with Jamf and Intune · last verified 2026-09-24
  8. [23] microsandbox offline provisioning of runtime dependencies and images · last verified 2026-09-24
  9. [24] microsandbox microVM isolation · last verified 2026-09-24
  10. [25] microsandbox runtime, CLI, images, and language SDKs · last verified 2026-09-24

run it locally.

put the boundary on your own machine before you choose anything else.

run it locally