[Feature] Memory usage when uploading a large file

[harveyjing]

Describe the bug

I know this can be circumvented by persigned url or third party storage service. But I just wanna know why.
The scenario is uploading a large file(10GB) through the Workers using Opennextjs framework. Supporse the upload api is /api/upload and in it I added some logs. Like blow:

export async function POST(request: Request) {

    console.log("starting upload", Date.now());

    const headers_0 = request.headers;
    console.log("headers_0", headers_0, Date.now());

    console.log("starting geting the body", Date.now());
    const body = await request.body;
    console.log("got the body", Date.now());

    return new Response("Uploaded", { status: 200 });
}

Then start the opennextjs server by pnpm run preview.
Then I upload a 600MB file using command blow:

curl -X POST http://localhost:8787/api/upload --data-binary @./600MB.zip --limit-rate 100M

And I watch the console out and wait for about 6 seconds the console will print out the starting upload logs.
The worked process's memory is bloating up to more than 1GB.
It seems the server buffered the request then enter the POST handler.
I was confusing why.

I wanna use streaming upload but this make it impossiable.

So I tested with other ways to see their behaviours.

1. Native Workers (Hello World template):
   I implememnt the same api in the fetch function.
   I upload the same file using the same command and see the console logs printed out instantly without waiting for 6 seconds. [GOOD]
   Memory usage is very low(20~30MB) in the worked process.
2. creat-next-app:
   This is the official Nextjs scaffold tool. I added the upload api and start the production server using pnpm run start.
   I upload the same file using the same command and see the console logs printed out instantly without waiting for 6 seconds. [GOOD]

Any information would be appreciated.

Steps to reproduce

Prerequest: Create a project using pnpm create cloudflare@latest my-next-app --framework=next

1. Create file ./api/upload/route.ts under app folder.
2. Add this route blow:

export async function POST(request: Request) {

    console.log("starting upload", Date.now());

    const headers_0 = request.headers;
    console.log("headers_0", headers_0, Date.now());

    console.log("starting geting the body", Date.now());
    const body = await request.body;
    console.log("got the body", Date.now());

    return new Response("Uploaded", { status: 200 });
}

3. pnpm preview.
4. curl -X POST http://localhost:8787/api/upload --data-binary @./600MB.zip --limit-rate 100M
   Watch the console output. It only print out logs after about 6 seconds.

Expected behavior

It should print out logs instantly.

@opennextjs/cloudflare version

1.13.1

Wrangler version

4.50.0

next info output

✗ % pnpm exec next info
exec next info
npm warn Unknown env config "verify-deps-before-run". This will stop working in the next major version of npm.
Using vars defined in .dev.vars
npm warn Unknown env config "verify-deps-before-run". This will stop working in the next major version of npm.
/bin/sh: yarn: command not found

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 25.1.0: Mon Oct 20 19:34:05 PDT 2025; root:xnu-12377.41.6~2/RELEASE_ARM64_T6041
  Available memory (MB): 49152
  Available CPU cores: 14
Binaries:
  Node: 22.14.0
  npm: 11.4.1
  Yarn: N/A
  pnpm: 10.12.1
Relevant Packages:
  next: 15.5.6 // An outdated version detected (latest is 16.0.4), upgrade is highly recommended!
  eslint-config-next: 15.4.6
  react: 19.1.0
  react-dom: 19.1.0
  typescript: 5.9.3
Next.js Config:
  output: N/A
 ⚠ An outdated version detected (latest is 16.0.4), upgrade is highly recommended!
   Please try the latest canary version (`npm install next@canary`) to confirm the issue still exists before creating a new issue.
   Read more - https://nextjs.org/docs/messages/opening-an-issue

Additional context

No response

[vicb]

Can you expand about your use case? Do you want to upload a large file to R2?

Given that you retrieve the full body const body = await request.body; I don't see how a native worker or cna would consume less than memory than at least the size of the file (600MB).

[harveyjing]

1. Yes, I wanna upload files to R2. In the Workers I got the R2 binding and stream the request.body to the R2 service.
2. For const body = await request.body; the request.body is a ReadableStream. Not a promise. So await don't do anything. It didn't retrieve the full body. Instead it got a stream.

[harveyjing]

More details @petebacondarwin .
In the same opennextjs project, setup the upload api already.

1. Scenario 1:
   a. Start the server by pnpm preview.
   b. Upload a large file using curl: curl -X POST http://localhost:8787/api/upload --data-binary @./600mb.zip --limit-rate 100M.
   c. The workderd process's memory will be bloating up to more than 1 GB.
   d. Wait for about 6 seconds then I can see the logs from console.
2. Scenario 2:
   a. Start the server by pnpm build && pnpm start.
   b. Upload a large file using curl: curl -X POST http://localhost:3000/api/upload --data-binary @./600mb.zip --limit-rate 100M.
   c. The node process's memory is stable at about 200MB~
   d. I can see the logs from console immediately but curl will block for about 6 seconds.

[harveyjing]

In order to clarify it I added more time logs. Above is the client console out after changing the route blow:

export async function POST(request: Request) {

    console.log("starting upload", new Date().toTimeString());

    const headers_0 = request.headers;
    console.log("headers_0", headers_0.entries.length, new Date().toTimeString());

    return new Response("Uploaded" + new Date().toTimeString(), { status: 200 });
}

[vicb]

I think the problem boils down to the Open Next converters.

That's probably not something we can change outside of a major release.

One thing you could do is to create a custom worker and handle a specific path without relying on OpenNext, i.e. something like:

const { pathname }  = request.url;

if (pathname = "/r2-upload") {
  return handleR2Upload(request)
}

return handler.fetch(...)

[vicb]

I marked this as v4 as it is when we will update Open Next to support stream internally.
Meanwhile you can use the workaround mentioned in my previous message.

[harveyjing]

@vicb Thanks for your prompt reply — I really learned a lot.