Skip to main content

​
What is a MicroVM sandbox?

A MicroVM sandbox is a lightweight virtual machine — typically backed by Firecracker or CloudHypervisor — designed to start in milliseconds and run a single workload in hardware-isolated form. Unlike containers, each MicroVM has its own kernel, which makes them safer for running untrusted or AI-generated code. They’re commonly used for AI agents, code execution, serverless functions, and CI/build workloads. Tensorlake Sandboxes are MicroVMs built on Firecracker and CloudHypervisor.

​
What are Tensorlake Sandboxes?

Tensorlake Sandboxes are isolated MicroVMs that boot in hundreds of milliseconds, with memory and filesystem preserved across suspend and resume. You can use them to run agent harnesses, execute tool calls, or as VMs for coding agents, builds, and IDEs.

​
How are Tensorlake Sandboxes isolated?

Each sandbox is a MicroVM backed by Firecracker and CloudHypervisor. Sandboxes provide hardware-level isolation rather than container-level isolation, so untrusted or AI-generated code can run safely without sharing a kernel with other workloads.

​
How fast does a Tensorlake Sandbox start?

Tensorlake creates a fresh sandbox in single-digit milliseconds; OS boot then completes in a few hundred milliseconds for the default tensorlake/ubuntu-minimal image. tensorlake/ubuntu-systemd, which includes a full init system and additional tooling (like Docker and Kubernetes support), takes around one second to boot. At peak load, the scheduler creates hundreds of sandboxes per second — see Architecture for how this differs from Kubernetes pod creation.

​
How do I create a Tensorlake Sandbox?

Create one on demand from the CLI or the SDK. Pass image, cpus, and memory to control the runtime. 
  tl sbx create
See the Quickstart for a full walkthrough.

​
What can I run inside a Tensorlake Sandbox?

Anything the OS supports. Common workloads include:

​
Is Tensorlake compliant with HIPAA and SOC 2?

Yes. Tensorlake is HIPAA and SOC 2 Type II compliant, supports EU data residency, and offers zero data retention.

​
How are Tensorlake Sandboxes different from Docker containers?

Tensorlake Sandboxes are MicroVMs backed by Firecracker and CloudHypervisor, which means each sandbox has its own kernel and hardware-level isolation. Docker containers share the host kernel — faster to start, but weaker isolation for running untrusted or AI-generated code. Tensorlake also provides built-in suspend/resume and snapshots, which aren’t part of the standard Docker runtime. If you have an existing Dockerfile, Tensorlake can build a sandbox image from it — see Sandbox Images.

​
Why would I use a sandbox if agents can already run on my laptop?

A laptop works for developing agents and running one or two interactively. It becomes the bottleneck when agents need to run unattended, in parallel, or against untrusted code:
  • Isolation — an agent that installs packages, modifies files, or runs LLM-generated code does it inside its own MicroVM, not on your machine.
  • Persistence — sandbox state (filesystem and memory) survives suspend and resume, so long-running work doesn’t depend on your laptop staying open.
  • Reproducibility — each sandbox starts from a defined image, not from whatever happens to be installed locally.
  • Snapshot and fork — checkpoint an agent’s environment and fork parallel workers from it, which a single machine can’t do.
  • Scale — going from one agent to dozens means creating more sandboxes, not buying more hardware.

​
How is Tensorlake different from running Claude Code with git worktrees?

Git worktrees let you check out several branches of a repository side by side, so a coding agent like Claude Code can work on multiple tasks at once on your machine. The isolation is at the source-code level: every worktree shares your laptop’s OS, dependencies, processes, and network. Tensorlake Sandboxes isolate the entire execution environment. Each sandbox is a MicroVM with its own filesystem, processes, and dependencies, and can be suspended, resumed, snapshotted, and forked independently — and it keeps running when your laptop doesn’t. In short:
  • Worktrees isolate source code.
  • Sandboxes isolate entire execution environments.
If your goal is to have Claude work on several branches locally, worktrees may be all you need. If your agents need their own runtime, persistent state, browser sessions, or custom dependencies, or need to run independently of a developer laptop, sandboxes provide that infrastructure. The two also compose: you can run Claude Code inside a sandbox and still use worktrees there.