An embedded sandbox shouldn't need a Linux VM

We started BoxLite with one conviction: a sandbox for AI agents should be a library you import, not a service you call.

BoxLite's first commit, on December 8, 2025, said it in the opening line of the README:

BoxLite is an embeddable virtual machine runtime for secure, isolated execution environments.

It took SQLite as its model ("small, fast, reliable") and defined the property in one line:

Embeddable — No daemon, no root, just a library in your application.

Ten months later, the design hasn't changed. Every box is a real virtual machine with its own Linux kernel, isolated in hardware: KVM on Linux, Hypervisor.framework on macOS. The VMM runs as a child of your process. There's nothing else to start.

On a Mac, that means BoxLite lives right on your Mac. There's no Linux VM to host the sandbox, no Docker Desktop and no background service. Your program starts a box, and when your program exits, the box is gone.

What "embedded" means

Postgres runs perfectly well on a single machine, and nobody calls it an embedded database. SQLite is embedded because it lives inside your program. There's no server to start, no port, and nothing to operate when your program isn't running.

We hold the embedded sandbox to the same bar:

• It's a dependency, not a deployment. It goes in your lockfile, not your runbook.
• Nothing runs when nothing is running. There's no daemon, no control plane, no database and no reserved memory.
• It runs where your code runs. It works natively on macOS and Linux, with no VM to host the sandbox host.
• It's the same library everywhere. You use it in unit tests, in CI, in a desktop agent you ship to users, and on a customer's air-gapped server.

Putting a sandbox platform on one machine makes it a smaller deployment, not an embedded one. The test is simple: when your program exits, is anything still running?

Why it matters for agents

Agents don't run in one place. They run on a developer's laptop, inside a test suite, in a CLI someone installed with pip, and inside products that ship to customers who will never run your infrastructure. A sandbox that needs its own servers can follow the agent to only some of those places. A library can follow it everywhere.

Isolation shouldn't be the price of that. Agent-generated code is untrusted code, and a shared-kernel container is a different risk class from a VM. BoxLite gives every box its own kernel, so embedding never means weakening the boundary.

BoxLite and E2B Embed

The term has spread this year. In September 2026, E2B launched E2B Embed, which in its own words "runs the whole E2B stack, every feature included, on a single machine." On that machine you run E2B's API, orchestrator, proxy, dashboard, Postgres, Redis, ClickHouse and a log pipeline. The machine has to be Linux with KVM, and on a Mac that means running it inside a Linux VM.

That's a useful product. It gives a customer a private copy of a hosted platform. By the test above, though, it's a single-node deployment rather than an embedded sandbox. The clearest way to show the difference is to measure it, so we installed both on the same MacBook Air (M4, 16 GB, macOS 26.1) and ran the same workload with 512 MiB sandboxes. Each was installed the way its own documentation describes for a Mac:

• BoxLite: natively, with pip install boxlite.
• E2B Embed: in a Linux VM with nested virtualization, as its README requires on a Mac, using the default docker compose up -d --wait.

The table follows from the two designs:

• Fresh creates. E2B Embed creates a fresh sandbox faster, because its server restores each one from a snapshot of the template. That's what a server is good at.
• Admission control. The failed creates are by design: the node lets three sandboxes start at a time and asks the rest to retry.
• The cost of a server. Everything else in the table is what running a server costs you: the services, the reserved memory, and a network hop on every command.
• Nested virtualization. E2B ran under nested virtualization here, because that's how it runs on a Mac. On bare-metal Linux its numbers will be better.

If you want your customer to run a copy of your cloud, E2B Embed does that. If you want the sandbox inside your product, that's what BoxLite was built for.

Each number is the median (p50) or 95th percentile (p95) of repeated runs: 30 creates, 100 commands and 20 resumes per tool. If you get different numbers, especially on bare-metal Linux, open an issue and we'll update this post.

Two forms, one runtime

BoxLite ships in two forms that share one SDK and one core API:

• BoxLite Open Source is the embedded runtime. It's Apache 2.0, runs in-process, needs no account, and no data leaves the machine.
• BoxLite Cloud runs the same boxes as a hosted service, behind a REST URL and an API key.

Moving between them is a change of endpoint, not a rewrite. When you need a server, we run it for you. You never have to start with one.

pip install boxlite

import asyncio
import boxlite

async def main():
    async with boxlite.SimpleBox(image="python:slim") as box:
        result = await box.exec("python", "-c", "print(2 + 2)")
        print(result.stdout)  # "4"

asyncio.run(main())

• Source: https://github.com/boxlite-ai/boxlite
• Questions: Discord, or support@boxlite.ai