Skip to main content
Modal Sandboxes are secure containers on Modal’s serverless platform for running arbitrary code at runtime, with elastic CPU and memory. The following table shows what CostGraph runs on this provider. CI runners: no. AutoPilot compares runners by price, and this provider publishes no sandbox price.

​
Connect

Run the dispatcher with provider set to modal and these variables:
  • MODAL_TOKEN_ID
  • MODAL_TOKEN_SECRET
To see what Modal costs, connect the Modal integration.

​
Key and permissions

MODAL_TOKEN_ID and MODAL_TOKEN_SECRET are the two halves of a Modal token. For CI, create a Service User at Settings > Tokens > Service users (or modal workspace service-users create <name>), which prints both values once. A personal token can also be created with “modal token new”. Documented (Team/Enterprise with RBAC): a service user starts with no access to any Environment. Grant it the Contributor role (full read/write) on the one Environment where the sandboxes run; Viewer is read-only. Creating a service user needs workspace owner or manager. Without RBAC, tokens are workspace-wide. Sources: modal.com: sandboxes, modal.com: sandbox resources, modal.com: resources, modal.com: service users, modal.com: rbac.

​
Limits

  • Default maximum lifetime is 5 minutes, and timeout can be raised to 24 hours. idle_timeout ends a sandbox after inactivity. (source)
  • The default request is 0.125 CPU cores and 128 MiB, and sandboxes can burst above it. 1 core = 2 vCPUs. The default soft CPU limit is 16 cores above the request. A maximum is enforced at creation, but its value is not stated on the page. (source)
  • Setting a region (for example us-west) adds a price multiplier. GPU sandboxes can be preempted. (source)
  • Service users are a Team/Enterprise plan feature. (source)