Perplexity's SPACE Turns Agent Sandboxes Into Infrastructure You Run Yourself

An open-source Firecracker sandbox with an E2B-compatible door, and an honest look at what it takes to run one.

Every coding agent eventually wants to run code. Install a package, execute a test, open a shell, try the thing it just wrote. The only real question is where that code runs, because "on the same machine as your credentials" is the wrong answer.

For the last couple of years the usual answer has been to rent a sandbox. You call a hosted service, it hands your agent a disposable computer, and the agent breaks things there instead of on your laptop. That works, until your security team asks where the code and data go, or the bill grows with every agent you add.

SPACE, which Perplexity open-sourced under Apache-2.0 and which sat at #5 on Trendshift's daily board on October 16, offers a third option. Run the sandbox platform yourself. Each sandbox is a tiny virtual machine, your applications drive it over plain HTTP, and existing E2B code can point at it with a couple of environment variables.

The catch is in the install guide, and it is worth reading before you get excited. Owning the sandbox means owning a Linux server with hardware virtualization, a Kubernetes-shaped deployment, and the network rules for what every sandbox is allowed to reach. That last part is the real security boundary, and it is the one most people skip.

What a sandbox is, and why a microVM

A sandbox is a throwaway computer for code you do not fully trust. An agent's code counts, even when the agent is yours, because it can be steered by a malicious README, a poisoned web page or a package that does something it should not.

There are two common ways to build one. A container (Docker, for example) shares the host's operating system kernel and fences off processes. It starts fast, but the wall between the container and the host is the kernel itself. A virtual machine gives the guest its own kernel on emulated hardware, which is a much thicker wall, but traditional VMs are slow and heavy.

A microVM aims for both: a stripped-down virtual machine that boots quickly and uses little memory. SPACE uses Firecracker, the open-source microVM monitor AWS built for serverless workloads such as Lambda. Think of it as giving every agent its own tiny laptop that you can wipe in seconds, instead of a separate login on a shared one.

How SPACE is put together

The README describes a small set of ideas, and they map neatly to how an agent actually works:

A template is the starting image, like a saved snapshot of a fresh machine. The quickstart uses one called seed.
A sandbox is a running copy of a template, with its own VM and its own writable disk.
A command session is one process inside a sandbox. You start a command, then attach to its output stream to read stdout and stderr as they arrive.
An operation is how SPACE handles slow lifecycle changes. Create, pause or delete returns an operation ID, and you poll it until it finishes, instead of holding a request open.

Applications talk to all of this over HTTP and server-sent events (a simple way for a server to stream updates to a client). SPACE itself is written in Rust, but you do not need any Rust to use it. The first-sandbox walkthrough drives the whole flow with a Python script that uses only the standard library, and a create request takes fields you would expect: template, runtime (fc for Firecracker), and resources such as vcpu, memory_mib and disk_mib. The full API reference is served at /openapi-m1.json on a running deployment.

For teams that expect lots of agents, SPACE also has warm pools (sandboxes booted ahead of time so a create skips the cold start) and base snapshots that restore sandboxes on a node. Those are the features that matter once one agent becomes fifty.

One agent task, start to finish

It helps to picture a single job. Say your agent wants to run a project's test suite.

It asks SPACE for a sandbox from a template and gets back an operation ID, then polls until the sandbox is up. It opens a command session with the command as an argument list (["pytest", "-q"]), a working directory and a timeout such as 30s. It attaches to the session's stream and reads stdout and stderr, which arrive base64-encoded, as the tests run. The walkthrough treats a run as successful only when it sees a process_exited event with exit code 0 and no error frames. Then the agent deletes the sandbox, and everything it touched goes with it.

The E2B door

E2B is a popular hosted sandbox service for agents, and plenty of agent code already calls its SDK. SPACE includes an E2B Compatibility Wrapper, a separate layer that lets an existing E2B client use SPACE as its backend. The tested baseline is e2b==2.21.1 and e2b-code-interpreter==2.6.2.

On the client, the switch is two environment variables, E2B_DOMAIN pointed at your deployment and E2B_API_KEY set to a key you mint on it. The server side needs its own setup first, including creating that key, which the wrapper doc walks through. Only the pinned Python SDK versions are covered by SPACE's compatibility tests. The doc's own example:

import os
from e2b import Sandbox

sandbox = Sandbox.create(
    api_key=os.environ["E2B_API_KEY"],
    domain=os.environ["E2B_DOMAIN"],
    template="seed",
    timeout=60,
)
print(sandbox.commands.run("printf 'Hello from SPACE\\n'").stdout)
sandbox.kill()

This is the most practical idea in the repo. You can prototype against a hosted service and move to your own hardware later without rewriting the agent.

Read the limitations list before you count on it, though. Some create-time options return an error, including mcp, volumeMounts and iam. A request asking for network.allowPublicTraffic=true is rejected. Template aliases are flat, so team/template names do not work, and E2B's pause maps to SPACE's suspend. If your code relies on any of those, it will fail loudly, which beats a silent failure.

The real security boundary is the network

A microVM keeps an agent's code off your host. It does nothing about what that code can reach on the network. An agent that can make outbound requests can still send your data somewhere, VM or not.

