use case / code interpreter

run generated code without holding your breath.

notebooks, data transforms, eval steps. model-written code runs in a real microvm with its own kernel, not in a container hoping the syscall filter holds.

dithered backlit keyboard representing generated code execution

fast enough to feel free

sandboxes boot in milliseconds locally, so you can afford one per execution instead of one shared pool with shared risk.

measured release: microsandbox 0.4.5, inferred from benchmark chronology because the raw artifact does not record the binary version; owner confirmation is pending. median of 10 measured runs after 2 warmups; end-to-end wall time from cli invocation to process exit; pre-pulled alpine userspace; bare-metal linux x86_64 on a gcp c3-standard-192-metal host (intel sapphire rapids, ubuntu 24.04, /dev/kvm). microsandbox: 320 ms; docker: 463 ms; firecracker: 808 ms. firecracker used the same alpine userspace and harness; these numbers do not use firecracker's narrower kernel-to-userspace boundary. full harness and raw results.

a clean machine every time

each run starts from the image you chose. no leftover pip installs, no state bleeding between users.

use one fresh microvm per execution when isolation matters more than keeping a shared interpreter warm.

limits that hold

set vcpus, memory, and disk per sandbox. the limits are enforced by the hypervisor, not requested politely from a shared kernel.

the generated program and every child process stay inside the guest machine those limits describe.

keep network and credentials explicit

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.

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.

start without a service dependency

one sdk. one api. local or cloud is a config change, not a rewrite.

private beta. access is by request.

how it works

from generated code to a clean result

pick an image

choose the language runtime and packages the execution needs.

start a fresh microvm

give this execution its own kernel, memory, disk, and network policy.

run and read

execute the generated code and collect stdout, stderr, and its exit result.

discard it

remove the sandbox so the next execution starts without leftover state.

see it work

the current cloud request shape

bash

# cloud access is invite-only
curl -X POST "$MSB_API_URL/v1/orgs/$MSB_ORG/sandboxes?start=true" \
  -H "Authorization: Bearer $MSB_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "name": "code-job",
  "image": {
    "type": "oci",
    "reference": "python:3.12"
  },
  "resources": {
    "vcpus": 1,
    "memory_mib": 512,
    "disk_size_mib": 8192
  },
  "runtime": {
    "workdir": null,
    "shell": null,
    "scripts": {},
    "entrypoint": null,
    "cmd": null,
    "user": null,
    "log_level": null
  },
  "env": [],
  "labels": {},
  "rlimits": [],
  "mounts": [],
  "patches": [],
  "network": {
    "enabled": true,
    "policy": null,
    "secrets": null,
    "max_connections": null
  },
  "init": null,
  "pull_policy": "if_missing",
  "security_profile": "default",
  "lifecycle": {
    "ephemeral": true,
    "max_duration_secs": 300,
    "idle_timeout_secs": null
  }
}'

know the limits

cloud access is invite-only and invitations go out in batches.
the curl body is the complete 0.6.8 cloud sandbox request, not simplified pseudocode.
copying results out of a sandbox remains an application-level lifecycle decision.

evaluate the alternatives

vs e2b vs modal

run your first interpreter sandbox locally in one command.