Conversation
aron-cf
requested review from
ghostwriternr,
scuffi and
whoiskatrin
as code owners
🦋 Changeset detectedLatest commit: 2406433 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
The `sandbox.writeFile()` endpoint now supports files of any size. We achieve this by using a byte stream which bypasses the Workers 32mb RPC file size limit[1]. This means that the rest of the tunneling through to the sandbox agent can just proxy the request body rather than managing string conversion. The sandbox agent then writes the raw bytes to disk. This simplifies the entire flow. [1]: https://developers.cloudflare.com/workers/runtime-apis/rpc/#readablestream-writeablestream-request-and-response
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
commit: |
Contributor
🐳 Docker Images Published
Usage: FROM cloudflare/sandbox:0.0.0-pr-505-2406433Version: 📦 Standalone BinaryFor arbitrary Dockerfiles: COPY --from=cloudflare/sandbox:0.0.0-pr-505-2406433 /container-server/sandbox /sandbox
ENTRYPOINT ["/sandbox"]Download via GitHub CLI: gh run download 23446359129 -n sandbox-binaryExtract from Docker: docker run --rm cloudflare/sandbox:0.0.0-pr-505-2406433 cat /container-server/sandbox > sandbox && chmod +x sandbox |
whoiskatrin
previously approved these changes
Mar 20, 2026
For websockets we now buffer any ReadableStream into memory. This is pretty much what we were doing before. It makes the HTTP transport more efficient though and we need to reconsider transports in the near future. For retries we now check the sandbox is healthy _before_ we attempt to start writing the file. We also gracefully handle retries if the stream has been consumed by returning the 503 response immediately.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
writeFilenow acceptsReadableStream<Uint8Array>The public
writeFileAPI has been expanded to acceptstring | ReadableStream<Uint8Array>as content, removing the previous 32 MiB size limit. Strings continue to work exactly as before. Passing aReadableStreamstreams bytes directly to disk with no buffering and no size cap.How the size limit is bypassed
The 32 MiB limit previously came from Cloudflare's JSRPC serialization at the Worker → Durable Object boundary.
writeFilecalls are now intercepted at thegetSandbox()proxy layer and converted to byte-orientedReadableStreams before crossing the RPC boundary — Cloudflare's RPC infrastructure streams these without buffering, bypassing the limit. On the container side, files are written incrementally chunk-by-chunk usingBun.file().writer(), keeping memory usage bounded regardless of file size.See docs for details: https://developers.cloudflare.com/workers/runtime-apis/rpc/#readablestream-writeablestream-request-and-response
The
websockettransportThis PR changes the websocket transport to use the HTTP protocol for writing a file. This avoids the need to buffer the file into memory to send over the socket as a base64 encoded string. This makes the implementation more efficient but the transport is no longer pure websockets.
stream-uploadexampleA new example demonstrating the
writeFilestreaming API with a full upload/download integrity check. Includes a browser UI and a CLI test script.To run:
cd examples/stream-upload npm install npm run devOpen
http://localhost:8787, pick a file, and click "Upload & Verify" — the UI computes SHA-256 of the original and downloaded file and confirms they match.CLI test script:
Generates a random binary file, uploads it, downloads it back, and compares SHA-256 hashes — printing
PASSorFAILwith sizes and hashes.Notable changes
encodingoption onwriteFileis deprecatedTest coverage
file-client.test.ts):writeFilewithReadableStream— successful write, error handling, network errorsfile-handler.test.ts): missingpathparam, missing body, successful stream write, service error propagation; mergedhandleWriteandhandleWriteStreamtest casesfile-service.test.ts): path validation, relative path resolution, empty stream, multi-chunk streams, write failure; removed encoding-specific tests (no longer handled at this layer)