AIStor Memory
Integrations

GitHub Codespaces

Give a Codespace agent durable memory on MinIO AIStor — the AIStor Memory devcontainer Feature mounts your cortex into any devcontainer.json host, published on GHCR and portable across every devcontainer.json runtime.

Status — Ready

Self-serve today: the AIStor Memory devcontainer Feature is published on GHCR (ghcr.io/miniohq/aimem) — add it to any devcontainer.json.

A Codespace is disposable — when it is torn down, everything the agent did in it goes too. AIStor Memory gives the agent in that Codespace durable memory: one mount of a MinIO AIStor Memory Bucket (a cortex) that it both works in and remembers through, so the files it edits and the knowledge it accumulates survive teardown and the next Codespace re-mounts the same state. Everything persists to your AIStor — your storage, your keys.

The AIStor Memory devcontainer Feature is how that memory reaches the Codespace. It injects an install script and an env-var contract into any devcontainer.json-aware host, so the same Feature mounts the cortex in Codespaces, VS Code Dev Containers, JetBrains Gateway, CodeSandbox, and Daytona's devfile import — write the integration once and it runs on all of them.

Quick start

The bucket must be a cortex

aimem mounts only a Memory Bucket (cortex), never a plain S3 bucket. Before you set AIMEM_BUCKET, create the cortex launcher-side with aimem cortex create my-project --endpoint-url https://aistor.example.com (or aimem cortex convert an existing bucket). At mount time aimem verifies over the Memory API that the target is a cortex, that an explicit endpoint URL is set, that real signing credentials are present (AIMEM_ACCESS_KEY / AIMEM_SECRET_KEY — anonymous mounts are refused), and that the AIStor server is on a paid/Enterprise tier; a plain bucket fails with 'my-project' is not a Memory Bucket (cortex). See Prerequisites.

Set the Codespaces environment once:

gh secret set -f - --user --app codespaces <<'EOF'
AIMEM_BUCKET=my-project
AIMEM_ENDPOINT=https://aistor.example.com
AIMEM_ACCESS_KEY=...
AIMEM_SECRET_KEY=...
EOF

Then add the Feature to your project's .devcontainer/devcontainer.json:

{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/miniohq/aimem:1": {}
  },
  "postCreateCommand": "aimem-mount"
}

Open the Codespace; AIStor Memory is mounted at /workspaces/aimem before your first terminal opens.

Options

OptionDefaultNotes
bucketFallback if AIMEM_BUCKET is not set at runtime
endpointUrlFallback if AIMEM_ENDPOINT is not set at runtime
mountpoint/workspaces/aimemWhere the bucket appears inside the container
localDir/tmp/aimem-localLocal --local disk store for staging and read cache
agentautoclaude / codex / cursor / auto
versionlatestPin in production

How the Feature works

The install script:

  1. Installs fuse3, the aimem binary, and a setuid-root aimem-fusermount helper into the Codespace image (the helper lets the non-root remoteUser complete the mount).
  2. Writes /usr/local/bin/aimem-mount, a wrapper that idempotently mounts the configured cortex. The wrapper reads AIMEM_BUCKET, AIMEM_ENDPOINT (or AIMEM_ENDPOINT_URL), AIMEM_ACCESS_KEY, and AIMEM_SECRET_KEY at runtime — bailing if the bucket, endpoint, or either credential is missing — then invokes aimem <bucket> <mountpoint> --endpoint-url … --local … --agent … --foreground, passing the non-secret mount settings from the Feature options as flags (credentials stay in the environment, never on the command line).
  3. Drops /etc/profile.d/99-aimem-mount.sh so the mount happens on first interactive shell (best-effort).

If your tooling needs the mount before any shell opens, keep the postCreateCommand: "aimem-mount" line in devcontainer.json.

Portability

Because the same Feature runs on every host that reads the devcontainer.json spec, it mounts AIStor Memory on all of them — not just Codespaces. The Daytona page and E2B page both refer back to this Feature for the install half of their integrations.

Reference