Memory Leak with node 22 (also 20, 24) + fetch + Next 16.0.1 + `output: standalone`

[austin-raey]

Link to the code that reproduces this issue

https://github.com/austin-raey/next-memory-issue

To Reproduce

1. Run pnpm install
2. In src/app/page.tsx, replace "http://put-large-api-json-request-here.test" with some JSON endpoint. I didn't want to put someone's URL here as to not DDOS them haha. Preferably one where you are not rate limited. You can probably separately set up a seperate folder with an express (or similar) API endpoint that returns a large JSON payload as to not DOS anyone. As to not pollute the test, it may be best for you to not make this JSON endpoint in this example Next repo itself (this may not make a difference though tbf)
3. With Docker Desktop, Rancher Desktop, or etc running, do make run.
4. Open an Inspector session in Chrome / Edge / etc. (about:inspect in Chromium browsers)
   4a. Optionally, go to the http://localhost:3000 page in your browser once, reload the page a few (2 or 3) times, then click "Collect garbage" a few times to ensure a clean heap, then "Take snapshot" of the heap to collect a baseline.

Image of the "Collect Garbage" button in Chromium browsers

5. In a seperate terminal tab in the example repository, run pnpm exec autocannon -R 30 -f http://localhost:3000. Let this run for a few minutes or so. -R 30 may be adjusted for more requests, but 30 is probably fine.
6. After waiting, hit CTRL + C to stop autocannon.
7. Go to the Inspector. Before taking the heap snapshot, click the "Collect garbage" broom icon to ensure the heap is clean. Note the heap is now larger than baseline and collecting garbage will not reduce this size.
8. Inspecting the heap, it seems a large portion is now taken up by fetch. There is also Array and InternalReadableByteStream which seems suspicious, but I am not sure if they are relevant:

Image of the suspicious items in heap

Current vs. Expected behavior

I would expect the heap, once garbaged collected, to be similar in size to the baseline heap. Instead, the heap size is now permanently larger and it seems a large portion is taken up by fetch.

This larger size is sticky and I haven't seen it ever go back down even after waiting several minutes with no requests made to http://localhost:3000. Manual garbage collection makes no change either.

Provide environment information

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: 25.1.0
  npm: 11.6.2
  Yarn: N/A
  pnpm: 10.20.0
Relevant Packages:
  next: 16.0.1 // Latest available version is detected (16.0.1).
  eslint-config-next: N/A
  react: 19.2.0
  react-dom: 19.2.0
  typescript: 5.9.3
Next.js Config:
  output: standalone

Which area(s) are affected? (Select all that apply)

Not sure, Runtime

Which stage(s) are affected? (Select all that apply)

Other (Deployed)

Additional context

• I have seen other tickets make note of this and were able to fix it with a specific version of node, although unfortunately this made no difference for me. I have tried using other of the latest LTS versions of node (20, 22, 24 at the time of writing 24.11.0, 22.21.1, 20.19.5) and it seems this issue still persists on each of these versions. You can easily try different node versions by modifying the first line of the Dockerfile.
• I've also observed this issue on the latest version of Next 15 (15.5.6 at the time of writing).
• Using axios instead of fetch (which I believe doesn't use undici) seems to help with this issue. Of course, this is not ideal, because Next provides nice additions to fetch for caching.

[hugocruzlfc]

I have the same problem, but in my case:

Operating System:
Platform: darwin
Arch: arm64
Version: Darwin Kernel Version 25.1.0: Mon Oct 20 19:26:04 PDT 2025; root:xnu-12377.41.6~2/RELEASE_ARM64_T8122
Available memory (MB): 16384
Available CPU cores: 8
Binaries:
Node: 20.19.5
npm: 10.8.2
Yarn: N/A
pnpm: 10.20.0
Relevant Packages:
next: 15.5.3 // An outdated version detected (latest is 16.0.5), upgrade is highly recommended!
eslint-config-next: 15.5.3
react: 19.1.1
react-dom: 19.1.1
typescript: 5.8.3
Next.js Config:
output: standalone

[hugocruzlfc]

For my part, it has been resolved. The problem was a cyclic dependency within the next-auth authentication to refresh the token.

[pablohpsilva]

I found a memory leak even when using the most basic nextjs-boilerplate. In short, if you profile the memory on every refresh, you will see it grows 100-200kb per refresh and the memory is never released. That's prod. The video below show exactly this behavior:

Kapture.2025-12-17.at.17.23.23.mp4

[austin-raey]

Yep, to echo @pablohpsilva, I simply used create-next-app at the time to create my example repo, with a couple extras for testing (Docker configuration for ease of switching node versions / building & running, autocannon for stress testing).

I am probably going to revisit this issue soon with the latest version at time of writing (16.1.0) to see if the issue persists, whenever I find some time.

I'm seeing on my template repo I have a couple extraneous deps (mainly tailwindcss, I'll check if there's any others) and I'd like to make this as minimal a repro as possible. I don't think this will affect things, but I digress haha.

[mangaupdates]

I'm experiencing this in production as well (with output standalone). About 48kb lost per page view until OOM kill. I believe (don't quote me on this) it started when I updated to 15.5 (from 15.3), and I also experience it now on 16.1.1. I am using openapi generator with typescript-fetch server side.

[Crustan]

We just updated to Next 16 (16.1.1) from Next 15.5.9 and we get OOM's like every hour, compared to a couple times a week.

[deshazer]

For those who come after...

I was able to drastically reduce the slope of memory consumption by installing node-fetch and then just dropping that in as a replacement for all of my normal fetch calls.

Now, I know this basically opts out of Next.js fetch's caching capabilities, but that happens to be ok in my situation (doesn't everyone hate Next.js caching anyway?). 🤷‍♂️

I was also lucky because we had one centralized wrapper around fetch called apiFetch that all my other services were using. So, swapping node-fetch into its place was basically a 2-line change. All that to say: this might not solve everyone's problem, but hopefully it will help someone.

It's hard to deny the results... Here's the AWS graph of memory consumption before and after deploying this change:

Note: this was on a container instance with 16GB of memory.

[timneutkens]

Spent the last ~2-3 days investigating this and haven't been able to find a clear leak. Even measuring the memory usage it is showing the garbage collecting bringing the chart back down to the level it was at before, no linear growth like in what @deshazer is posting above.

My suspicion would be that for some it's related to the Node.js version. There were some memory leaks in Undici (Node.js's fetch implementation that have been fixed in patch releases of the Node.js 20 and later major versions.

Investigation: #88577 (comment)

[timneutkens]

Going to close this issue as there's no new comments after sharing the investigation. As far as I can tell there's nothing linearly leaking like in @deshazer screenshot.