A Root Filesystem That Grows with Your Agent

An agent clones a repository, installs a toolchain, downloads a dataset, and starts producing build artifacts. A disk size that looked generous at launch can become a constraint halfway through the task. The files also spread beyond the project directory: package managers, language runtimes, and tools write into their own locations throughout the filesystem.

Sandbox0 now supports automatic online growth of the writable root filesystem, backed by a sparse logical device of up to 64 TiB. The filesystem starts small and expands as it fills, while the agent keeps running. Changed blocks are committed to regional object storage in the background, allowing the worker to reclaim the local write log covered by each acknowledged commit.

The feature is enabled in our qualified Sandbox0 Cloud deployment. Other deployments can enable it explicitly. It applies to newly imported images with the growth configuration; existing captured images and snapshots retain their original device geometry.

Let the Agent Use Its Filesystem#

A separately mounted volume works well when an application knows where its durable data belongs. Agent workloads often discover their storage needs while they run. A compiler lands in /usr/local, a package cache grows under the home directory, and a checkout expands in /workspace.

Growing the RootFS lets those ordinary paths share the same capacity model. There is no extra mount path to choose for each tool. Separate mounts still have their own limits and lifecycle: for example, a memory-backed mount does not become durable simply because the RootFS is durable.

The important change is that an initial filesystem size no longer has to be the lifetime storage ceiling of the sandbox.

Three Different Capacities#

The design separates three quantities that are easy to confuse:

The template's ephemeralStorage field supplies the initial filesystem size: the default remains 8Gi, with supported initial sizes from 300Mi through 1Ti. On a growth-enabled deployment, this field is the starting size. A fixed-size deployment retains its existing capacity behavior. See template configuration for the full contract.

As free space runs low, the worker grows mounted XFS within the already attached sparse device. This does not require replacing the device, restarting the guest, or reopening the agent's files.

64 TiB is a logical ceiling, not unlimited storage or a reservation of 64 TiB of physical capacity. Remote storage capacity, configured budgets, and upload throughput still matter. Our qualification workloads also do not constitute a 64 TiB performance benchmark.

Background Commits Keep the Worker Footprint Bounded#

A sparse local disk alone would still fill the worker as the agent writes more data. Online growth therefore needs a second mechanism: moving committed data out of the local write log while the same process continues writing.

Sandbox0 publishes changed blocks and their mapping as immutable filesystem generations. Unchanged blocks can be reused. The regional service verifies that publication comes from the current authorized writer, and uploads hold custody of their objects so garbage collection cannot remove them mid-flight.

Remote publication and local reclamation are separate steps. Only after a commit is acknowledged can the worker install the new base and discard the write-log records it covers. Writes made after that commit's boundary must remain, including later overwrites of the same blocks. Recovery must find a complete old or new local state; an uncertain acknowledgement is retried instead of being treated as permission to delete data.

This is what lets accumulated filesystem data exceed the worker's local write-log budget. If object storage is unavailable or writes arrive faster than uploads can drain them, the configured budget applies backpressure. Writes can wait. Online growth does not promise uninterrupted write progress through an arbitrary storage outage.

Root Disks and Mounted Volumes Solve Different Problems#

Other sandbox providers offer several useful storage models. A comparison needs to distinguish the root or local disk from a filesystem mounted at a chosen path. A large persistent volume does not automatically enlarge the root filesystem used by every installed tool.

The following summarizes official documentation checked on October 15, 2026. Defaults, configurable limits, and preview features are labeled separately; these numbers are not performance comparisons.

Modal and Blaxel already offer mounted filesystems without a fixed volume capacity. Those offerings still have other boundaries: for example, Modal documents a 500,000-inode limit for Volume v1, and file-size and directory-entry limits for v2. “No fixed capacity” should not be read as “no limits of any kind.”

Sandbox0's focus here is the whole writable RootFS: ordinary filesystem paths can grow while the workload runs, with incremental persistence underneath. The right storage model depends on whether an application needs a shared mounted dataset, a disposable local disk, or a durable agent environment whose tools can write across the root filesystem.

Growth Fits the Existing Sandbox Lifecycle#

Snapshots and forks retain immutable filesystem generations while the active writer continues moving forward. A new runtime can read committed blocks on demand instead of requiring every byte of the accumulated filesystem to be copied onto its worker first.

Planned pause still has to settle outstanding writes. Background publication reduces the remaining disk work to changes not yet committed; it does not make pause or resume constant-time. Outstanding data, checkpoint size, cache state, and network throughput all affect the result.

Filesystem persistence and process continuity also remain distinct. The explicit, experimental memory-preserving pause/resume path requires memory: true on both operations and a compatible restore target. A RootFS snapshot by itself does not retain a process's RAM or open file descriptors. See snapshot and restore and our process migration introduction for those boundaries.

There is a durability boundary during unexpected worker loss as well. A guest fsync makes the local write log durable; it does not by itself acknowledge a regional commit. Permanent loss of that worker can recover the last remotely committed state, while an unpublished local suffix can be lost. Planned maintenance must finish publication before removing the source.

What We Validated#

Our production canary started with a 300 MiB initial filesystem on a 64 TiB logical device. One process wrote and checked 1,200 MiB of payload, including overwrites and zeros. Mounted XFS grew online. Full payload hashes matched after a memory-preserving pause/resume and in a separately started filesystem fork. The original process also retained its heap marker, memory mapping, and an open file that had been unlinked.

Separate isolated tests covered a 2 GiB workload through a real object storage interruption, recovery with a bounded local write log, and continued process identity across three live ownership transfers. A physical worker deletion test restored a complete 600 MiB remotely committed payload on an independent replacement and confirmed the expected loss of its unpublished local suffix. Snapshot, restore, and garbage-collection checks exercised the surrounding lifecycle.

These are specific correctness and recovery results. They do not establish full-capacity throughput, fleet-wide latency percentiles, or preservation of volatile memory after sudden hardware loss. The public implementation and acceptance record documents the test conditions and remaining boundaries.

For agents, the practical result is straightforward: the filesystem can grow with the work, without asking the agent to stop and rebuild its environment just because it outgrew its starting disk size.

Start with template configuration. If you run Sandbox0 yourself, the feature remains opt-in: follow the self-hosted configuration guide and the rollout requirements in the acceptance record before enabling it.