> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensorlake.ai/llms.txt > Use this file to discover all available pages before exploring further. # What are Tensorlake Sandboxes? > Frequently asked questions about Tensorlake Sandboxes — isolated MicroVMs for AI agents, tool calls, builds, and IDEs. ## What is a MicroVM sandbox? A MicroVM sandbox is a lightweight virtual machine — typically backed by [Firecracker](https://firecracker-microvm.github.io/) 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](https://firecracker-microvm.github.io/) 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](/applications/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. ```bash cli theme={null} tl sbx create ``` ```python sandbox.py theme={null} from tensorlake.sandbox import Sandbox resp = Sandbox.create( image="tensorlake/ubuntu-minimal", cpus=4, memory_mb=8192, ) ``` ```typescript sandbox.ts theme={null} import { Sandbox } from "tensorlake"; const resp = await Sandbox.create({ image: "tensorlake/ubuntu-minimal", cpus: 4, memoryMb: 8192, }); ``` See the [Quickstart](/sandboxes/quickstart) for a full walkthrough. ## What can I run inside a Tensorlake Sandbox? Anything the OS supports. Common workloads include: * Agent harnesses and [tool calls](/sandboxes/tool-calls) * LLM-generated or untrusted code * Browser automation and [computer use](/sandboxes/computer-use) * Builds, tests, and CI workloads * Long-running processes and [PTY sessions](/sandboxes/pty-sessions) * [Networking](/sandboxes/networking) and [tunnels](/sandboxes/tunnels) ## 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](/sandboxes/lifecycle) and [snapshots](/sandboxes/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](/sandboxes/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](/sandboxes/lifecycle), so long-running work doesn't depend on your laptop staying open. * **Reproducibility** — each sandbox starts from a defined [image](/sandboxes/images), not from whatever happens to be installed locally. * **Snapshot and fork** — checkpoint an agent's environment and [fork parallel workers](/sandboxes/snapshots) 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](/sandboxes/lifecycle), [snapshotted, and forked](/sandboxes/snapshots) 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.