SPACE: Firecracker microVMs for running agent and user code in isolation

A sandbox platform where the application keeps control

SPACE stands for Sandboxed Platform for Agentic Code Execution, and the description is precise about the division of labour. Applications use its HTTP API to create Linux environments, execute commands, collect output and manage sandbox lifecycles. The README states the split directly: your application decides what to run and what results to keep, while SPACE manages the sandbox, its processes and the connection that carries command output.

The isolation unit is a Firecracker microVM, not a container and not a process. Each sandbox is a full virtual machine with its own writable filesystem, which is the difference that matters for the intended use case. Agent runtimes and user submitted code do unusual things, write unexpected files, open unexpected sockets and assume they own the machine. A microVM boundary contains that in a way a container boundary does not.

The audience is therefore applications that execute code for somebody else, or for an agent that may go off script. A developer running a script on their own laptop does not need this, and the operational weight of microVMs is significant. A platform that lets customers or agents run arbitrary code in a hosted environment does, and the cost of a lighter isolation model shows up as a security incident rather than as a bug.

The implementation language is Rust, but that is not a constraint on the adopter. The README says plainly that applications interact over HTTP and server-sent events, that you do not need to embed a Rust library to use it, that the first sandbox walkthrough runs a standard-library-only Python example, and that installation and cluster diagnostics use Bash.

Templates in, sandboxes out, and an operation ID in between

The object model is small and worth understanding before reading the API reference. A template supplies the starting environment, and a sandbox is an instance of that environment with its own VM and writable filesystem. Multiple commands can run inside the same sandbox, which is what makes it a workspace rather than a one-shot runner.

The lifecycle is described as asynchronous. When you change a sandbox's state, the API returns an operation ID that you poll for completion. That single design choice explains several parts of the API surface, including the troubleshooting guide's section on safe retries, since a retried lifecycle call can duplicate an operation rather than replace it.

Command output travels on a different path from the control plane. The output uses a separate data-plane connection and a session-scoped attachment token, so a client that starts a command has to obtain a token and attach to the stream to read what the process wrote. The repository layout confirms the split at the code level, with a dedicated data plane service under crates/apps/data/plane/svc and a separate gateway for network handling.

Two lifecycle verbs are worth separating, and the architecture guide is explicit that pause and suspend preserve different things. The README's flow lists keeping, pausing or suspending a sandbox, and waking it when needed, so a caller has to pick the right verb for the state it wants to resume from. A platform that conflated those would be much simpler to describe and much harder to use.

Getting to a first sandbox on a local Kind cluster

The setup path is documented in two steps. docs/installation.md covers deployment in a local Kind cluster along with authentication, and docs/first-sandbox.md is the walkthrough that runs a command and collects its output. The setup guide covers Kubernetes, and the architecture guide also explains how SPACE can run without it, so the platform is not tied to a single orchestrator even though the local development loop is.

For the development loop itself, the README gives one command, run from the repository root after the local installation:

tilt up

Tilt rebuilds the affected images and rolls their workloads as files change, and the Kind runbook under infra/space/kind/ covers that loop, the local topology and template builds. The repository is set up for this kind of iteration, with a Tiltfile, a lefthook configuration, a pre-commit configuration, a clippy configuration and a deny configuration for dependency checks.

For the operator side there is a dedicated CLI, documented at crates/apps/admin/cli/README.md, covering API access, port forwarding, the space-admin-cli login command, node management, warm pools and system template builds. A separate SSH CLI and a volume manager CLI exist in the workspace as well.

The documentation itself is built from the repository with a shell script, and the local browsing commands are:

bash scripts/build-docs.sh
python3 -m http.server 8000 --bind 127.0.0.1 --directory target/docs/site

That serves the guide and API reference together on a local port, and the build needs Git and Python 3.11 or newer. The standalone scripts build the guide and the API reference separately, and they also work with uncommitted edits, which matters when you are writing the documentation for a change you are still making.

The hosted versions of the same documents update automatically once changes merge, so reading the online guide is the fast path and the local build is the one you need when you are changing the code.

Warm pools and base snapshots attack the cold boot cost

A microVM per sandbox means paying a boot for every sandbox you create, and boot time is the cost that decides whether this design works for an agent that spawns a sandbox per step. The project has two answers to that, and both are documented as separate guides.

Warm pools keep booted sandboxes ready on Kubernetes so that creates skip a cold boot. The idea is straightforward: hold a stock of running sandboxes, hand one over when a create arrives, and let the operator manage the pool's size and its template. The operator CLI documentation lists warm pool management alongside node management, which is the right place for that control to live.

Base snapshots go further and restore a sandbox from a snapshot on a single node, optionally combined with a node warm pool. That is a different trade from a warm pool, because it changes what a new sandbox starts from, not when it is created. A snapshot captures a prewarmed filesystem, and the restore avoids the guest boot that a template plus warm pool would still pay.

Both features sit next to the sandbox store and snapshot storage libraries in the Rust workspace, with crates/libs/sandbox/store, crates/libs/snapshot/store, crates/libs/snapshot/storage and crates/libs/snapshot/retention as separate crates, which suggests the retention of snapshots is treated as its own concern rather than a detail of the sandbox path.

What the documentation does not publish is a boot time figure or a per-snapshot cost, so the operational sizing of a pool is something you have to measure on your own hardware. The versioning guide's notes on service stability are the place to look for what is considered settled enough to depend on.

