Object Stores Overview
Mount S3-compatible buckets directly into sandboxes.
An object store is a project-level connection to an S3-compatible bucket — AWS S3, Cloudflare R2, MinIO, Ceph, or any other S3-compatible service. Once defined, the bucket can be mounted into any sandbox in the project as an ordinary filesystem path: your code reads and writes files under /mnt/data (or wherever you mount it), and Daytona translates those operations into S3 calls against your bucket.
This makes object stores the natural way to give sandboxes access to data that already lives outside the platform: large datasets, model weights, corpora shared with other systems, or output buckets consumed by downstream pipelines. The bucket stays where it is — nothing is copied into Daytona ahead of time.
The security model
Object stores are designed so that bucket credentials never enter the sandbox. The S3 access key and secret key are stored as project secrets, and the object store references them by name — never by value. When a sandbox boots with a mount attached, the platform establishes the mount outside your code's reach; untrusted code running inside the sandbox sees only the mounted files, not the keys.
This means a sandbox running arbitrary or agent-generated code can work with data from your bucket without ever being able to exfiltrate the credentials that guard it.
Object stores vs volumes
Daytona offers two ways to attach durable data to a sandbox, and they serve different jobs:
| Object stores | Volumes | |
|---|---|---|
| Backing storage | Your own S3-compatible bucket | Platform-managed storage |
| Best for | Existing buckets, huge datasets, sharing with external systems | Scratch and working state between sandboxes |
| Write performance | Network round trips to the bucket | Fast local writes |
| Access pattern | Read-mostly, large sequential reads | Full filesystem semantics |
| Data ownership | Stays in your cloud account | Lives inside Daytona |
As a rule of thumb: if the data already lives in a bucket, or must remain accessible to systems outside Daytona, use an object store. If sandboxes need a fast shared working directory, use a volume.
Capabilities and limits
- Read-write or read-only. Each store has a default
read_onlyflag, and every individual mount can override it — for example, a dataset store that is read-only by default but writable for one ingestion sandbox. - Prefix scoping. A store can expose only a key prefix of the bucket (for example
datasets/imagenet/) instead of the whole bucket. - Up to 8 mounts per sandbox, each at its own absolute path.
- Mount at create or at runtime. Mounts can be declared when the sandbox is created, or attached to and detached from a running sandbox on the fly.
- Directory-listing cache. An optional cache TTL (
dir_cache_secs) trades listing freshness for fewer bucket requests — useful for very large, rarely-changing datasets.
Because the mount is a live connection to remote object storage rather than a local disk, expect object-storage characteristics: file operations involve network round trips, and it performs best with whole-file reads and writes rather than many small random updates.
Where to go next
- Creating object stores — credential secrets, all parameters, and provider recipes for AWS S3, Cloudflare R2, and MinIO.
- Mounting object stores — attaching buckets at sandbox creation or to a running sandbox.
- Secrets — how the credential secrets that back object stores work.