SPACE handles this with a base network policy per tenant (a tenant is one customer or team sharing the platform) plus egress profiles, named, additive allowances that an operator defines at startup in SPACE_EGRESS_PROFILES. A profile lists extra domains, IPs or CIDR ranges (blocks of IP addresses written like 192.0.2.0/24) a sandbox may reach, and wildcard domains are rejected, so you name api.example.com exactly instead of *.example.com. Signed-in ("federated") create requests pick profiles with the X-Space-Egress-Profiles header, other creates ignore it, and explicit tenant or platform denies still win.

Two details are easy to miss. If no profile is selected and none is marked default, the sandbox gets no profile-based allowances, and only the tenant's base policy applies. And a sandbox's selected profiles are fixed for its lifetime, so changing what a running sandbox can reach means recreating it.

That is the right shape for agents. Start from a tight base, add access by name. It also means someone on your team has to write and maintain those lists, and that someone is now you.

Put this into practice

Here is the lowest-friction path, straight from the installation guide, and what to expect.

Check your host first. Run the setup in Bash, in one persistent shell session (the guide starts with exec bash). You need "an apt-based Linux x86_64 host with KVM" (the Linux kernel's built-in hardware virtualization), with /dev/kvm, /dev/net/tun, loop devices, btrfs support, and a Docker daemon that allows privileged containers. A cloud VM works only if it supports nested virtualization. The guide is blunt: these instructions "do not run directly on macOS." The installer needs root or passwordless sudo.

Clone and install the tooling.

git clone https://github.com/perplexityai/SPACE.git && cd SPACE
export INSTALL_DIR="$HOME/.local/bin"
export PATH="$INSTALL_DIR:$PATH"
bash infra/space/kind/scripts/install-prereqs.sh

That pulls in Kind (Kubernetes running inside Docker), kubectl, Helm, Tilt and friends.

Clear credentials, then deploy. This step deserves a pause. The guide warns that bootstrap copies AWS and Datadog credentials from your shell into cluster secrets, so unset them first:

unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN
unset DD_API_KEY EPPO_SDK_KEY
read -rsp 'Initial root@local password: ' SPACE_CONSOLE_PASSWORD
export SPACE_CONSOLE_PASSWORD
bash infra/space/kind/scripts/install-fc-vendor.sh
bash infra/space/kind/scripts/bootstrap.sh

Set that password. Without it, bootstrap makes the root@local password literally password. The first build compiles the Rust workspace, and the guide says it may take a long time, so start it before lunch.

Run your first sandbox. Once the deployment reports ready, the walkthrough script creates a sandbox from seed, runs a command, streams the output and checks for a clean exit:

python3 examples/first_sandbox.py

Tear it down when you are done with bash infra/space/kind/scripts/teardown.sh, then confirm with kind get clusters.

Honest limitations

It is early. The versioning doc says "SPACE 0.8.0 establishes the public release baseline," with 0.9.0 planned as the last breaking release before a stable 1.0. The GitHub repo had no published releases on October 16, and its star count was still in the hundreds, so treat it as a young public project.

The local setup is for development. The guide says the deployment uses development passwords and signing keys and should be kept private. There is a reference EKS (AWS Kubernetes) deployment in the repo, but the walkthrough is a single-host Kind cluster.

The hardware bar is real. No Mac, no Windows, no cheap VPS without nested virtualization. If your agents run on a laptop today, this is not a weekend swap.

Compatibility is partial. The E2B wrapper covers the common path, and the limits list is long. Test your actual SDK calls before you plan a migration.

You inherit the operations. Warm pools, snapshots, egress profiles and upgrades are now your job, including keeping every API replica configured the same way, which the egress doc calls out explicitly.

Who this is for

If you are a solo developer or a small team, a hosted sandbox is still the sensible default, and SPACE is worth reading mostly for its egress design. If you run many agents, already pay a sandbox bill, or have data that should not leave your own cloud, SPACE is a serious open-source starting point with a migration path built in.

Either way, start with the network question, not the VM one. Decide what your agents are allowed to reach, write it down as an allow-list, and then pick the sandbox that enforces it.

Sources: reviewed on the main branch at commit b9fc395 on October 16, 2026 (no tagged release exists). perplexityai/SPACE README · installation guide · first-sandbox walkthrough · E2B Compatibility Wrapper · egress profiles · versioning · LICENSE · Firecracker · Trendshift

Medium metadata

Title: Perplexity's SPACE Turns Agent Sandboxes Into Infrastructure You Run Yourself

Alternate titles to test:

You Don't Have to Rent an Agent Sandbox Anymore
SPACE Gives Every AI Agent Its Own Disposable Computer. Here's the Cost.

Subtitle options:

An open-source Firecracker sandbox with an E2B-compatible door, and an honest look at what it takes to run one. (picked)
Self-hosted microVMs for coding agents, plus the KVM host, Kubernetes setup and allow-lists that come with them.
Perplexity open-sourced its agent sandbox. Here is what owning one actually means.

Description: Perplexity open-sourced SPACE, a Firecracker sandbox for AI agents with an E2B-compatible API. What it does, how to run it, and its real costs.

Tags:

AI Agents: the core audience building agents that run code.
Open Source: Apache-2.0 release from a major AI company.
Cybersecurity: sandboxing and egress control are security decisions.
Kubernetes: the deployment path is Kind and EKS.
Software Development: practical setup guide for working developers.

Article type: A (spike), a real repo with a clear payoff.

Publish plan: post at 7 to 8 AM ET, let Medium distribute for 2 to 6 hours, send to subscribers only if it is performing.