Devin (Cognition)

Each Devin session starts in a fresh sandbox. With AIStor Memory, the session would mount a Memory Bucket that holds its files and the memory it keeps, in your AIStor. The next session, on any host, mounts the same bucket and starts where the last one stopped.

This integration is not self-serve. Devin has no public sandbox-extension API, so it needs two changes that only Cognition can make: bundling aimem into the runner image, and adding a storage field to each session. This page describes that design. To use it, contact your MinIO representative.

Devin keeps workspaces today by snapshotting the whole sandbox VM, which ties the workspace to one host's local disk. With the workspace in a Memory Bucket, any host can resume a session by mounting the bucket, and the VM snapshot becomes an optimization rather than a requirement.

How it would work

1. Runner image bundles aimem, FUSE userspace, and devin-aimem-workspace.
2. Control plane exposes one per-session workspace_storage field with bucket (a Memory Bucket), endpoint_url, and credentials_secret_ref.
3. Runner startup maps that field to environment variables and runs devin-aimem-workspace mount before the agent starts.

AIStor Memory provides everything else: atomic uploads, agent-memory warmup, and the aimem skill.

Runner contract

The session field is small:

{
  "workspace_storage": {
    "kind": "aimem",
    "bucket": "team-foo-devin",
    "endpoint_url": "https://aistor.team-foo.example.com",
    "credentials_secret_ref": "devin-aimem-team-foo"
  }
}

The runner resolves credentials_secret_ref to the bucket's signing credentials and exports them as AIMEM_ACCESS_KEY and AIMEM_SECRET_KEY (plus AIMEM_SESSION_TOKEN for temporary credentials). It also exports AIMEM_BUCKET and AIMEM_ENDPOINT_URL, then runs:

devin-aimem-workspace mount

To create credentials limited to one Memory Bucket, run aimem credentials team-foo-devin. It prints export lines for AIMEM_ACCESS_KEY, AIMEM_SECRET_KEY, and AIMEM_SESSION_TOKEN that you can source.

The hook mounts the workspace at /workspace and uses /var/cache/aimem/devin as AIStor Memory's required local staging directory. It writes the config to /etc/aimem/devin.yaml, with the required version: "1.0" key, the endpoint from AIMEM_ENDPOINT_URL, and the staging directory. The mount is then one --config command with no other flags:

aimem team-foo-devin /workspace --config /etc/aimem/devin.yaml

# /etc/aimem/devin.yaml — written by the hook from the runner's env
version: "1.0"
endpoint_url:
  - https://aistor.example.com # from $AIMEM_ENDPOINT_URL
local: /var/cache/aimem/devin

Signing credentials stay in the environment, never in a flag or the YAML. The staging directory can also come from the --local /var/cache/aimem/devin flag or the AIMEM_LOCAL environment variable; at least one of the three is required.

On pause or teardown, the runner runs:

devin-aimem-workspace unmount

Give the agent its secrets

The mount does not give the agent any secrets. To give the agent credentials, the runner runs aimem secret provision before it starts the agent:

# Keep the store token in the launcher env, not argv (argv shows up in
# process listings and shell history).
AIMEM_SECRET_STORE_TOKEN="$STORE_TOKEN" \
aimem secret provision \
  --store-endpoint "$STORE_URL" \
  --grant OPENAI_API_KEY=openai --grant GITHUB_TOKEN=gh-pat \
  -- <agent-command>

This fetches only the granted secrets from your store and passes them to the agent as environment variables. aimem removes the store token and the mount credentials from the agent's environment. --grant VAR=secret-name is required and can be repeated.

If the secrets are stored in the Memory Bucket (written with aimem secret put team-foo-devin <name>), use --bucket team-foo-devin instead of --store-endpoint. Use exactly one of the two. The bucket source uses the same AIMEM_ENDPOINT_URL, AIMEM_ACCESS_KEY, and AIMEM_SECRET_KEY as the mount.

What this gives you

• Resume on any host. The bucket holds the session's files and memory, so any host can mount it and continue.
• Cost follows the working set. Only files the agent writes are stored, not the whole VM state.
• Portable memory. The same bucket works in any region or cloud. SaaS and customer-VPC deployments use the same design; only the storage backend differs.

Get in touch

If you run Devin, as SaaS or in your own VPC, and want to try Memory Bucket workspaces for your sessions, contact your MinIO representative.