Tensorlake: Firecracker Sandboxes with a Serverless Orchestration Layer

The problem Tensorlake targets: agent code that needs a real machine, not a subprocess

Running model-generated code inside your application process is the default and the wrong one. A subprocess shares the filesystem, inherits environment variables, and dies with the parent. Tensorlake's answer is to hand you a Firecracker MicroVM per unit of work, with a filesystem that the README describes as block-based storage achieving near-SSD speeds inside the VM. The audience is narrow and specific: teams building agents that write files, install packages, or hold a long-running process open between turns. The README's own example of a long-running process is `sandbox.start_process("sleep", ["300"])`, which returns a pid you keep. That is the shape of workload this project is designed for. If your agent only calls HTTP APIs, this is more infrastructure than you need. The second half of the pitch is the serverless function runtime with fan-out, so a single agent can dispatch many parallel units of work without you standing up a queue and a worker pool. The two halves share a client, which is the actual product decision here: sandbox state and orchestration are sold as one system rather than two.

Firecracker MicroVMs, snapshots and pools: the execution model

Each sandbox is a stateful Firecracker MicroVM. The README states that sandboxes are created in under a second via Lattice, described as a dynamic cluster scheduler, and that idle sandboxes suspend and resume in under a second without losing memory or filesystem state. That suspend/resume behavior is the part that changes how you write code. You do not need to serialize your agent's working set to an external store between turns; you keep the sandbox and let it go idle. Snapshots go further: `client.snapshot_and_wait(sandbox_id)` captures a running sandbox, and a later `client.create_and_connect(snapshot_id=...)` picks up where it left off. The README frames this as durable memory and filesystem checkpoints, and also mentions cloning running sandboxes across machines. Pools invert the startup problem. `client.create_pool(image=..., warm_containers=3, network=...)` pre-warms containers, and `client.claim(...)` takes one. The README is explicit about ordering here: claim-specific file systems are mounted before the sandbox is reported as running, so your `/mnt/skills` mount exists by the time you connect. Named sandboxes are a separate convenience: `client.create(name="stable-name")` followed by `client.connect("stable-name")` gives you a reconnection handle that survives across calls. The README also claims support for up to 5 million sandboxes in a single project. Treat that as a stated design ceiling rather than a measured one; nothing in the material shows how the scheduler behaves at that scale.

Getting from install to a running sandbox

Two install paths, and they are genuinely different artifacts. The Python SDK comes from PyPI with `pip install tensorlake`. The `tl` CLI does not: the README states it is distributed as a standalone binary, not through PyPI or npm, and is installed with `curl -fsSL https://tensorlake.ai/install | sh`. If your build pipeline assumes every tool arrives through a package manager, that curl-and-pipe step is a supply-chain decision you have to make deliberately. Authentication is an environment variable plus a login: `export TENSORLAKE_API_KEY="your-api-key"` then `tl login`. The CLI surface covers the lifecycle in single commands. `tl sbx create` returns an id. `tl sbx exec <sandbox-id> -- sh -lc "..."` runs a command. `tl sbx cp ./my_script.py <sandbox-id>:/tmp/my_script.py` moves files in. `tl sbx ssh <sandbox-id>` opens an interactive terminal. `tl sbx terminate <sandbox-id>` cleans up. In Python the equivalent is a context manager, and the README notes the sandbox is automatically terminated when it exits, which is the behavior you want and also the behavior that will surprise you if you expect a sandbox to outlive the `with` block. The image argument deserves attention. Omitting `--image` selects Tensorlake's default managed environment, and the README states plainly that to select a custom environment you pass the name of a registered Sandbox Image; arbitrary Docker image references are not supported. That constraint shapes your whole build process, because it means your image has to be registered through Tensorlake rather than pulled from a registry you already control.

Network policy is per-sandbox and per-pool, and claimed sandboxes do not follow a pool update

Outbound access is controlled at the sandbox level. `tl sbx update <sandbox-id> --no-internet` blocks all outbound traffic on a running sandbox. `tl sbx update <sandbox-id> --network-allow api.example.com` narrows egress to named destinations. `tl sbx update <sandbox-id> --clear-network` removes the policy and restores unrestricted outbound access. In Python the same idea is `NetworkConfig(allow_internet_access=False)` at pool creation. The detail worth reading twice is what happens when a pool's policy changes. The README states that on a change the service recycles the pool's unclaimed warm containers onto the new policy, while containers already claimed by sandboxes keep the policy they booted with. So tightening a pool's egress rules does not retroactively tighten the sandboxes you already handed out. If your threat model assumes a policy flip propagates to everything running, it does not. You have to expire or terminate claimed sandboxes yourself. This is a defensible design (a running VM cannot have its network namespace rewritten without disrupting it) but it is the kind of thing that is easy to miss in a first read of the API. The allow-list model is also hostname-based, so if your agent needs to reach an arbitrary set of endpoints chosen at runtime, the policy has to be permissive or the sandbox has to be recreated.

