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; the files and the knowledge stay in the cortex, and 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 — whereas 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), creates the sandbox from it 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 and, failing that, creates it with mknod (which needs CAP_MKNOD); a sandbox that grants neither 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.