Skip to content

SDK overview

mvm has two SDK surfaces because sandbox users have two different jobs.

SurfaceBest forCurrent status
Runtime SDKCreate a sandbox from application code, run commands, move files, snapshot, and stop it.Partial in Python and TypeScript; Rust lifecycle client is planned.
Decorator SDKDeclare a reproducible workload in source code and compile it into mvm Workload IR.Available for build-time declarations.

The runtime SDK is the imperative surface: your app owns a sandbox lifecycle. The decorator SDK is the declarative surface: your source file declares what should be built and executed.

The parity target is product behavior, not a copy of another site: application developers should get simple lifecycle ergonomics, while platform developers get decorators that compile into secure mvm Workload IR.

Both surfaces target the same runtime model:

  • mvm owns local microVM lifecycle, image materialization, guest communication, signed plans, and host-side enforcement.
  • Nix-built microVM artifacts are the preferred path for reproducibility and auditability.
  • OCI images are compatibility inputs and must pass through verification, cache scoping, and launch policy before execution.
CodeRuns onNotes
Your SDK clientHost processOwns lifecycle and receives errors/logs.
Static decorator compilerHost, without importing user codeReads declarations and emits Workload IR.
Workload entrypointGuest microVMRuns behind guest/host policy boundaries.
Runtime admissionmvmVerifies local plans and launches the microVM backend.

The SDK docs use conservative language until implementation and tests prove stronger behavior:

  • Secret examples use references, not plaintext values.
  • Mutable OCI tags are local development examples only.
  • Network access is deny-by-default unless a page says otherwise.
  • Planned APIs are labeled Planned and should not be copied as shipped code.
  • Strong product claims link back to the security claim ledger.