How to Fix “Server Is Approaching the Used Memory Threshold” in a Next.js App

Getting a server memory warning doesn't always mean your application has a memory leak. Sometimes, old Next.js build files and other cached data can contribute to resource usage.

If you're running a Next.js application on a VPS, AWS server, or another cloud server, you may eventually see a warning such as:

Server is approaching the used memory threshold

Before assuming something is seriously wrong, check what is actually consuming your server's resources.

First, Check Your Server Memory

On Linux, you can start with:

free -h

You can also check running processes:

top

or:

htop

Look for processes using significant amounts of memory, such as:

• Node.js

• Next.js

• PostgreSQL

• Nginx

• Docker containers

• Other background services

This helps determine whether the problem is really your Next.js application.

Check Your .next Folder

If you're using Next.js, your production build is normally generated inside:

.next

Over time, especially if you repeatedly build and deploy the application, build-related files can take up considerable disk space.

Check its size:

du -sh .next

If it has become unnecessarily large, you can remove it:

rm -rf .next

Then create a fresh production build:

npm run build

And start the application again:

npm start

For a typical deployment, the sequence can be:

rm -rf .next
npm install
npm run build
npm start

You don't necessarily need to run npm install every time. If your dependencies haven't changed, deleting .next and rebuilding is usually enough.

Why Can Rebuilding Help?

The .next directory contains generated build output and caches used by Next.js.

If something has become stale, corrupted, or unnecessarily large, removing the directory gives Next.js a clean starting point for the next build.

Think of it as:

Old build → Delete .next → Fresh build → Fresh build output

This can resolve some deployment and build-related problems.

However, deleting .next does not magically fix a genuine RAM leak. If Node.js or another process is continuously consuming memory, you need to investigate that process separately.

Don't Confuse RAM With Disk Space

This is important.

Your server has different types of resources.

• RAM: Check with free -h

• Disk space: Check with df -h

• CPU usage: Check with top or htop

• Swap usage: Check with free -h

A large .next folder primarily affects disk usage, not RAM.

So if your hosting provider specifically says memory/RAM is approaching its threshold, deleting .next may not solve the underlying problem.

Check Node.js Processes

You can check Node processes with:

ps aux | grep node

If you find multiple Next.js/Node processes running, you may be unintentionally running more than one application instance.

For example:

node server.js
node server.js
node server.js

Three application processes can consume significantly more memory than one.

Check Your Logs

Logs can also grow over time.

For example, check your disk:

df -h

Then identify large directories:

du -sh * | sort -h

You may discover that the problem isn't Next.js at all.

It could be:

• Application logs

• Docker images

• Old deployments

• Database files

• Uploaded files

• Build artifacts

A Simple Troubleshooting Checklist

When you receive a memory warning, don't immediately restart the server.

Try this:

1. Check RAM

free -h

2. Check running processes

top

3. Check disk space

df -h

4. Check .next

du -sh .next

5. Rebuild if necessary

rm -rf .next
npm run build

6. Check whether multiple Node processes are running

ps aux | grep node

7. Monitor the server again

If memory continues increasing after a clean build and restart, investigate the application or another server process instead of repeatedly deleting .next.

Final Thoughts

A “server is approaching the used memory threshold” warning doesn't automatically mean your Next.js application has a serious problem.

Start by finding out what resource is actually being exhausted.

If you're dealing with stale or unnecessarily large Next.js build output, removing .next and creating a fresh production build can be a useful cleanup step.

But remember:

Clean the build when the build is the problem. Diagnose the process when memory is the problem.

That distinction can save you a lot of unnecessary server restarts.