Turbopack Build Saturates 4 GB And Stalls Or OOMs On Large Module Graphs

Turbopack's production build retains the entire module graph and intermediate compilation artifacts in memory simultaneously, and fails to evict or stream under memory pressure. With 12,000 deterministic client modules, peak usage exceeds the 4 GiB cgroup ceiling, leading to constant at-limit reclaim attempts and no observable progress.

1. Clone https://github.com/shunkakinoki/next-turbopack-build-memory-reproduction 2. Run `bun install --frozen-lockfile --minimum-release-age=0` 3. Run `bun run reproduce -- canary` (or `-- 16.3.2`) This generates 100 App Router routes and 12,000 client modules (79.8 MiB), then runs `next build` in a 2 CPU / 4 GB memory cgroup. The build stalls in 'Creating an optimized production build ...' and gets killed or times out.

This config may cause Turbopack to fail earlier with an out-of-memory error, which is preferable to a kernel kill but still aborts the build. The underlying memory retention remains. If `turbopackMemoryLimit` is not honored in your Next.js version, the build will still saturate the cgroup. Reducing `cpus` significantly slows the build. Roll back by removing the experimental keys. Test on your exact version and workload before adopting in CI.