Mounting Object Stores

Once an object store is created, it can be mounted into sandboxes in two ways: declared up front when the sandbox is created, or attached to (and detached from) a sandbox that is already running. In both cases the bucket appears at an absolute path inside the sandbox as a mounted filesystem, and the credentials backing it never enter the sandbox.

Mounting at sandbox creation

Pass object_store_mounts when creating a sandbox. Each entry names the store (by id or name), the absolute mount_path inside the sandbox, and optionally a read_only override for that specific mount. The store's own read_only flag is the default when the override is omitted.

from rlp import CreateSandboxFromImageParams, Daytona, ObjectStoreMount
 
daytona = Daytona()
 
sandbox = daytona.create(CreateSandboxFromImageParams(
    image="python:3.12-slim",
    object_store_mounts=[
        ObjectStoreMount(object_store="training-data", mount_path="/mnt/data", read_only=True),
    ],
))
sandbox.process.exec("ls /mnt/data")

const sandbox = await daytona.create({
  image: 'python:3.12-slim',
  objectStoreMounts: [
    { objectStore: 'training-data', mountPath: '/mnt/data', readOnly: true },
  ],
})
await sandbox.process.exec('ls /mnt/data')

curl -X POST https://api.rl.trydaytona.com/vms \
  -H "Authorization: Bearer $RLP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "image": "python:3.12-slim",
    "object_store_mounts": [
      { "object_store": "training-data", "mount_path": "/mnt/data", "read_only": true }
    ]
  }'

Mount rules the API enforces (the same path rules as volumes):

• At most 8 object-store mounts per sandbox.
• mount_path must be absolute, contain no .., and be unique among the sandbox's mounts.
• Reserved paths are rejected: /, /proc, /sys, /dev, /overlay, /mnt/scratch.
• The store must be in state ready; a deleted store returns 409 Conflict.

Mounting and unmounting on a running sandbox

Unlike volumes, object stores can also be attached to a sandbox while it is running — useful for long-lived sandboxes that need access to a new dataset without a restart. The sandbox must be in state running; any other state returns 409 Conflict. Unmounting is done by the store's name.

# Attach to a running sandbox
daytona.object_store.mount(sandbox.id, "training-data", "/mnt/data", read_only=True)
 
# What is mounted right now?
mounts = daytona.object_store.list_mounts(sandbox.id)
 
# Detach by store name
daytona.object_store.unmount(sandbox.id, "training-data")

await daytona.objectStore.mount(sandbox.id, 'training-data', '/mnt/data', true)
 
const mounts = await daytona.objectStore.listMounts(sandbox.id)
 
await daytona.objectStore.unmount(sandbox.id, 'training-data')

# Attach
curl -X POST https://api.rl.trydaytona.com/vms/$SANDBOX_ID/object-store-mounts \
  -H "Authorization: Bearer $RLP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "object_store": "training-data", "mount_path": "/mnt/data", "read_only": true }'
 
# List
curl https://api.rl.trydaytona.com/vms/$SANDBOX_ID/object-store-mounts \
  -H "Authorization: Bearer $RLP_API_KEY"
 
# Detach by store name
curl -X DELETE https://api.rl.trydaytona.com/vms/$SANDBOX_ID/object-store-mounts/training-data \
  -H "Authorization: Bearer $RLP_API_KEY"

A runtime mount follows the same validation as create-time mounts; attaching to a mount_path that is already in use returns 409 Conflict. If the mount cannot be established inside the sandbox, the attach request fails and the mount is not recorded.

Behavior notes

It is object storage, not a local disk. The mount gives you filesystem access to the bucket, but every operation ultimately maps to S3 requests: reads and writes involve network round trips, and whole-file sequential access performs far better than many small random updates. Directory listings can be cached for a configurable TTL via the store's dir_cache_secs — with a non-zero TTL, changes made by other writers to the bucket may take up to that long to appear in listings.

Read-only enforcement. A mount attached read-only (either from the store default or the per-mount override) rejects writes inside the sandbox; the credentials' own bucket permissions still apply on top of that.

Deletion guard. An object store cannot be deleted while any live sandbox has it mounted — the delete returns 409 Conflict until the mount is removed or the sandbox is stopped or deleted.

Snapshots. A snapshot captures the sandbox's own disk. Bucket contents are not part of the snapshot — the mount is a live connection to your bucket, and the data stays there.

Note: credentials are delivered to the mount out-of-band and are never visible inside the sandbox — code running in the sandbox sees only the mounted files. See the overview for the security model.