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
npmon the machine that runs the example. - An AIStor endpoint that the sandbox can reach, and signing credentials for it.
Quick start
-
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 .envFill in
VERCEL_TOKEN,VERCEL_TEAM_ID,VERCEL_PROJECT_ID,AIMEM_ENDPOINT,AIMEM_BUCKET,AIMEM_ACCESS_KEY, andAIMEM_SECRET_KEY. For temporary credentials, also setAIMEM_SESSION_TOKEN. -
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_otherlets the non-root sandbox user use the mount.uidandgidgive the files to that user, so the agent's tools can write withoutsudo.- Writable
dir_modeandfile_modekeep 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
aimemrelease.aimemagrees on a FUSE protocol version with the kernel at mount time, and an older build can fail against the microVM's kernel.
Reference
usage.ts, theaimem-mountwrapper,.env.example, andpackage.json: the example.- Vercel Sandbox documentation.