Cloud Volumes: durable file trees that mostly bypass the API service

FilesystemClient is a separate capability from sandboxes, and the README is unusually specific about its data path. SDK writes hash files locally, upload only the missing 64 MiB parts directly to checksum-bound object-store URLs, and then atomically publish metadata. Reads resolve an authenticated immutable plan and fetch the selected records directly from signed object-store URLs. The README adds that file payloads normally do not pass through the Tensorlake API service. That last sentence is the design claim: the control plane handles metadata and signing, the data plane is object storage, and your bytes do not transit a service that could become a bandwidth bottleneck. The 64 MiB part size tells you the intended workload is large files rather than many tiny ones; a directory of thousand-byte config files will not benefit from part-level deduplication. The README's example is TypeScript, `new FilesystemClient({ apiKey: "your-api-key" })` then `await client.create("agent-artifacts")`, with the comment that all changes become visible atomically. Note that the example in the supplied material is truncated mid-sentence, so the write path is described but not shown. The claim that changes become visible atomically is the important one for agents that checkpoint state, because it means a reader never sees a half-written tree.

Where Tensorlake is the wrong tool

The clearest limitation is stated by the project itself: arbitrary Docker image references are not supported, only registered Sandbox Images. If your deployment already depends on images built and scanned in your own registry, adopting Tensorlake means adding a registration step and a second place where image provenance lives. The second limitation is network policy granularity. Hostname allow-lists and an all-or-nothing `--no-internet` flag cover a lot of cases, but there is no mention of per-port rules, bandwidth caps, or egress logging in the material, so an audit requirement that needs byte-level accounting is not addressed here. Third, the CLI install path is a curl-piped shell script, which some organizations prohibit outright. Fourth, the performance claims in the README are self-reported and contextual: the SQLite comparison is given for 2 vCPUs and 4 GB RAM against named alternatives, and the README does not describe the benchmark harness. Those numbers are a starting hypothesis for your own test, not a procurement input. Finally, the release cadence visible in the material is aggressive, with CLI versions 0.5.128, 0.5.129 and 0.5.130 published within roughly two days. Frequent patch releases on a 0.x CLI mean you should pin a version and read the notes between bumps rather than tracking latest.

How it compares to running your own container runtime

The obvious alternative is a self-hosted container runtime on your own machines, whether that is plain Docker, Kubernetes with a sandboxing runtime, or gVisor. The difference in approach is not just isolation strength. With containers you own the scheduler, the image registry, the snapshot mechanism and the idle-reclamation policy, and you pay for that ownership in engineering time. Tensorlake moves all four behind an API: Lattice schedules, pools pre-warm, suspend/resume handles idleness, and snapshots are a client call. The trade is control. You cannot choose the kernel, you cannot pull an arbitrary image, and your network policy vocabulary is the one the API exposes. There is also a second class of alternative worth naming: running the code in-process or in a subprocess with a seccomp profile. That is cheaper and has no network round trip, and for trusted code it is the right call. The reason to reach for MicroVMs is untrusted code, and the README is explicit that the sandbox API is meant for running agents or as an isolated environment for tools or LLM generated code. If your code is not model-generated or third-party, the isolation is buying you less than the operational cost.

Licence, maintenance and what to check before you commit

The repository is Apache-2.0, which permits commercial use, modification and redistribution, and includes an express patent grant. That is a permissive licence and imposes no copyleft obligation on your own code. It does not, however, grant you anything about the hosted service at cloud.tensorlake.ai, which is governed by separate terms; the licence covers the client code in this repository, not the runtime you connect to. That distinction matters if you are evaluating this for a regulated environment, because the interesting behavior (scheduling, suspend/resume, snapshotting) happens server-side and is outside the licence's scope. On maintenance, the material shows an active release stream on the CLI and a last push within the recent window, but it does not show a changelog, a deprecation policy, or a support commitment. The README points to docs.tensorlake.ai and a Slack workspace, and references a `docs/sandbox-errors.md` file for failure diagnostics, which suggests error handling is documented in-repo rather than only on the website. The practical upgrade cost is the 0.x version number: pin the CLI binary and the `tensorlake` package version together, and read the release notes for each bump, because a CLI at 0.5.130 with three releases in two days is not a stable interface you can float.

Editorial conclusion

Adopt Tensorlake if your agent workload needs MicroVM isolation, filesystem state that survives a suspend, and the ability to fan work out across many short-lived functions from the same SDK. Do not adopt it if you only need to execute a handful of trusted scripts per request, or if you require arbitrary Docker image references, which the documentation says are not supported; registered Sandbox Images are the only path. Before committing, verify three things against your own account: that `tl sbx create` returns in the sub-second range the README claims, that a snapshot taken with `client.snapshot_and_wait` restores the process state you depend on, and that your outbound destinations fit the allow-list model behind `tl sbx update --network-allow`.

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. tensorlakeai/tensorlake on GitHub