E2B

E2B runs each agent sandbox in a Firecracker microVM that is deleted when the run ends. AIStor Memory mounts a Memory Bucket at /workspace, so the files the agent works on and the memory it keeps (memory files, annotations, object metadata, and search) are stored in your AIStor. The next sandbox mounts the same bucket and starts where the last one stopped.

Prerequisites

• An E2B API key.
• The aimem binary on the machine that runs the example, to create the Memory Bucket.
• An AIStor endpoint that the sandbox can reach, and signing credentials for it.

Quick start

Download the example, then run these commands from that directory:

mkdir aimem-e2b && cd aimem-e2b
base=https://docs.min.io/aimem/examples/e2b
for f in aimem-mount build.sh e2b.Dockerfile package.json run.sh usage.ts; do
  curl -fsSLO "$base/$f"
done
chmod +x aimem-mount build.sh run.sh
mkdir -p bin

export E2B_API_KEY=...
export AIMEM_BUCKET="my-project"
export AIMEM_ENDPOINT="https://aistor.example.com"
export AIMEM_ACCESS_KEY=...
export AIMEM_SECRET_KEY=...

# Create the Memory Bucket once, launcher-side, with admin credentials. Skip if it
# already exists (or run `aimem convert` to upgrade an existing bucket).
aimem create "$AIMEM_BUCKET" \
  --endpoint-url "$AIMEM_ENDPOINT" \
  --access-key "$AIMEM_ACCESS_KEY" \
  --secret-key "$AIMEM_SECRET_KEY"

./build.sh
./run.sh

The Memory Bucket commands (aimem create and the rest) do not read AIMEM_ENDPOINT. They read --endpoint-url or AIMEM_ENDPOINT_URL, so pass the flag as shown.

• build.sh publishes the aimem-workspace template from e2b.Dockerfile. The template downloads the released binaries when it is built. The script uses the e2b CLI if it is installed, and npx @e2b/cli@latest if not.
• run.sh creates a sandbox from the template, starts aimem-mount, waits for /workspace, writes a test file through the mount, prints it, and deletes the sandbox.

To pin a release:

./build.sh --build-arg AIMEM_VERSION=RELEASE.<date>

To use a different template name:

TEMPLATE_NAME=my-aimem-template ./build.sh
AIMEM_E2B_TEMPLATE=my-aimem-template ./run.sh

How the mount works

E2B does not pass the envs of Sandbox.create to the template's start_cmd. The mount therefore starts after the sandbox is created: your code runs aimem-mount with sb.commands.run and the AIStor Memory environment variables. The mount is ready in a few seconds.

Writes are staged in /tmp/aimem-staging on the sandbox's local disk and uploaded to the Memory Bucket when the file is closed. The aimem-mount wrapper sets this required staging directory (--local).

E2B's microVMs give the sandbox user read and write access to /dev/fuse. aimem runs without privileges and passes the device to the setuid-root aimem-fusermount helper, which performs the mount. The Dockerfile installs the helper and gives the mountpoint to the sandbox user, because the helper mounts only on a directory the caller owns. You do not need host capability flags.

Give the agent its secrets

The storage credentials reach the sandbox only in the environment of the one-time mount command. When the agent needs its own credentials, such as a model API key, deliver them with aimem secret provision rather than in envs. The command fetches only the granted secrets, from a Memory Bucket (--bucket <name>) or an HTTP secret store (--store-endpoint), starts the agent with those values as environment variables, and removes the store credential from the agent's environment:

aimem secret provision --bucket "$AIMEM_BUCKET" \
  --endpoint-url "$AIMEM_ENDPOINT" \
  --grant OPENAI_API_KEY=openai-key \
  -- my-agent --run

To store a secret in the Memory Bucket, run aimem secret put <bucket> <name> on the launcher, with the value from --value or standard input. The server encrypts it at rest.

Reference

• e2b.Dockerfile, aimem-mount, build.sh, run.sh, and usage.ts: the example.
• E2B sandbox template documentation.