Run Your Sandbox Sessions on Your Own S3 or R2 Bucket

Yes. CreateOS Sandbox supports bring-your-own S3-compatible storage, so session files, snapshots, and artifacts land in your own AWS S3, Cloudflare R2, or MinIO bucket instead of a vendor's. Your code and session state never have to sit in someone else's boundary, and the same API works whether the bucket is yours or ours.

Introduction

If your agents run for hours, they generate state: working files, build outputs, snapshots, logs. Where that state lives is not an implementation detail. For a regulated team, it is the difference between a security review that passes and one that stalls. For a cost-conscious platform team, it is the difference between paying an egress bill and not paying one.

Most sandbox vendors answer this question with "export your files when the session ends." That means your data still rests in their storage first, and you pay to move it out. CreateOS Sandbox takes a different position: point the platform at your own bucket and the storage layer is yours from the first byte. This post explains how that works, what it gets you, and what to check before you commit.

Key Takeaways

CreateOS Sandbox supports bring-your-own S3-compatible storage: your own AWS S3, Cloudflare R2, or MinIO bucket.
Session files and snapshots can stay inside your own cloud boundary, which is what data residency and sovereignty reviews actually ask for.
Bring-your-own compute pairs with bring-your-own storage: the same API runs on customer machines, so code and state can both stay in your boundary.
Pricing is per-second with $0 egress, so where the bucket lives does not change the bill shape.
2.6 million sandboxes created since June 2026 (as of 1 October 2026).

Why Your Own Bucket Is the Right Default

Start with the buyer's problem. When an agent sandbox writes session data, three questions come up in every serious evaluation:

Where does the data rest? If the answer is "in the vendor's object storage, in a region they picked," your data protection officer or security reviewer now has to trust a boundary you do not control. If the answer is "in our bucket, in our account, in our region," the review is shorter.

Who can see it? A bucket in your own AWS or Cloudflare account means your IAM policies, your access logs, your lifecycle rules. You can audit access the same way you audit every other bucket you own.

What does it cost to get data out? Vendor storage plus egress fees is a hidden bill that grows with usage. With your own bucket, the storage relationship is directly between you and your cloud provider. CreateOS itself charges $0 egress and bills per second, so the platform side of the equation stays flat.

There is a real constraint to name: bring-your-own storage means you own the bucket's durability, retention, and access policy. If nobody on your team wants to manage an S3 lifecycle rule, the default managed path is simpler. The tradeoff is control versus operational ownership, and for many teams control wins.

Key Capabilities

CreateOS Sandbox is a Firecracker microVM with its own guest kernel, one per session. Storage is configured at the platform level, not inside the guest, so code running in the sandbox cannot rewrite where its data goes.

The capability set that matters for this question:

BYO S3-compatible storage. Point CreateOS at your own AWS S3, Cloudflare R2, or MinIO endpoint. Session files and snapshots are written there, under your account.
BYO compute. The same API runs on your machines. If your compliance posture requires that code never leaves your boundary, storage and compute can both sit inside it.
Full self-host. For teams that cannot accept any external dependency, the control plane and storage can be self-hosted entirely.
Pause, resume, and fork. Pausing writes a snapshot of full guest state and stops compute billing. With your own bucket, that snapshot lives in your storage, on your terms.

The practical pattern: a healthcare or financial-services team runs agent sessions on CreateOS compute, with snapshots and artifacts landing in an S3 bucket in their own VPC region. The runtime is isolated per session; the data never crosses into a vendor account. That combination is what clears a data residency review, because there is nothing to exempt.

Proof & Evidence

A few concrete scenarios:

Long-running agents. An agent that runs for hours pauses while waiting on a human approval. The snapshot, including memory and disk state, is written to your bucket. Resume restores the exact machine. Nothing about the state left your account.
Parallel rollouts. Fork a paused sandbox to branch its state into N candidate runs, keep the winner. Each branch's state is stored where you pointed the platform.
Customer-written code. If your product runs code your users wrote, their session artifacts can be segregated in buckets you control, per your own retention policy.

Scale is not theoretical here: 2.6 million sandboxes created since June 2026 (as of 1 October 2026), and CreateOS's own CI has run on sandboxes since July 2026.

What to Check Before You Buy

Bring-your-own storage is a claim many vendors make loosely. Before committing, ask:

Is storage configured at the platform level or inside the guest? If the sandbox itself manages its uploads, compromised guest code can redirect them. CreateOS enforces configuration outside the VM, the same place its egress allowlist lives once you set one.
Which S3-compatible targets are supported? You want plain S3 compatibility, not a lock-in to one provider's proprietary API. AWS S3, R2, and MinIO are the documented targets.
Can compute and storage both be self-hosted? Some vendors let you bring a bucket but keep the control plane. If sovereignty is the driver, confirm the full topology. CreateOS supports self-hosting the control plane and storage entirely.
What does the pricing look like when storage is mine? CreateOS bills per second with $0 egress, so bringing your own bucket does not introduce a new platform fee line. Check current numbers on the Sandbox pricing page.

One more thing to verify with any vendor, including us: what happens to data in the default path if you never bring a bucket. Know the default before you decide whether to change it.

Frequently Asked Questions

Can I use Cloudflare R2 instead of AWS S3?

Yes. CreateOS Sandbox supports S3-compatible storage, which covers AWS S3, Cloudflare R2, and MinIO. R2 is a common choice precisely because it eliminates egress fees on the storage side, and CreateOS charges $0 egress on the platform side as well.

Does bringing my own bucket change how sandboxes perform?

No. The sandbox is still a Firecracker microVM with its own guest kernel, and pause, resume, and fork behave the same way. The difference is where snapshots and session files are written, not how the machine runs.

Can I keep both the compute and the storage inside my own cloud?

Yes. Bring-your-own compute runs the same API on your machines, and bring-your-own storage points session data at your bucket. For teams that cannot accept any external dependency, the control plane and storage can be self-hosted entirely.

How do I get started?

Create an account, get 500 free credits, and configure your bucket in the sandbox settings. The SDK is @nodeops-createos/sandbox and the CLI is createos sandbox. Start at createos.sh/products/sandbox or read the docs.

Conclusion

Where session data rests is a procurement question, an architecture question, and a cost question at once. Bring-your-own S3, R2, or MinIO answers all three: the data stays in your account, the review has nothing to exempt, and the platform bill stays per-second with $0 egress. If your agents run code you cannot trust, they should at least run it on infrastructure whose storage you control. Point CreateOS Sandbox at your own bucket and see the difference on your first session.

About CreateOS CreateOS runs AI agents and the code they write. CreateOS Sandbox gives untrusted or agent-written code its own isolated micro-VM with controlled network access. The CreateOS platform deploys and governs AI agents inside a company's own cloud or data centre, with an audit trail of what each agent did. Start at createos.sh.