Skip to main content
Every session runs in its own isolated sandbox. Sandboxes are ephemeral: spun up for the session, destroyed when it’s done. No code or state persists after execution.

Data handling

Your repository is cloned into the sandbox for the duration of a session and torn down when the session ends — no repository contents or working state persist afterward. The one exception is snapshots. If you use the snapshot feature to speed up environment setup, your repository and pre-installed dependencies are cached into a reusable snapshot image so future sessions start faster. That cached copy persists until the snapshot is rebuilt or removed. Model providers handle prompt data according to their own retention policies — see the retention table in Max for Tembo-hosted models. With BYOK, model requests run against your own provider account, so provider-side retention follows that account’s terms.

Sandbox sizes

Tembo offers six sandbox sizes. Each session runs in a dedicated Linux VM, and no two sessions share the same VM. Micro and Medium are best for routine code analysis, fixes, features, and reviews. Large, XL, and XXL are best for heavier builds, integration tests, Docker workloads, large repositories, or multi-container setups. Need more than 64 GB of RAM? Contact support@tembo.io to request access. VM sandboxes include full nested virtualization for Docker-in-Docker and provide a stronger isolation boundary. If your org requires that untrusted code only runs with a VM boundary, we can enforce a VM-only posture. Contact support@tembo.io.

Pre-installed tools

All sandbox sizes come with:
Go, Rust, Java, and Elixir are available through Nix dev shells. Add a tembo.nix to install language-specific tooling for your project.

Add custom dependencies

Add a tembo.nix file to your repository when your project needs tools that are not pre-installed in the sandbox.