Oct 30, 2026Blog

How much RAM does Next.js need on a VPS?

PRNext

There is no single RAM requirement for every Next.js application. A static page, a session-based dashboard and a page rendering large tables perform different work. Monthly visitor counts alone say little about the VPS you need.

A better question is how much memory your application requires with its dependencies, concurrent peaks and deployment workflow. This guide builds that budget while keeping compilation separate from the server handling visitors.

Separate build, idle and load

A build transforms source code and can generate pages ahead of time. An idle server keeps its runtime and loaded modules. Under load, multiple renders, network calls and responses can be active together. Measure these three states separately.

When CI performs the build, its peak does not directly size the production VPS. If the same server builds and serves the site, budget for both during that interval. Deployment overlap between an old and new release adds another scenario to test.

Measure the right processes

The JavaScript heap is only part of Node’s memory. RSS includes resident process pages, including native allocations. On Linux, PSS apportions shared pages proportionally and is useful when comparing process trees.

For a systemd service, also observe cgroup memory. It covers the group using its own accounting, which differs from PSS. Record the metric and keep it consistent between runs. Measuring one worker alone misses the parent, other workers and native components.

Terminal

systemctl show my-next-app.service -p MemoryCurrent -p MemoryPeak
ps -eo pid,ppid,rss,comm --sort=-rss

Measure your routes and traffic peaks

Observe idle memory after a few visits have loaded common paths. Then apply gradually increasing load to a dynamic page, an API and your expensive routes. Validate response content: a lightweight error page can produce impressive throughput while hiding a failure.

Record peak memory, latency, errors and concurrency. Include authenticated traffic if the application depends on sessions. Anonymous homepage traffic may not describe a customer dashboard. A short run is a starting point, not evidence of stability over weeks.

Budget for the whole server

Add the operating system, proxy, any database, applications and headroom for peaks and deployments. Use measurements from the target server or a representative environment. A memory limit protects a boundary; it does not guarantee enough room for the application.

Hypothetical example: from 2,048 MiB, reserve 500 MiB for the system and shared services, then 400 MiB for peaks and deployment overlap. That leaves 1,148 MiB for applications. These values illustrate the calculation, not a Next.js minimum or universal recommendation. Replace them with your measurements.

Read benchmarks with their configuration

In our PRNext versus Next.js campaign, the ordinary SSR page on the small VPS uses 113.88 MiB PSS for PRNext and 101.38 MiB for Next.js. With the two-CPU budget on the other machine, the values are 117.50 and 173.30 MiB. The ranking depends on the context.

These results describe an identified PRNext 0.1.18-alpha candidate, a fixture application and short windows. They do not measure your application, its build or the final release archives. Sleep is another state: it releases inactive workers’ memory and adds a wake-up cost.

Read the benchmark configurations and data

Understand idle memory and wake-up cost

Decide from the actual bottleneck

Enough memory does not prevent a saturated CPU from increasing latency. More CPU does not fix retained objects or a database short of memory. Look for the resource that degrades when requests slow down.

Repeat the same workload after each change. If memory keeps growing at comparable work without settling, investigate retention. If the peaks are legitimate, reconsider where builds run, the process count or the available capacity.

Diagnose high Next.js memory usage