Next.js 16.2.2 standalone + Cache Components: cached internal streamed fetches cause unbounded arrayBuffers growth and OOM

[mdotk]

Link to the code that reproduces this issue

https://github.com/mdotk/next-standalone-memory-repro

To Reproduce

1. Clone the repro repo and install dependencies.

npm install

2. Build the app.

npm run build

3. Start the standalone server.

PORT=3025 npm run start:standalone

4. In another shell, run the reproducing load.

BASE_URL=http://127.0.0.1:3025 \
DURATION_MS=180000 \
CONCURRENCY=64 \
PAGE_WEIGHT_KB=2048 \
API_WEIGHT_KB=2048 \
MIX=page,api,page,page \
MAX_LOGGED_FAILURES=20 \
npm run load

5. Sample memory during the run.

curl 'http://127.0.0.1:3025/api/health?sample=1'

Current vs. Expected behavior

Current:

On next@16.2.2 with output: "standalone" and cacheComponents: true, the standalone server shows rapid unbounded memory growth under sustained high-cardinality traffic once the app is doing cached internal server-side fetch() calls against a streamed JSON route.

In one local run:

• baseline was about 95 MB rss
• after ~28s, memory reached about 1.58 GB rss / 589 MB arrayBuffers
• after ~38s, memory reached about 2.36 GB rss / 1.04 GB arrayBuffers
• after ~62s, memory reached about 2.42 GB rss / 1.95 GB arrayBuffers
• after ~180s, memory reached about 3.43 GB rss / 4.31 GB arrayBuffers

The standalone server then died with:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

While the server is destabilizing, the load generator starts receiving:

• ECONNRESET
• UND_ERR_SOCKET
• ECONNREFUSED

Expected:

Memory should stabilize or at least be reclaimed after responses complete. Large temporary spikes under load are one thing, but the standalone process should not continue retaining arrayBuffers/external memory until it exits with OOM.

Provide environment information

Operating System:
  macOS 15.x arm64
Node.js version:
  25.1.0
Next.js version:
  16.2.2
Output mode:
  standalone
Other config:
  cacheComponents: true
  compress: false

Additional context

A few things make this feel close to the existing response-retention / runtime-retention family:

• the failing repro requires cached internal server-side fetch()
• the internal fetched route returns a streamed JSON response
• the exploding categories are rss, external, and especially arrayBuffers
• the app is generating many unique request paths over time

I also ran the same repro app locally with next start as a control. I know that is not the supported way to run an app configured with output: "standalone", so I am not presenting it as the main repro. But it is useful signal:

• with next start, the app still showed large temporary growth under the same load
• after the shorter control run stopped, memory recovered back down instead of the server dying
• with the standalone server, the same app kept climbing and eventually exited with OOM

That difference made me file this specifically against the standalone runtime path.

This also overlaps with symptoms in:

• 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. #90433
• Memory leak (ArrayBuffer/WriteWrap retention) in Next.js 16.1.6 stable — fixed in canary but not released #90895
• Memory leak: ArrayBuffer/WriteWrap retention in 16.1.6 standalone (fixed in canary, not released) #90898
• controller[kState].transformAlgorithm is not a function #75994

[mdotk]

Additional production signal from the same app after filing this issue:

• We kept the app on next@16.2.2, output: "standalone", and cacheComponents: true.
• We raised our production restart guard from 5 GiB to 7 GiB to see whether this was mainly a restart-threshold artifact.
• Result: restart frequency decreased, but the underlying memory trend did not change. The process still climbs steadily until it reaches the new ceiling and is recycled.

Recent production pattern:

• Around 2026-04-04T12:20Z the process was already at ~6.9 GiB
• 2026-04-04T12:25Z: ~7.29 GiB
• 2026-04-04T12:29Z: guard-triggered restart at 7601336320
• 2026-04-04T12:30Z: second restart at 7593152512
• after restart it returned to low memory and began the same steady climb again

The runtime artifact growth also continues during these runs. In the same production windows we still see:

• .next/server/app growth continuing over time
• fetch-cache file count continuing to increase
• large server/cache footprint before each restart window

So increasing the restart limit reduces restart frequency, but does not produce stabilization. The process still grows until it reaches whatever ceiling we give it.

This strengthens the runtime/deployment suspicion rather than the “small application leak” theory:

• our minimal repro still shows standalone OOM behavior on 16.2.2
• the next start control in that repro behaved materially better after load stopped
• our production app still shows the same upward-only pattern under standalone, even when the restart threshold is raised