Memory leak causing OOM still occurs in Next.js 16.0.10 (also tested with 16.0.1) when using output: standalone with fetch requests.

[haoyanwang]

Link to the code that reproduces this issue

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

To Reproduce

1. Create a Next.js app with output: 'standalone'
2. Make fetch requests to an external API
3. With just 2 requests per second, OOM occurs after a few minutes

Current vs. Expected behavior

• Current: Memory continuously grows until OOM after ~2 requests/second. GC cannot release the memory.
• Expected: Memory should stabilize, GC should work properly, no OOM.

Provide environment information

- Platform: Linux
- Node: v22.16.0
- Next.js: 16.0.10
- output: standalone
- Router: App Router

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

Performance

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

Other (Deployed)

Additional context

Related to PR #88577 (fix for issue #85914). The fix should properly cancel both branches of a tee'd ReadableStream, but the issue still persists in 16.0.10.

@icyJoseph I've tested with next@16.2.0-canary.51 (which should include the fix from #88577), but the memory leak still occurs.

Heap Timeline Analysis
The heap timeline shows that string and object types are being retained and continuously accumulated. These objects are referenced by cacheController

nextjs-memory-leak.heaptimeline.zip

[haoyanwang]

@timneutkens I'm experiencing the same issue in Next.js 16.0.10 with output: standalone.

Heap timeline analysis shows string and object types are retained by cacheController. Reproduction is very easy - only ~2 requests/second is enough to trigger OOM.

Is the fix in #88577 complete? Happy to provide more details if needed.

[timneutkens]

Please provide a reproduction of your own making. Looking at the heaptimeline it seems to be leaking something in your application code, but I can't tell if that's the case without the code.

[icyJoseph]

@haoyanwang Could you make sure and verify that you did run your diagnostic with next@canary? You've been trying to open the issue for the past 10-15 minutes, perhaps you made a mistake while testing, worth trying 🙏

[C-Jeril]

I encountered a similar problem： Turbopack Memory Regression in 16.1.x Compared to 16.0.11 (Large App Router Project)

---

Summary

We are experiencing a significant memory usage regression in Turbopack between Next.js 16.0.11 and 16.1.x during production builds.

The issue appears during the optimized production build phase, before SSG execution. The JavaScript heap remains low and stable, while RSS memory increases substantially, suggesting the issue originates from Turbopack's Rust layer or module graph handling rather than application-level code.

---

Environment

• Next.js: 16.0.11 vs 16.1.6
• Turbopack enabled (next build --turbopack)
• React: 19.2.x
• App Router
• ~6,700 routes (large-scale project)
• Windows environment
• 19 workers (default parallelism)

Command used:

next build --turbopack --experimental-debug-memory-usage

---

Observed Behavior

✅ Next.js 16.0.11

Peak memory during graph build phase:

• Peak RSS: ~8.1 GB
• JS Heap: ~52 MB
• After compilation completes, RSS drops to ~2.4 GB
• Build completes successfully

Memory usage appears proportional to worker count and project size.

---

❌ Next.js 16.1.6

Peak memory during graph build phase:

• Peak RSS: ~12.9 GB
• JS Heap: ~50–150 MB
• No corresponding increase in JS heap
• Significant memory spike compared to 16.0.11

This suggests a regression in Turbopack memory handling in 16.1.x.

---

Important Observations

1. JS heap remains low (<150MB) in all cases.
2. The spike occurs during the "Creating optimized production build" stage.
3. Memory drops after compilation, indicating no long-term leak.
4. SSG phase memory is stable (~2.5GB RSS).
5. Limiting workers reduces memory proportionally.

This strongly suggests the issue is related to Turbopack module graph construction or worker-level memory duplication introduced in 16.1.x.

[haoyanwang]

@haoyanwang Could you make sure and verify that you did run your diagnostic with next@canary? You've been trying to open the issue for the past 10-15 minutes, perhaps you made a mistake while testing, worth trying 🙏

I deployed with 'next': '16.2.0-canary.51', but the memory leak still exists. I'm trying to submit a minimal reproduction code

[icyJoseph]

@C-Jeril same goes for you, without a reproduction repository, we are still at anecdote level, in the sense that we'll be just guessing what your problem could be, for days on end.

[haoyanwang]

@timneutkens @icyJoseph
https://github.com/haoyanwang/next-memory-leak-demo

This is my demo, which was built using Docker. When accessed continuously, it causes memory usage to keep rising without being reclaimed. For more details, please refer to the readme.md file.

[timneutkens]

"next": "15.5.4"

https://github.com/haoyanwang/next-memory-leak-demo/blob/main/package.json#L14

You're not using next@canary here.