AIStor Memory
Integrations

Vercel Sandbox

Mount an AIStor Memory Bucket at /workspace in a Vercel Sandbox, so the agent's files and memory outlive the microVM.

A Vercel Sandbox runs each sandbox in its own Firecracker microVM and deletes the microVM when the run ends. AIStor Memory mounts a Memory Bucket at /workspace, so the files the agent works on and the memory it keeps are stored in your AIStor. The next sandbox mounts the same bucket and starts where the last one stopped.

Prerequisites

Use a Memory Bucket

aimem mounts only a Memory Bucket. See Prerequisites.

  • A Vercel token, team ID, and project ID.
  • Node.js and npm on the machine that runs the example.
  • An AIStor endpoint that the sandbox can reach, and signing credentials for it.

Quick start

  1. Download the example, then create the settings file:

    mkdir aimem-vercel && cd aimem-vercel
    base=https://docs.min.io/aimem/examples/vercel
    for f in aimem-mount package.json usage.ts; do
      curl -fsSLO "$base/$f"
    done
    curl -fsSL "$base/env.example" -o .env.example
    chmod +x aimem-mount
    cp .env.example .env
    $EDITOR .env

    Fill in VERCEL_TOKEN, VERCEL_TEAM_ID, VERCEL_PROJECT_ID, AIMEM_ENDPOINT, AIMEM_BUCKET, AIMEM_ACCESS_KEY, and AIMEM_SECRET_KEY. For temporary credentials, also set AIMEM_SESSION_TOKEN.

  2. Install the dependencies and run the example from the same directory:

    npm install
    npm start

usage.ts creates a sandbox, downloads the released linux/amd64 aimem binary, checks it against its published .sha256sum, and uploads it with the aimem-mount wrapper. It mounts the bucket at /workspace, removes the storage credentials from the environment the agent's commands run in, writes a file through the mount as the non-root sandbox user, and then stops the sandbox. You do not need to build anything.

To pin a release, set AIMEM_VERSION=RELEASE.<date>. The default is latest.

How the mount works

The microVM runs Amazon Linux 2023 on x86_64. A FUSE mount needs root, so the wrapper runs aimem under sudo. aimem opens /dev/fuse and mounts directly, with no setuid helper and no fuse package.

The wrapper writes a --config YAML file, because the access settings allow_other, uid, gid, dir_mode, and file_mode exist only as config keys:

  • allow_other lets the non-root sandbox user use the mount.
  • uid and gid give the files to that user, so the agent's tools can write without sudo.
  • Writable dir_mode and file_mode keep access working when Vercel runs separate command sessions under different user namespaces.

Set the staging directory (local: or --local) to a path under /vercel/sandbox, which is on disk. Do not use /tmp, which is held in memory.

Because the mount runs under sudo, aimem installs its agent skill in root's home directory (/root/.agents/skills/aimem/ and /root/.claude/skills/aimem/), outside /workspace. For an agent that runs outside the sandbox, install the skill with npx skills add minio/skills/aimem. See SKILLS.

Long-lived agents

Each Vercel Sandbox session has a time limit: up to 45 minutes on Hobby, and up to 24 hours on Pro and Enterprise. The mount lasts only as long as the sandbox process. When you resume a persistent sandbox, Vercel restores its filesystem but does not restart aimem, so run the mount again on each resume:

const sandbox = await Sandbox.getOrCreate({
  name: "my-agent",
  // upload aimem + aimem-mount once, on first create
  onCreate: async (sb) => {
    /* writeFiles(...) */
  },
  // re-run the mount on every resume (aimem-mount is idempotent — it exits
  // early if /workspace is already mounted)
  onResume: async (sb) => {
    /* runCommand sudo aimem-mount */
  },
});

Limitations

  • Use a current aimem release. aimem agrees on a FUSE protocol version with the kernel at mount time, and an older build can fail against the microVM's kernel.

Reference