Turbopack build saturates 4 GB and stalls or OOMs

Link to the code that reproduces this issue

https://github.com/shunkakinoki/next-turbopack-build-memory-reproduction

To Reproduce

1. Clone the reproduction repository.
2. Run bun install --frozen-lockfile --minimum-release-age=0.
3. Run bun run reproduce -- canary.

The command generates 100 App Router routes and 12,000 deterministic client modules (79.8 MiB of TS/TSX), then runs next build in a Linux container constrained to 2 CPUs and 4 GB of memory. It samples cgroup memory once per second and bounds the build to 180 seconds.

The current canary result is captured in this native Linux x64 workflow run. The same fixture on 16.3.2 is captured in this run.

A smaller control completes:

REPRO_COMPONENTS_PER_ROUTE=80 bun run reproduce -- 16.3.2

Current vs. Expected behavior

Current behavior:

• Next.js 16.3.2 remains in Creating an optimized production build ..., reaches the 4,096 MiB cgroup ceiling, records 206,580 at-limit events, and is killed by the kernel with exit 137.
• Next.js 16.4.0-canary.4 remains in the same compilation phase for the full 180-second bound, reaches 4,096 MiB, and records 260,056 at-limit events before the harness stops it with exit 124.
• The 8,000-module control completes on the same runner and limits in 65 seconds, although it also peaks at 4,095 MiB.

Expected behavior:

next build should complete without retaining the entire 4 GB working set, or fail promptly with an actionable memory error. It should not remain in compilation while continuously pinned at the cgroup ceiling.

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
  Kernel: 6.17.0-1022-azure

Container limits:
  CPU quota: 2
  Memory: 4 GB
  Memory + swap: 4 GB total (swap cannot extend the limit)

Runner host reported by next info:
  Available CPU cores: 4
  Available memory: 15990 MB

Binaries:
  Bun: 1.4.0
  Node value reported by next info under Bun: 26.3.0

Relevant packages:
  next: 16.4.0-canary.4
  react: 19.2.8
  react-dom: 19.2.8
  typescript: 5.9.3

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

Turbopack, Performance

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

next build (local and CI)

Additional context

The issue first appeared in a real App Router deployment on a 2 vCPU / 4 GB Linux runner, where Next.js 16.3.2 was killed with exit 137 during Creating an optimized production build .... The public repository is synthetic and contains no application code.

Disabling both reactCompiler and experimental.turbopackRustReactCompiler does not avoid the saturation: the compiler-off control still reaches 4,096 MiB and times out in compilation with 128,933 at-limit events. This suggests the retained memory is in the broader Turbopack production build path rather than the React Compiler transform.

The measurements establish memory exhaustion and lack of forward progress. They do not establish a time-based memory leak. The open report #95745 covers page-data worker OOMs and worker heap controls; this reproduction stalls earlier, inside Turbopack compilation.

This report supersedes #97800, which was auto-closed because its REST-created Markdown used second-level headings instead of the issue form's third-level field headings.

Start with the linked reproduction repository and run bun install --frozen-lockfile --minimum-release-age=0 followed by bun run reproduce -- canary. Compare the 12,000-module case with the 8,000-module control and compiler-off control, then inspect the Turbopack path reached by next build. Done means the fixture completes within its memory limit or fails promptly with an actionable error instead of stalling at the cgroup ceiling.