Creating Object Stores

Creating an object store registers a bucket connection with your project: the endpoint, bucket name, options, and — crucially — the names of the project secrets that hold its credentials. The store is ready to mount immediately after creation. Object stores are managed through daytona.object_store (Python) / daytona.objectStore (TypeScript) in the SDKs, the /object-stores REST routes, and the Object Stores page in the dashboard.

Prerequisite: credential secrets

Before creating a store, save the bucket's access key and secret key as project secrets. The object store references them by name (access_key_secret, secret_key_secret, and optionally session_token_secret for STS session tokens); the values are encrypted at rest and are never returned by any API or exposed inside a sandbox. Creation fails with 400 Bad Request if any referenced secret does not exist in the project — a misconfigured store fails at write time, not at mount time.

from rlp import Daytona
 
daytona = Daytona()
daytona.secret.set("S3_ACCESS_KEY", "AKIA...")
daytona.secret.set("S3_SECRET_KEY", "wJalr...")

import { Daytona } from '@rlp/sdk'
 
const daytona = new Daytona()
await daytona.secret.set('S3_ACCESS_KEY', 'AKIA...')
await daytona.secret.set('S3_SECRET_KEY', 'wJalr...')

Note: secrets referenced by an object store are treated as platform-managed and hidden from the default secrets list; the dashboard has an opt-in toggle to show them.

Parameters

POST /object-stores accepts the following fields. Only name, bucket, and the two credential secret names are required — everything else has a sensible default.

Note: dir_cache_secs is currently settable via REST and the dashboard only — the SDK create helpers do not expose it yet. Lower values make other sandboxes' changes appear sooner; higher values reduce bucket requests for large, static datasets.

Creating a store

store = daytona.object_store.create(
    "training-data",
    bucket="acme-training-data",
    access_key_secret="S3_ACCESS_KEY",
    secret_key_secret="S3_SECRET_KEY",
    region="us-east-1",
    provider="AWS",
    read_only=True,
)

const store = await daytona.objectStore.create('training-data', {
  bucket: 'acme-training-data',
  accessKeySecret: 'S3_ACCESS_KEY',
  secretKeySecret: 'S3_SECRET_KEY',
  region: 'us-east-1',
  provider: 'AWS',
  readOnly: true,
})

curl -X POST https://api.rl.trydaytona.com/object-stores \
  -H "Authorization: Bearer $RLP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "training-data",
    "bucket": "acme-training-data",
    "access_key_secret": "S3_ACCESS_KEY",
    "secret_key_secret": "S3_SECRET_KEY",
    "region": "us-east-1",
    "provider": "AWS",
    "read_only": true
  }'

The response includes the store's id, configuration, and state (ready immediately on success). Credential fields in responses always contain the referenced secret names, never values.

Provider recipes

AWS S3. Leave endpoint unset (AWS is the default) and set region to the bucket's region plus provider: "AWS" — as in the example above.

Cloudflare R2. Point endpoint at your account's R2 endpoint and set the provider hint:

curl -X POST https://api.rl.trydaytona.com/object-stores \
  -H "Authorization: Bearer $RLP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "r2-assets",
    "bucket": "assets",
    "endpoint": "https://<account-id>.r2.cloudflarestorage.com",
    "provider": "Cloudflare",
    "access_key_secret": "R2_ACCESS_KEY",
    "secret_key_secret": "R2_SECRET_KEY"
  }'

MinIO (and most self-hosted S3 services). Set the endpoint to your server and enable path-style addressing:

curl -X POST https://api.rl.trydaytona.com/object-stores \
  -H "Authorization: Bearer $RLP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "minio-data",
    "bucket": "data",
    "endpoint": "https://minio.example.com:9000",
    "provider": "Minio",
    "path_style": true,
    "access_key_secret": "MINIO_ACCESS_KEY",
    "secret_key_secret": "MINIO_SECRET_KEY"
  }'

Managing stores

Stores can be listed, inspected, and deleted by id or name. Deletion is refused with 409 Conflict while any live sandbox has the store mounted — unmount or stop those sandboxes first. After deletion the name is retired and immediately reusable for a new store; deleted stores remain visible with ?include_deleted=true.

stores = daytona.object_store.list()
store = daytona.object_store.get("training-data")
daytona.object_store.delete(store)

const stores = await daytona.objectStore.list()
const store = await daytona.objectStore.get('training-data')
await daytona.objectStore.delete(store)

curl https://api.rl.trydaytona.com/object-stores \
  -H "Authorization: Bearer $RLP_API_KEY"
 
curl -X DELETE https://api.rl.trydaytona.com/object-stores/training-data \
  -H "Authorization: Bearer $RLP_API_KEY"

Note: deleting a store does not delete its credential secrets. If a secret referenced by a live store is deleted, mounts of that store will fail — keep the secrets in place for as long as the store exists.

Next

• Mounting object stores — attach the store to sandboxes at create time or at runtime.