How much memory should I use as maximum when I run next.js in production?

[dokshor]

Hi community:

I'm planning to deploy two sites using next.js on EKS. I'm always thinking about don't loose the performance and out of memory in applications so, I would like to ask to you:

¿How much memory should I use, on a single instance, to don't be surprised about a memory leak?

Best.

[xabierlameiro]

There isn't a number, and that's not a dodge. Sizing can't protect you from a leak. A leak grows without bound, so whatever limit you pick gets reached eventually; the limit only decides how long the pod lives between restarts. Going from 512 MB to 4 GB doesn't buy you safety, it buys you eight times the interval and a slower feedback loop when something is actually wrong.

The version of your question that does have an answer: how much do you retain per request? Measure that, and the sizing falls out as arithmetic.

Put sustained load on a production build, sample the heap after a forced GC between rounds, and look at the growth per thousand requests. On healthy routes I measure noise in the hundredths of a MB per 1000 requests. A route I broke on purpose, with a module-level array, comes out at +472 MB per 1000. There's no gray area between those two: real retention is orders of magnitude above the noise, not slightly above it.

Once you have that figure it's division. Retain 0.5 MB per request, serve 100k requests a day, and you're adding 50 GB a day. No instance size saves you. Retain a flat 0.02 MB per 1000 requests and your steady-state working set is what you size for, plus headroom for peaks.

So the sizing procedure is: measure the working set at steady state under realistic load, not at boot, and set the limit above that with room for per-request peaks. Then watch the slope of RSS across the pod's lifetime. Flat sawtooth between deploys is healthy. A line that climbs every hour until it dies is a leak, and it will keep dying at whatever number you set.

Two things specific to what you're planning. You mentioned two sites on EKS: if you put them in the same instance with generous limits, the cgroup OOM killer picks by score across everything in it, so the leaking site can get the other one killed. You'll be debugging the wrong service. Separate limits per pod make the blame land where it belongs. And an OOMKilled in Kubernetes shows up as exit 137 with nothing in your Node logs, because the kernel doesn't let V8 print anything, so don't go looking for JavaScript heap out of memory in the logs. Its absence is itself the clue that it was the kernel and not the heap.

I package the measurement as next-leak:

npx next-leak .

Per-route, forced-GC sampling across cycles, and it gives you exactly the MB per 1000 requests figure to divide with. Node 22+ and output: "standalone".

If you post what your pods sit at after an hour of traffic versus right after a restart, that difference tells you whether you have a sizing question or a leak question. They're not the same problem.

[chinnathit]

If you just need a practical starting baseline for your Kubernetes limits before you run full load tests

• Typical SSR app: 512MB-1GB memory limit per pod is usually enough to get off the ground.
• Heavy ISR, image optimization, or large API responses: Start at 1-2GB.

A critical detail a lot of people miss in containers is --max-old-space-size. Even with newer Node versions reading cgroup limits better, V8 can still greedily allocate heap right up to the container's ceiling. When that happens, non-heap memory (native modules, buffers, worker threads) pushes the pod over the edge, and the kernel drops the hammer with a silent exit 137 instead of giving you a readable V8 heap error.

A solid rule of thumb is setting --max-old-space-size to about 75–80% of your container's memory limit so the OS has room to breathe.

Also, since you mentioned two sites on EKS, definitely run them as separate Deployments/Pods rather than shoving them into the same container/pod. If one site hits a sudden traffic spike or leaks, you don't want it bringing down the other one with it.