How much RAM does a Minecraft server need?Guideline values for vanilla, Paper and modpacks

Published on October 20, 2026

Guideline values by server type

The following values come from experience for a stable server, not the absolute minimum to start:

The jump with modpacks stands out: a pack with 200 mods takes up more memory when idle than a full vanilla server. More on this in Host modpacks.

What really drives the requirement

Four factors, roughly in this order:

• Mods and plugins - by far the biggest lever. Every mod brings its own blocks, recipes and world generators that stay in memory permanently.
• view-distance and simulation-distance - both determine how many chunks the server keeps loaded at the same time. The values are in server.properties.
• Distribution of players - ten players at ten distant locations load many times the chunks of ten players in one place.
• World size and entities - large farms with many mobs or item entities cost memory permanently.

The slot count is deliberately not in this list: with us, slots are unlimited anyway, and on their own they say little about the requirement.

Allocated memory and actual usage

Two misunderstandings regularly lead the assessment astray.

First: the memory that Minecraft may use as the Java heap is not the total memory requirement of the process. Besides it, the Java runtime needs space for loaded classes, threads and network buffers. Anyone who sets a plan's entire memory as heap leaves nothing for this part - the result is crashes even though the heap should be enough on paper.

Second: a high fill level is not an alarm sign on its own. Java does not return occupied memory immediately but only cleans up when it gets tight. The curve therefore looks like a sawtooth: rising slowly, dropping suddenly. What matters is not the peak, but whether noticeable headroom appears again after a clean-up.

This gives the rule for assessment: if the value stays at the limit permanently and hardly drops even after cleaning up, memory really is too tight. If, on the other hand, it swings widely up and down, the server is working normally - then stuttering is a different problem.

How do I tell that RAM is tight?

Not every stutter is a memory problem. These point to too little RAM:

• Crashes with java.lang.OutOfMemoryError or Could not reserve enough space for object heap in the log.
• Regular, short freezes every few seconds - typical of constantly running garbage collection.
• The server becomes increasingly sluggish over hours and runs smoothly again after a restart.

If memory looks unremarkable and the server stutters anyway, it is usually down to CPU load or individual plugins - covered in Lag and TPS.

Save memory instead of adding more

Before you reach for the next bigger plan, it is worth looking at what is taking up memory in the first place. These levers take effect after a restart and cost nothing:

• Lower the view distance. view-distance and simulation-distance determine how many chunks are kept loaded at the same time. The effort grows disproportionately with the value - even two steps lower are clearly noticeable.
• Clean up entities. Large mob farms and piles of leftover items cost memory permanently, even when nobody is standing next to them.
• Remove unused worlds. Every loaded world keeps its own chunks in memory - see Run multiple worlds.
• Clear out extensions. Plugins and mods that nobody uses any more still take up memory. What is responsible for what is clarified in Install plugins & mods.

Tackle the points one at a time, not all at once - otherwise you will not know afterwards what worked. Only when they are done and the server still hits the limit is a bigger plan the right step.

Conversely: if the decision is still open and the server has not been ordered yet, Plan your server size approaches it from the other side - via edition, software and play style instead of symptoms during operation.

Restarts free memory - but solve nothing

A restart resets memory cleanly: all chunks are unloaded, accumulated objects disappear, the server starts with a free heap. Using the restart scheduler in the web interface, you set a fixed time for this, ideally at night when nobody is playing.

This is good hygiene, especially with large modpacks. But it does not replace a root-cause analysis. If your server does not make it through an evening without a daily restart, either memory is sized too tight, or a single extension does not release occupied objects again.

So do not shorten the intervals until it just about fits; observe what grows between two restarts. If the bottleneck is reached faster after each restart, that points to entities or an extension. If usage instead rises steadily with the number of players and the size of the settled area, it is simply the sizing - then only more memory or a smaller view distance helps.

More RAM is not always the solution

Minecraft is largely single-thread limited: the world tick essentially runs on one core. If that core is maxed out, additional memory does not change the tick rate.

Nor does it help to assign 16 GB to a small vanilla server - very large heaps can even lengthen garbage collection pauses. It makes sense to align the requirement with the actual server type and then observe it.

Unsure which plan to pick? The resources per plan are listed on the Minecraft product page, and which plan suits which project is explained in How much does a Minecraft server cost?.

Frequently asked questions