Daytona

A Daytona sandbox is disposable, but the agent's memory should not be. AIStor Memory gives the sandbox durable memory: one mount of an AIStor Memory Bucket (a cortex) that the agent works in and remembers through. The sandbox is torn down, but the files and the knowledge stay in the cortex. The next sandbox re-mounts the same state at full fidelity — the real files, byte-for-byte. The mount is the durable workspace form of that memory, mounted at /workspace.

usage.py also exercises the preferred external-worker boundary: the Daytona SDK remains on the controller, storage credentials are removed before the worker phase, and typed list/read/write calls execute through sandbox.process.exec against the AIStor Memory workspace.

Run AIStor Memory in a Daytona linux-vm sandbox. Daytona container sandboxes don't reliably expose /dev/fuse: much of the fleet runs them without CAP_MKNOD, so aimem-mount can't create the device either and the mount fails. A linux-vm sandbox has full kernel and device access.

VM sandboxes are created from a VM snapshot, so the example in this repo builds a linux-vm snapshot from a stock OS image (ubuntu:24.04 by default — Daytona's declarative image builder does not run for us-east-1 or linux-vm). It then creates the sandbox from that snapshot as os_user="root", installs aimem into the running sandbox with aimem-setup.sh, and starts aimem-mount in a Daytona process session. The bucket name, endpoint URL, and credentials are handed to the mount through a root-only /root/aimem.env file the session sources — never a command line, env_vars, or a baked image layer.

aimem cortex create my-project \
  --endpoint-url https://aistor.example.com \
  --access-key ... --secret-key ...

Quick start

Run from the AIStor Memory repo root. usage.py creates ~/.cache/daytona-aimem and installs the Daytona Python SDK there if it is not already importable. The released binaries fetch from the public CDN by default, so nothing else needs to be staged locally.

DAYTONA_API_KEY=... \
AIMEM_BUCKET=my-project \
AIMEM_ENDPOINT=https://aistor.example.com \
AIMEM_ACCESS_KEY=... \
AIMEM_SECRET_KEY=... \
python3 examples/daytona/usage.py

When the command returns, the sandbox is still running. The final stderr line prints the sandbox ID and confirms /workspace is the AIStor Memory mount. Writes stage to /tmp/aimem-staging and upload atomically on close.

Set DAYTONA_DELETE_ON_EXIT=1 only for disposable smoke runs.

The endpoint in AIMEM_ENDPOINT must be reachable from Daytona's egress network. Standard Daytona plans permit outbound HTTPS to arbitrary public hostnames including *.trycloudflare.com; the automated CI test uses a cloudflared quick tunnel against a runner-local AIStor.

What usage.py does

Optional knobs

• AIMEM_MOUNTPOINT defaults to /workspace.
• AIMEM_LOCAL defaults to /tmp/aimem-staging.
• AIMEM_REGION, AIMEM_PREFIX, AIMEM_AGENT, and AIMEM_ALLOW_OTHER=true pass through to aimem-mount.
• Offline or unreleased builds can stage a Linux aimem binary in examples/daytona/bin/; aimem-setup.sh installs the staged binary before falling back to the CDN. This is the path CI uses.

FUSE availability

A linux-vm sandbox exposes /dev/fuse with full device access — unlike a container sandbox, which across much of Daytona's fleet grants neither the device nor CAP_MKNOD to create it. The example creates the sandbox as os_user="root", so aimem opens /dev/fuse directly and performs the mount(2) itself — no setuid helper is involved. If Daytona has not yet materialised the device node, aimem-mount waits for it. Failing that, it creates the node with mknod, which needs CAP_MKNOD. A sandbox that grants neither the device nor CAP_MKNOD is reported as unmountable.

Reference

• examples/daytona/ — the driver (usage.py), setup script, and mount wrapper.
• Daytona Sandboxes — Daytona's sandbox lifecycle.
• Daytona Python SDK — CreateSnapshotParams(sandbox_class=SandboxClass.LINUX_VM) + CreateSandboxFromSnapshotParams(os_user="root").
• Daytona Snapshots — VM snapshots and SandboxClass.LINUX_VM.