Memory Leak Issue in Next.js 16.1.0 Causing OOM Crashes in Docker/Kubernetes Environment

[rameesac]

Summary

I'm experiencing a critical memory leak issue with Next.js 16.1.0 that's causing production instability.

Environment:

Next.js version: 16.0.1
Deployment: Docker container running in Kubernetes

Issue Description:
After building and deploying the application, we observe continuous memory growth over several hours, eventually resulting in OOMKilled errors and pod restarts.

Symptoms:

Progressive memory consumption leading to out-of-memory crashes
Linear increase in memory usage over time
Continuous restart cycles affecting service availability

Implementation Details:

Using the await connection() method in the root server component to load environment variables to inject and provide from a EnvProvider
Implemented a /ready GET endpoint in API routes for Kubernetes liveness probes call on every 10s

Request:
Has anyone else encountered similar memory leak behavior in Next.js 16.x? Any guidance on debugging or potential workarounds would be greatly appreciated.
Thank you for your assistance.

Memory Usage:

layout.tsx

EnvProvider.tsx (Thought of use it for env provider for whole application)

package.json

api/ready

Additional information

No response

Example

No response

[ismaildasci]

memory leak in next.js with k8s usually comes from few sources:

1. connection() in root layout - this runs on every request and might be caching something. try moving env loading to middleware or next.config.js instead:

// next.config.js
module.exports = {
  env: {
    CUSTOM_VAR: process.env.CUSTOM_VAR,
  },
}

2. context provider re-creating on each request - your EnvProvider might be creating new objects every render. memoize it:

const envValue = useMemo(() => ({ ...env }), [])

3. liveness probe every 10s - check if /ready endpoint is doing something heavy. should be just:

export async function GET() {
  return Response.json({ status: "ok" })
}

4. try standalone output mode for k8s:

// next.config.js
module.exports = {
  output: "standalone",
}

5. debug memory:

node --expose-gc --inspect server.js

then use chrome devtools to take heap snapshots

6. set memory limit in dockerfile:

ENV NODE_OPTIONS="--max-old-space-size=512"

what does your EnvProvider do exactly? if its fetching on every request thats probably the leak

[icyJoseph]

Hi, did you manage to make any progress here?

One thing you can quickly try is to turn off image optimization and see what the memory profile looks like during with that, get some data and turn on image optimization again.

As pointed out in the other comment, tweaking --max-old-space-size is often necessary too, because Node needs extra memory to run, other than the memory allocated by your user code so-to-speak.

Rule of thumb (AI suggestion):

• container limit 1024Mi → try heap 512–768
• container limit 2048Mi → try heap 1024–1536

A couple of other things are, making sure that you don't hold onto data globally, like when for each request you maybe copy some data into a global store, but never release it. Sometimes there's some Node.js patterns that implicitly do this, and never release memory, but these are less likely.

As mentioned above too, standalone mode can help, because it creates a minimal server, that can eliminate certain dependencies.

Try with next/image, tweak --max-old-space-size, and then switch Node.js version if possible, then Next.js version too, it is not uncommon for Node.js or Next.js to have released patches for some edge case memory leaks.

[blf885]

I'm also curious about progress. I'm encountering what appears to be the same thing. I have disabled image optimization, adjusted max old space size up to 6GB and it continues to grow and hit that limit. I've tried disabling the cache using cacheMaxMemorySize: 0 in config. I've tried limiting it to 128MB. Neither had any impact. I did not get a snapshot of the heap with the 0 setting. I may go back to that and get a snapshot to see if its disregarding that setting. Using Node 22.14.0 and Next 16.1.6. May start messing with versions as well.

[hotrungnhan]

@joshunger i'm still facing that issue, in both 16.2.3 and 16.2.1-canary.32.

[icyJoseph]

What issue though? the problem with this OOM reports is that, in some cases, GC is not running because the benchmarkd/demonstration keeps hammering the server, never letting go to run GC, but in your actual applications, user-code is misbehaving, but it is hard to trace. A repro repository is necessary, one such that is yours and represents your problem. We have seen people reusing someone else's repo, which we have investigate heavily already.

[hotrungnhan]

Ah, i mean i still got OOM, maybe it difference than this one, but in my case Memory keeps increasing without any upper limit until it hits the Docker limit and crashes.
I’ll share the example repository with you soon.

[joshunger]

@hotrungnhan just a shot in the dark are you running app/[lang] or app/[locale] or similar? Let's figure out what is common here.

This is the best advice I've seen from Tim - #90433 (comment)

Create a app/api/gc/route.ts:

export async function GET() {
  // @ts-ignore
  globalThis.gc();

  return NextResponse.json({
    ok: true
  });
}

Then -

CMD ["node", "--expose-gc", "server.js"]

And then:

ab -n 5000 -c 100 http://127.0.0.1:3000/
# leaving some time to have it settle. Then triggering again
ab -n 5000 -c 100 http://127.0.0.1:3000/

For larger applications, 5000 might be too high especially for Chrome to handle. You might want 500 or so.

You can then call http://127.0.0.1:3000/api/gc for the garage collection.

[hotrungnhan]

@joshunger Your idea is pretty solid. I enhanced it a bit to automate this behavior.
I created an instrumentation following the official guidelines to periodically trigger GC on an interval.
Now things are better overall, the RAM still increases, but it seem flatten, the rate is much slower rate than it before.

I used bun in my production server, it expose gc by default with no require flag.

//instrumentation.ts

import Bun from 'bun'
export async function register() {
  setInterval(Bun.gc, 1000 * 60)
}

[joshunger]

@icyJoseph this might be related to React.cache when the server is under load I'll see if I can find a repo

[PayteR]

We hit what looks like the same thing on 16.2.3 and can add some hard data, because we got as far as heap snapshot retainer analysis.

Setup: App Router, custom node server, production build, everything dynamically rendered. Under sustained GET load we retain 0.5-1 MB per request that survives forced GC. Reproduces on Node 22 and on Bun identically, and on 16.3.3 too, so it's not fixed by upgrading.

The React.cache suspicion in this thread matches what our snapshots show. Retainer chains of the leaked objects (sampled ~200 promises plus ~400 plain objects via memlab) consistently end in a module-scope nested Map -> WeakMap -> Map structure, which is the cache-node tree shape React's cache() builds, living inside react-server-dom-turbopack-client.node.production.js. It grows monotonically and nothing ever prunes it.

In our app the biggest cached content is next-intl (message ASTs + Intl formatters, there's a matching report at amannn/next-intl#2174), plus we see ~225 retained AsyncLocalStorage store entries (kResourceStore symbol) per request. So it looks less like one library's bug and more like per-request cache() scopes or their contents ending up rooted in a module-level cache that never gets released.

Current mitigation on our side is an RSS watchdog that gracefully restarts instances before OOM, which obviously isn't a fix. Can provide snapshot analysis output or a repro recipe if a maintainer wants to dig in.

[pkpio]

We had the exact same issue after spending days on heap analysis. It was narrowed down to the Next framework. My solution was also a watchdog that restarts the container well before OOM.

This works because we have a load balancer with multiple servers. Won't be ideal for a single server for a deployment.