# Cloudflare Computer Container-Side Filesystem Limits: Workspace Size and Memory Constraints

> Explore Cloudflare Computer's container-side filesystem limits. Learn about the ~10 GB workspace size and memory constraints, perfect for agent-scale workloads but not large monorepos.

- Repository: [Cloudflare/computer](https://github.com/cloudflare/computer)
- Tags: internals
- Published: 2026-08-13

---

**Cloudflare Computer’s container-side filesystem resides entirely in container memory while persisting to Durable Object SQLite storage, imposing a practical ~10 GB workspace limit that makes it unsuitable for large monorepos but optimized for agent-scale workloads.**

Cloudflare Computer provides ephemeral compute environments backed by a virtual filesystem architecture that fundamentally differs from traditional persistent-disk containers. While the underlying storage utilizes **Durable Object (DO) SQLite** capable of holding up to approximately 10 GB per workspace, the **container-side filesystem** implementation requires loading the entire workspace into RAM. This memory-resident design creates specific constraints on storage capacity, directory complexity, and I/O performance that developers must account for when architecting agent-based applications.

## How the Container-Side Filesystem Works

According to the source documentation in [`packages/computer/README.md`](https://github.com/cloudflare/computer/blob/main/packages/computer/README.md), the workspace filesystem is **virtual** and backed by the Durable Object’s SQLite storage, yet the **container-side view** lives entirely in memory. This architectural split means that while data persists durably to the DO storage layer, any file operations inside the container traverse a **FUSE layer** that maintains the full filesystem tree in RAM. Consequently, the practical storage limit is bound not by disk capacity but by the container’s available memory budget, with the documentation explicitly capping workspaces at **~10 GB** per instance.

## Key Workspace Size Limitations

### Memory-Bound Storage Capacity

The primary constraint stems from the filesystem’s memory-resident nature. As stated in [`docs/README.md`](https://github.com/cloudflare/computer/blob/main/docs/README.md), "The container-side filesystem is held in memory, so very large trees aren't a fit." This means the **~10 GB** theoretical maximum defined in [`packages/computer/README.md`](https://github.com/cloudflare/computer/blob/main/packages/computer/README.md) represents the absolute upper bound of data that can simultaneously fit into the container’s RAM. Exceeding available memory results in container failure rather than disk overflow, making memory management critical for workspace stability.

### Directory Tree Scale Constraints

The platform explicitly targets **"agent-scale" workspaces** rather than full monorepos. Documentation in both [`packages/computer/README.md`](https://github.com/cloudflare/computer/blob/main/packages/computer/README.md) and [`docs/README.md`](https://github.com/cloudflare/computer/blob/main/docs/README.md) warns against storing massive directory trees such as complete `node_modules` installations or entire git monorepos. These structures consume excessive memory when loaded into the FUSE layer, potentially causing the container to exhaust its memory allocation rapidly. The filesystem API surface documented in [`docs/04_filesystem_interface.md`](https://github.com/cloudflare/computer/blob/main/docs/04_filesystem_interface.md) (`workspace.fs`) is optimized for modest file collections typical of task-specific agents, not repository-wide operations.

### FUSE Layer Performance Impact

All container-side I/O operations traverse the FUSE abstraction layer, introducing noticeable latency compared to native disk access. Heavy filesystem operations—such as extracting large tarballs, installing extensive package dependencies, or writing high volumes of small files—execute significantly slower than equivalent operations on traditional block storage. This performance characteristic reinforces the recommendation to limit workspace contents to essential agent task data rather than bulky development environments.

## Practical Code Examples

When working within the ~10 GB constraint, write modest amounts of data and avoid large dependency trees:

```ts
// Safe usage: writing small files well under the memory limit
using ws = await getWorkspace(env.Agent.get(id));

// Write a small file
await ws.fs.writeFile("/notes/todo.md", "- [ ] ship it\n");

// Read it back
const todo = await ws.fs.readFile("/notes/todo.md", "utf8");

// WARNING: Copying entire node_modules or large monorepos will 
// exhaust container memory and cause crashes

```

Monitor underlying storage utilization through the Durable Object storage API:

```ts
// Inspect SQLite-backed storage usage (approximate ~10 GB limit)
const stats = await ws.storage.list(); // Returns DO storage entries
console.log(`Workspace entries: ${stats.length}`);
console.warn(`Stay under ~10 GB total to ensure container memory stability`);

```

## Summary

- **Memory-resident limitation**: The container-side filesystem loads entirely into RAM, making workspace size directly dependent on container memory allocation rather than disk space.
- **~10 GB practical cap**: While Durable Object SQLite backing supports approximately 10 GB, the container memory constraint enforces this as the effective maximum workspace size.
- **Agent-scale design**: The filesystem targets small, task-specific workspaces rather than full monorepos or massive dependency trees like complete `node_modules` directories.
- **FUSE performance overhead**: All I/O operations incur latency through the FUSE layer, making heavy filesystem operations noticeably slower than native alternatives.

## Frequently Asked Questions

### What is the maximum workspace size in Cloudflare Computer?

The platform supports workspaces up to approximately **10 GB** per instance. However, because the container-side filesystem resides entirely in memory, the practical limit depends on your container’s available RAM. As documented in [`packages/computer/README.md`](https://github.com/cloudflare/computer/blob/main/packages/computer/README.md), exceeding memory capacity causes container failure, so treat 10 GB as the absolute ceiling rather than the target operating size.

### Why are large monorepos unsuitable for Cloudflare Computer workspaces?

Large monorepos and massive `node_modules` directories consume excessive memory when loaded into the FUSE-based filesystem. According to [`docs/README.md`](https://github.com/cloudflare/computer/blob/main/docs/README.md), the system is designed for **"agent-scale workspaces"**—modest file collections specific to individual tasks—rather than repository-wide codebases. Loading full monorepos rapidly exhausts the container’s memory budget and degrades performance.

### How does filesystem performance compare to native disk storage?

All filesystem operations traverse a **FUSE abstraction layer**, making I/O significantly slower than native disk access. Heavy operations like extracting large archives or installing extensive package dependencies experience noticeable latency. This architectural choice prioritizes durability and portability over raw I/O speed, reinforcing the recommendation to limit workspace contents to essential files only.

### Can I programmatically check current workspace storage usage?

Yes. You can inspect the underlying Durable Object storage utilization using `ws.storage.list()`, which returns the entries stored in the SQLite backing. While this method shows the durable storage footprint, remember that the container-side memory usage—what actually constrains your application—may differ slightly due to filesystem metadata overhead maintained in RAM.