Mount from a sandbox

The API key stays on your backend. The sandbox receives only a one-time ticket, which it exchanges for a session certificate.

1. Create an API key and grant it

In the console, open API keys and create a key. Its secret (mtbl_…) is shown once; store it in your secret manager. Then open the filesystem and grant the key rw (or ro).

2. Create a session from your backend

curl -X POST "https://mountable.io/api/v1/mount-sessions" \
  -H "Authorization: Bearer $MOUNTABLE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"filesystem_id": "k5q2ztr4mvd7wn3xa6jhebcyfu", "mode": "rw", "idempotency_key": "job-4182"}'

With the CLI, mountable ticket create FS_ID --idempotency-key job-4182 --json does the same and handles retries (see Agents).

The response contains the session id and the ticket. The ticket is single-use and must be exchanged within five minutes.

Field	Meaning
`filesystem_id`	the filesystem to mount
`mode`	`ro` or `rw`, up to the key's grant
`idempotency_key`	retries with the same key return the same session; the ticket is never shown twice
`max_duration_seconds`	optional; default 12 hours, at most 7 days and never past the key's expiry

3. Mount in the sandbox

The sandbox needs FUSE (/dev/fuse) and the mountable CLI. Node and Python images can run it straight from their registry; any Linux image can install it:

npx -y mountable-cli mount <filesystem> /mnt/work      # npm
uvx mountable mount <filesystem> /mnt/work             # PyPI
curl -fsSL https://mountable.io/install.sh | sh         # installs to ~/.local/bin

Below, mountable stands for whichever you use (npx -y mountable-cli, uvx mountable, or the installed mountable).

The CLI is self-contained: mounting downloads nothing else. It talks to https://mountable.io unless MOUNTABLE_API_URL says otherwise. Pass the ticket on stdin, never on the command line or in an image:

mkdir -p /mnt/work
echo "$TICKET" | mountable mount --ticket-stdin /mnt/work &

The ticket names the filesystem and mode. The CLI generates a key pair, exchanges the ticket for a short-lived certificate, keeps renewing it in the foreground (hence &), and aborts the mount when the session is revoked or expires.

4. Revoke

curl -X DELETE "https://mountable.io/api/v1/mount-sessions/$SESSION_ID" \
  -H "Authorization: Bearer $MOUNTABLE_API_KEY"

You can also revoke live sessions on the filesystem's page in the console. Removing a grant, revoking the key, or deleting the filesystem revokes the affected sessions too. Within about 20 seconds the CLI in the sandbox aborts the mount: every further operation in it fails, and writes not yet committed are lost.

Tested sandboxes

Each provider is checked by mounting production from a fresh sandbox: install the CLI, mount, write and read back an 8 MiB file, then revoke the session and see the mount stop.

Provider	Result	Checked
E2B (Debian 12, default template, non-root user)	works; the mount stopped 4 s after revocation	2026-10-07, CLI 0.3.0

The sandbox needs FUSE: /dev/fuse and fusermount3. If a provider doesn't offer them, mounting fails with a clear error.