Volumes Overview

A volume is a named, project-scoped directory tree that exists independently of any sandbox. Sandboxes come and go; a volume persists, and you can attach it to many sandboxes — one after another or several at the same time. That makes volumes the natural home for anything worth keeping or sharing across sandbox lifetimes: datasets, model weights, package caches, build artifacts.

Contrast this with a sandbox's own filesystem, which lives and dies with the sandbox (unless it's persistent — and even then it belongs to exactly one sandbox). A volume belongs to the project.

Local-first performance

When a sandbox attaches a volume, it doesn't do remote I/O against shared storage on every read and write. Instead, the sandbox gets a fast, private working copy of the volume, materialized locally, and works at local-disk speed. Changes are then committed back in the background on a roughly 5-second cadence, so they survive the sandbox's teardown and become visible to other sandboxes attaching the same volume.

This design means volume-heavy workloads (training loops over a dataset, compilers hitting a cache) run at full speed — the synchronization cost is paid asynchronously, not on your hot path.

Concurrency model

Multiple sandboxes can write to the same volume concurrently. Daytona merges their committed changes automatically, per file, last-change-wins: if two sandboxes modify the same file, the most recent committed change becomes the volume's content for that file. Conflicts are recorded on the volume — you can inspect them afterwards — but they never block a writer or fail a commit.

The practical guidance: concurrent writers are fine when they touch different files (each worker writing its own output, shards of a dataset, separate cache entries). If two sandboxes routinely rewrite the same file, design that coordination yourself — the volume won't do application-level merging for you.

Durability — the honest caveats

Committed state is durable: once the background commit has run, your data survives sandbox teardown and host failure. The window to understand is the commit cadence itself — if the host running a sandbox fails, up to one commit interval (~5 seconds) of that sandbox's most recent writes can be lost.

That tradeoff is exactly right for datasets, caches, and artifacts, and exactly wrong for systems that need transactional guarantees. Don't put a database's data directory on a volume; run a managed database instead, or accept that a crash may lose the last few seconds.

Note: volumes are storage for files, not a coordination primitive. There is no cross-sandbox file locking.

Interactions with other features

Attaching volumes changes a few sandbox behaviors:

• Cold boot — a sandbox created with volumes always cold-boots, so creation is somewhat slower than a template-booted sandbox.
• Pause and fork are blocked (v1) — a sandbox with attached volumes cannot pause or fork. Warm stop/start works normally for persistent sandboxes with volumes.
• Not part of snapshots — VM snapshots capture the sandbox, not its attached volumes; re-attach volumes when restoring.
• Up to 8 volumes can be attached to one sandbox.

When to use what

Next

Ready to create and attach one? See Using Volumes for the full CRUD and mounting reference with examples.