Next.js 16.2 Turbopack Build Out of Memory on Vercel

The Problem

I ran into this on a client marketing site last week. They upgraded from Next.js 15.4 to 16.2, pushed the branch, and Vercel started failing every preview deployment with the same line in the build log:

<--- Last few GCs --->
[2024:0x6d8e240] FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 ELIFECYCLE  Command failed.
Error: Command "next build" exited with 134

The repo is not huge. Around 280 routes, an MDX blog, a Tailwind v4 setup, a single Sanity CMS integration. It built in 90 seconds on 15.4 with about 4.2 GB of peak RSS in CI. On 16.2 the same code climbed past the Vercel default 8 GB ceiling and got killed by the kernel.

Local builds on a 32 GB MacBook worked fine. CI on Vercel's default Hobby builder failed every time. CI on Vercel's Pro builder (8 GB) failed about one run in three, depending on what got cached. The diff between commits did not include a single user-facing change.

Why It Happens

Next.js 16 made Turbopack the default bundler for production builds, and 16.2 removed the --webpack flag that 16.0 and 16.1 still accepted as a fallback. The bundler change is the whole story.

Turbopack and webpack take fundamentally different approaches to the module graph. Webpack streams modules through the compilation in batches, releasing memory as each batch finishes. Turbopack keeps the whole graph resident so it can do parallel transforms and incremental rebuilds. On a warm dev server that is faster. On a cold production build with 280 routes and a few thousand MDX/Tailwind/Sanity-derived modules, the resident graph plus the per-route SSR render eats 6–9 GB before the build is half done.

Three cost centres show up over and over when I trace these:

1. Barrel files. Re-exporting 80 components from components/index.ts was free in webpack because tree-shaking ran late. Turbopack still tree-shakes, but the analysis pass keeps every imported module in memory until the final emit. A single barrel that touches 80 client components costs ~150 MB during build.
2. MDX with remark/rehype plugins. Every MDX page compiles through @next/mdx plus your plugin chain. Turbopack runs these in worker threads and shares the AST across the main process, doubling the live AST count compared to webpack.
3. Tailwind v4 in JIT mode. Tailwind v4 generates a single utility CSS bundle that Turbopack treats as one module per route variant. With dark mode and a few @variant directives you can hit 12-15 MB of generated CSS held in memory at once.

The Next.js 16 release notes cover the Turbopack default change. The Turbopack memory guide lists the relevant flags but does not warn about the Vercel default builder size.

The Fix

You need to raise the Node heap limit, cut the barrel imports that hold the most memory, and pick a build path that actually fits your project. Three of these together is what gets a green build; one of them alone usually just shifts where the crash happens.

Step 1: Raise the Node heap. Add to your package.json:

{
  "scripts": {
    "build": "NODE_OPTIONS='--max-old-space-size=7168' next build"
  }
}

7168 MB leaves headroom for the kernel and the rest of Vercel's build agent inside the 8 GB ceiling. Setting it to 8192 looks tempting and is the first thing every Stack Overflow answer suggests. Do not do that on Vercel — the agent itself needs ~700 MB and you will trip the OOM killer again when GC runs hot.

Step 2: Kill barrel re-exports on hot paths. Find them with:

grep -rE "export \* from" components/ app/ lib/ 2>/dev/null

Replace export * from './button' style files with direct imports at the call site. The diff is mechanical and pays for itself in build time as well as build memory. If you maintain a barrel for DX, gate it behind a Turbopack-aware path:

// components/index.ts
export { Button } from './button'
export { Card } from './card'
// stop using `export * from`

Turbopack handles named re-exports cleanly; it is the wildcard form that pins memory.

Step 3: Upgrade the build machine, not the heap. If you are on Vercel's Pro plan, add this to vercel.json:

{
  "build": {
    "memory": 16384
  }
}

The Enhanced build machine ships 16 GB and finishes large Turbopack builds with room to spare. Vercel bills per build minute, not per machine size, so on a project where builds are minutes-long the upgrade is usually cheaper than the engineering time spent slimming the graph.

Step 4: Trace before you blame the bundler. If the build still OOMs after the above, run a tracing build locally:

NEXT_TURBOPACK_TRACING=1 NODE_OPTIONS='--max-old-space-size=7168' next build

That writes a trace to .next/trace. Open it with npx @vercel/turbo trace .next/trace and look for the modules with the highest memory_peak. Nine times out of ten it is one route group importing a 6 MB JSON fixture, or a CMS client pulling its whole schema at build time. Lazy-loading those is a one-line fix and shaves gigabytes off the peak.

Step 5: If you absolutely cannot move yet, pin to 15.4. Until you have time to slim the graph, downgrade with a frozen lockfile rather than running the upgrade with a crashed build. You give up the new caching primitives in 16, but you keep shipping.

The Lesson

Turbopack as the default production bundler changes the memory profile of every Next.js build, and Vercel's default 8 GB builder is no longer a comfortable fit for any non-trivial app. Raise the heap to 7168 MB, drop wildcard barrel re-exports, move to the Enhanced builder if you are on Pro, and use Turbopack's tracing output to find the actual hot modules instead of guessing.

If your Next.js upgrade landed on Vercel and CI started failing on builds that worked yesterday, that is the kind of work I do. See my services. For another Turbopack-specific gotcha I covered recently, see Next.js 16 Turbopack CSS Modules HMR breaking.