The E2B compatibility wrapper is the migration path, and it has edges

If you already run code for agents with an E2B based stack, the documentation has a dedicated guide for it: docs/ecw.md covers configuring the E2B Compatibility Wrapper, creating a compatibility API key, using the tested E2B Python SDK, and understanding the supported behavior and the limitations. That is the whole of the compatibility story, and the guide is explicit that some behavior is not supported.

The wrapper exists because the E2B API surface is a de facto standard for agent sandboxes. ECW lets an existing client keep its SDK and talk to SPACE underneath, which is a much smaller change than rewriting an agent runtime against a new protocol. The repository's Python test project shows how concrete that path is: the space-smoke project depends on a pinned e2b release, 2.21.1, alongside OpenTelemetry SDK and exporter packages for telemetry, and its test group pulls in boto3, pytest, requests, psycopg, cel-python, pglast, python-hcl2 and pyyaml. So the E2B surface is exercised by the smoke suites, not merely documented.

The limits are the part to read. A compatibility wrapper is a translation, and anything the target platform does differently shows up as a difference in behavior, which is exactly what the guide's limitations section is for. The E2B approach also gives you an alternative architecture to compare against, and the difference is architectural rather than cosmetic. An E2B based system is built around a managed service, where the provider owns the microVM fleet and the API. SPACE is the fleet itself, with templates, warm pools, snapshots, node management and an operator CLI under your control.

That control is the reason to run your own. It is also the reason the operational surface is larger than an API client.

Where the platform is more than you need, and where it is not enough

The first limitation is scope of isolation. Firecracker microVMs are the right boundary for code that is genuinely foreign to you, and they are overkill for code you wrote and trust. If your agent only runs a shell command from a template you control, in an environment with no secrets and no network egress, a container or a process sandbox gives you a much smaller operational bill. The README does not present SPACE as a light tool, and the presence of egress profile guides and credential management services in the workspace says that the platform is built for environments where the code being run is a risk to be managed.

The second limitation is the contract boundary. Fields marked incubating in the schema are outside the supported contract, which means a client built against them can break when they change. The API reference is generated and served at /openapi-m1.json, so you can read the current state of the schema, and it also tells you which fields you should not depend on.

The third is operational. The local development loop assumes Docker, Kind, Tilt and a Rust toolchain, the service is deployed as a set of Kubernetes workloads with their own services, and the operator surface includes node, template, volume, credential and snapshot management. The observability guide goes as far as describing a Rust and Go selector contract and unchanged image defaults, which is a hint that turning telemetry on is a configuration decision rather than a default.

A fourth point is about trust in the project itself. There are no GitHub releases, so there is no tagged version to pin, no release notes to diff and no published changelog for a breaking change. The versioning guide covers release progression, supported guests, service stability and upgrade and rollback requirements, and it is the only place those answers live. The last push was on 2026-10-19 and the repository is not archived, so the code is being worked on, but the deployment story rests on a guide rather than on a versioned artefact.

A Rust workspace that treats the boundary as the product

The repository layout explains the shape of the system better than any summary. crates/apps/ holds the CLI tools and service binaries, crates/libs/ the shared libraries, proto/ the gRPC protobuf definitions, templates/firecracker/ the seed builder and template recipes, docker/ the service Dockerfiles and Rust artifact build, ci/ the CI checks and artifact build scripts, infra/space/kind/ the local Kind configuration and runbook, and infra/space/aws/reference/ a reference EKS deployment that is applied on a schedule.

The Cargo workspace members show how many separate processes a deployment involves: an API service, an internal API, a cluster controller, a builder service, a database migrator, a credential manager, a data plane, a network gateway with a benchmark binary, a node API and several node control and runtime services, a sandbox manager, a template manager and publisher, a volume manager, a guest agent and host, an SSH CLI, and even mock services for a large language model and a branching key provider. The libraries split along the same grain, with separate crates for guest execution, guest protocol, host client and server, sandbox store, teardown, portability, snapshot storage and retention.

The supporting repository shows the care taken around the supply chain. There is a .gitleaks.toml for secret scanning, deny.toml for dependency policy, a supply-chain/ directory, a clippy configuration, a lefthook file and a pre-commit configuration, plus SECURITY.md and a .agents/ directory. ARCHITECTURE.toml and architecture-baseline.toml sit at the root, which suggests the architecture is described in a machine readable form that can be checked rather than only in prose.

Licensing is Apache License 2.0, with the LICENSE file in the repository root. That is a permissive licence with an explicit patent grant, and this is a technical read of the repository rather than legal advice, so the exact obligations for your distribution should be confirmed by your own counsel.

Editorial conclusion

Adopt SPACE when your application runs code it does not fully control, an agent needs a disposable Linux environment per job, and you can operate Kubernetes and accept microVM cold start costs. Do not adopt it for untrusted workloads on a shared host where a process level sandbox would do, and do not treat the incubating fields in the schema as stable, since the documentation places them outside the supported contract. Before you deploy, read docs/versioning.md for the release progression and rollback requirements, work through docs/installation.md for a local Kind cluster, and check docs/ecw.md if you intend to keep an existing E2B based client, then pin a commit because the repository publishes no GitHub releases.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. perplexityai/SPACE on GitHub
4. README