E2B vs Modal: How Each Agent Sandbox Mounts S3 Storage
E2B vs Modal, for storage: both sandboxes lose their files when they shut down, and both can mount an S3-compatible bucket to keep them. E2B runs s3fs inside the sandbox with a custom url flag. Modal mounts the bucket as a CloudBucketMount with a bucket_endpoint_url.
TL;DR:
- Agent sandboxes are ephemeral. Anything an agent needs to persist, uploaded documents, generated files, logs, has to be mounted in from external storage.
- The OpenAI Agents SDK defines mount types like
S3Mountgenerically, but each of its 7 official hosted sandbox providers implements the actual mounting differently. - Two of those providers, Modal and E2B, are independently confirmed to support custom S3-compatible endpoints, which is where AIOZ Storage fits.
Updated Oct 19, 2026: new E2B vs Modal opening and comparison table, mount details re-checked against E2B's and Modal's current docs, and the moved E2B docs link fixed.
Why Do Agent Sandboxes Need External Storage?
A sandbox exists to run untrusted or model-generated code safely, isolated compute with its own filesystem, and that filesystem doesn't survive the sandbox's lifecycle by default. An agent analyzing a set of documents needs those documents available when the sandbox starts. An agent generating files, reports, images, processed data, needs those files to still exist after the sandbox that created them is gone. Mounting external storage into the sandbox's filesystem is how both directions get solved, without the agent's code needing to know it's talking to a remote bucket instead of a local disk.
The OpenAI Agents SDK's Manifest System
The OpenAI Agents SDK defines a Manifest system for exactly this: S3Mount, GCSMount, R2Mount, AzureBlobMount, and BoxMount are its documented mount types for making external storage available inside a sandbox. As of the SDK's native sandbox support, launched April 2026, there are 7 officially integrated hosted sandbox providers: Modal, Blaxel, Cloudflare, Daytona, E2B, Runloop, and Vercel. The Manifest concept is generic across all of them, a way to declare "this bucket should be available at this path," but the SDK's own documentation is explicit that the actual mounting mechanics are deferred to each provider's own implementation, not specified once at the manifest level.
How Do E2B and Modal Mount S3-Compatible Buckets?
That per-provider deferral is not a documentation gap, it's a genuine architectural choice, and it means the honest answer to "does S3Mount support a custom endpoint" is: it depends which provider's sandbox you're running on. Two real, checkable examples:
Modal, one of the SDK's official providers, publishes its own ModalCloudBucketMountStrategy, which translates S3Mount, R2Mount, and GCSMount manifest entries into Modal's native CloudBucketMount volumes. Its configuration includes a bucket_endpoint_url field, documented as the S3-compatible endpoint URL, required specifically for non-AWS buckets. That field exists in Modal's own extension code, not the SDK's core manifest spec, which is exactly the "provider-specific" framing the SDK's own docs point to.
E2B, another official provider, mounts buckets using s3fs, a FUSE-based tool, run directly inside the sandbox. Its documented pattern for a non-AWS bucket, demonstrated against Cloudflare R2, passes a custom endpoint through s3fs's own -o url= flag alongside a credentials file:
await sandbox.files.write('/root/.passwd-s3fs', '<ACCESS_KEY_ID>:<SECRET_ACCESS_KEY>')
await sandbox.commands.run('sudo s3fs -o url=https://<endpoint> <bucket-name> /home/user/bucket')Swap in AIOZ Storage's own access key, secret, and https://s3.aiozstorage.network endpoint, and the same command mounts an AIOZ Storage bucket into an E2B sandbox as a local directory, using nothing AIOZ-specific, just the S3-compatible surface every AIOZ Storage integration in this series already relies on.
| E2B | Modal | |
|---|---|---|
| Mount method | s3fs (FUSE), run inside the sandbox at runtime | CloudBucketMount volume |
| Custom S3 endpoint | -o url= flag on the s3fs command | bucket_endpoint_url argument |
| Credentials in the docs example | /root/.passwd-s3fs file with key ID and secret | A Modal Secret passed as secret= |
| Non-AWS example in the docs | Cloudflare R2 | Cloudflare R2 |
| OpenAI Agents SDK mount types | Handled by E2B's own integration | S3Mount, R2Mount, GCSMount via ModalCloudBucketMountStrategy |
| Read-only setting | Not shown in E2B's bucket example | read_only, on by default in the Agents SDK config |
Read-Only vs Read-Write Mounts
The same distinction that matters for a human team sharing access to a bucket matters for an agent mounting one. Modal's ModalCloudBucketMountConfig includes a documented read_only field alongside bucket_endpoint_url, and it's worth setting deliberately rather than leaving at whatever the default happens to be. An agent that only needs to read source documents or a dataset should get a read-only mount, full stop, regardless of what credential scope it's using underneath. An agent that needs to write generated files back out needs read-write, but only on the bucket it's supposed to write to, not the one it's reading from.
That mapping isn't unique to sandbox mounts, it's the same read/write split AIOZ Storage's access grants already enforce at the credential level: an access grant scoped to Read on a dataset bucket and a separate one scoped to Write on an output bucket means a misbehaving or compromised agent can't overwrite the data it was only supposed to read, even before the sandbox provider's own mount mode adds a second layer of the same restriction.
What This Means for a Specific Provider
If you're building on Modal or E2B specifically, AIOZ Storage is a legitimate mount target today, verified against each provider's own public documentation, not assumed from the generic manifest description. If you're building on one of the SDK's other 5 official providers, Blaxel, Cloudflare, Daytona, Runloop, or Vercel, this article does not claim the same thing works there. Each implements its own mount mechanics, and the only honest way to know is to check that specific provider's own docs the way this article checked Modal's and E2B's, rather than assuming every provider behaves the same way because they all speak the same manifest vocabulary.
Frequently Asked Questions
Does OpenAI's Agents SDK support AIOZ Storage directly?
The SDK itself defines generic mount types like S3Mount without specifying endpoint behavior; that's deferred to each sandbox provider. Two providers, Modal and E2B, are independently confirmed to support custom S3-compatible endpoints in their own mounting implementations, which is where AIOZ Storage fits.
Why doesn't OpenAI's own documentation just say whether custom endpoints work?
Because the actual mounting mechanics differ by sandbox provider. The SDK's manifest system is a shared vocabulary across 7 official providers, but each one implements the underlying mount differently, so a universal answer at the SDK level wouldn't be accurate for all of them.
How does E2B mount a non-AWS S3-compatible bucket?
Through s3fs, a FUSE-based mounting tool run inside the sandbox, with the target endpoint passed via its -o url= flag alongside a credentials file, demonstrated in E2B's own docs against Cloudflare R2.
What is Modal's bucket_endpoint_url field for?
It's part of Modal's own ModalCloudBucketMountStrategy, which translates the SDK's generic mount types into Modal's native storage volumes. The field is documented as required specifically for non-AWS buckets like R2 or GCS, the same slot AIOZ Storage's endpoint fills.
Will this same setup work on every OpenAI Agents SDK sandbox provider?
Not confirmed. This article verified Modal and E2B specifically. The other 5 official providers each implement their own mounting mechanics, and whether they support a custom S3-compatible endpoint has to be checked against that provider's own documentation individually.
What kinds of files typically get mounted into an agent sandbox this way?
Anything the agent needs to read that exists before the sandbox starts, like source documents or datasets, and anything it needs to persist after the sandbox ends, like generated reports, processed files, or logs.
Related Reading
- AIOZ Storage for AI and Data Pipelines: What's Actually Documented Today - the hub this article is part of, including the original summary of this claim.
- Offloading LangGraph Agent Checkpoints to AIOZ Storage - the other AI-agent infrastructure pattern in this cluster, agent state persistence instead of sandbox file mounts.
- Using AIOZ Storage as a Dataset and Model-Output Backend - the honest can/can't framing this article's provider-by-provider verification continues.
- AIOZ Storage Access Control: Macaroons and Access Grants - generating the access key and secret these mount configs authenticate with.
- What Is an MCP Server? How AI Agents Access Storage - a different real pattern for agent-storage access, standardized tool calls rather than a sandbox mount.
- What Is Retrieval-Augmented Generation (RAG)? Explained - the pattern behind why an agent's sandbox might need a knowledge base mounted alongside its working files.
References
Related Content
How to Create a Bucket and Upload a File on AIOZ Storage
Create a bucket and upload a file on AIOZ Storage in five steps: sign up, set a passphrase, add credits, and upload. Plus what the passphrase cannot recover.
AIOZ Storage Rate Limit: Working Within 100 Requests/s
The AIOZ Storage rate limit is 100 requests per second. See what the docs do and don't say, and how to stay under it with boto3 retries and a limiter.
What AIOZ Storage Erasure Coding Covers and What It Doesn't
AIOZ Storage erasure coding splits each object into pieces on DePIN nodes, so it survives node loss. See what it covers, what it doesn't, and what to back up.
How to Rename a File in an S3 Bucket on AIOZ Storage
Rename a file in an S3 bucket on AIOZ Storage from the dashboard, then move, delete and download files, and see which actions the docs say are not supported.
AIOZ Storage llms.txt: Docs Built for Super Intelligence
AIOZ Storage publishes llms.txt, a 46-link docs index, and llms-full.txt, all docs in one 164 KB file. See what each file contains and when to use which.
Vector Database vs Agent Memory on AIOZ Storage: A Guide
Vector database vs agent memory on AIOZ Storage: use the vector database for control over embeddings and metadata, Memory for simple Record and Recall calls.