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.

[icyJoseph]

Are you able to repro this in a non prod environment? If so, give next@canary a go

[blf885]

Long story short, I was able to reproduce a leak in a non prod environment. I fixed that leak and deployed. But there was still another leak. I have not been able to reproduce this other leak yet locally. We had tried disabling image optimization previously and saw no noticeable impact. I'm going to try that again now that I fixed the other leak.

[blf885]

Disabling image optimization was noticeably better this time now with the other leak fixed. I did however still have the process crash due to the V8 heap exceeding the default --max-old-space-size of 2GB after 6 hours. So there must still be a leak.

[icyJoseph]

IIRC, there were two more patches to canary that addressed memory leaks. If you have a non prod env, maybe give canary a go there, or wait for the next release.

[blf885]

Thanks, I will check that out. It will be most helpful once I'm able to reproduce the leak locally. I have not been able to do that just yet.