How much RAM does a Minecraft server need?

The honest short answer: 2 GB runs a vanilla or Paper server for up to about five friends, 4 GB covers a small public server of ten to twenty, 6 GB covers a light modpack or thirty players on Paper, 8 to 10 GB covers a serious modpack for a small group, and past about 12 GB you are almost always solving the wrong problem with the wrong resource. Memory is the easiest thing to buy and the least likely thing to be broken. This post explains what the number is actually made of, where the two settings that move it live, and how to tell in five minutes whether memory is your bottleneck or whether you are about to pay for nothing.

What a Minecraft server keeps in memory#

A Minecraft server does not load the world. It loads the parts of the world somebody is standing near, and it throws the rest away. Memory therefore scales with how much of the world is resident at once, which is roughly the player count multiplied by the area each player keeps loaded, and barely at all with how large the world is on disk. A 40 GB world with three players online is cheap. A 2 GB world with thirty players scattered across four dimensions is not.

Inside the Java heap, the big consumers are:

• Loaded chunks. A chunk is a 16 by 16 column of blocks from the world floor to the build limit, held as palettes of block states plus light data. At view-distance=10 a single player keeps a square of 21 by 21 chunks loaded, which is 441 chunks. At 8 it is 289. At 6 it is 169.
• Entities and block entities. Mobs, dropped items, minecarts, armour stands, and every chest, hopper, sign and shulker box in a loaded chunk. This is where farms and hoarder bases hurt: a chunk containing 400 hoppers costs far more than an empty one.
• Player data and inventories, which are small, plus the network buffers behind each connection, which are not nothing at thirty players.
• Plugin or mod state. Region caches, permission trees, block-logging queues, a web map's tile cache, a pathfinding graph. Some plugins hold more than the world does.

Outside the heap, the JVM itself needs memory the heap setting does not cover: metaspace for loaded classes, the JIT code cache, one reserved stack per thread and Netty's direct byte buffers. A modded server with three hundred mods can put 400 to 600 MB into metaspace alone. That gap between "heap" and "what the container needs" is the single most common sizing mistake, and it has its own section below.

RAM by player count and server type#

These are working numbers for a server that has been tuned rather than left on defaults, with view-distance at 8 and simulation-distance at 6. Add a tier if you run a web map, heavy block logging, or three dimensions that people actually use.

Two things that are not on the table because they change the answer more than player count does. First, dimensions: the Nether and the End are separate worlds with their own loaded chunks, so a group that has moved on to End busywork is loading two or three times the area it was during week one. Second, spread: ten players in one town load a fraction of what ten players exploring in ten directions load, and the second group also generates new terrain while they do it, which is the most expensive thing a server does. World borders and pregeneration is the fix for both, and it is free.

Heap, container and the gap you must leave#

If you run the server yourself, you set the heap with two flags:

$ java -Xms3G -Xmx3G -jar paper.jar --nogui

-Xmx is the maximum heap. -Xms is the starting heap, and the long-standing advice for Minecraft is to set them equal, so the JVM never spends time growing and shrinking a heap it is going to fill anyway. On a panel-based host you do not type that line - the value is a field on the Startup tab, and the panel builds the command.

The trap is setting -Xmx to the container's whole limit. On a 4 GB plan, -Xmx4G tells Java it may use every byte the container has, and then metaspace, thread stacks and Netty buffers push the process over the limit. What happens next depends on the host, and it is never a clean Java error: the kernel stops the process, the log simply ends, and there is no crash report to read. Leave headroom:

Roughly: leave 25% or 512 MB, whichever is larger, and lean towards more on a heavily modded server because metaspace grows with mod count, not with player count.

View distance and simulation distance#

Since 1.18 there are two distance settings in server.properties, and confusing them wastes both money and tick time.

view-distance=8simulation-distance=6entity-broadcast-range-percentage=100network-compression-threshold=256max-tick-time=60000

The first two are the ones that decide your sizing:

• `view-distance` (default 10) is how many chunks out from each player the server keeps loaded and sends to the client. This is the memory and bandwidth lever. Going from 10 to 8 cuts the loaded square per player from 441 chunks to 289, a 34% reduction, and almost nobody notices in survival.
• `simulation-distance` (default 10) is how far out chunks actually tick: mobs move, crops grow, redstone runs, hoppers pull. This is the CPU lever. Most servers can sit at 6 with no complaints, and farms outside that radius simply stop until someone comes back.

The default pairing of 10 and 10 is generous for a single-player-sized world and wasteful for a server. The standard tuning is view-distance=8 with simulation-distance=6: players still see a reasonable horizon, and the server only simulates what is close enough to matter. Paper can also set both per world in config/paper-world-defaults.yml, which is how you give the lobby a distance of 4 and the survival world 8. Paper optimisation covers the rest of those files, and every `server.properties` key covers the ones this post skips.

One more that helps a busy server without touching memory: entity-broadcast-range-percentage. At the default 100 the server tells each client about entities across its whole view distance. Dropping it to 50 roughly halves the entity packets going out, which matters on a public server at forty players far more than an extra gigabyte of heap would.

Why a bigger heap stops helping#

Java does not use memory it has not been asked for, so an idle server on a 14 GB plan does not run better than the same server on 6 GB. Worse, a larger heap makes each garbage collection pause longer, not shorter, because there is more to walk. A twenty-player Paper server handed 16 GB typically produces the same average tick rate as the same server on 6 GB, with noticeably worse stutters when the collector runs.

There is a real threshold to know about. Below roughly 12 GB, G1 (the default collector, and what the community's standard flag set is tuned for) behaves well with a 200 ms pause target. Above it, the tuning changes - the widely used flag set tells you to raise G1NewSizePercent and G1HeapRegionSize for large heaps, and some big modded servers move to Shenandoah or generational ZGC on Java 21 instead. None of that is a reason to buy a large heap you do not need; it is a warning that a large heap is a configuration project, not a purchase. JVM flags and Java versions has the actual flag sets.

So the uncomfortable rule: if the server is stuttering and the memory graph is sitting well below the limit, memory is not your problem and adding it will change nothing. What you have is a CPU problem, a distance setting, a chunk-generation problem or one badly behaved plugin. CPU vs RAM for game servers is the general version of this argument; why TPS drops is the Minecraft-specific one.

Proving memory is the problem#

Five minutes of evidence beats an afternoon of guessing. In order:

1. Watch the memory graph while people play. A healthy Java server saws: it climbs, the collector runs, it drops back. If it climbs to the limit and stays flat against it, you are short. If it peaks at 60% and stays there, you are not.
2. Run a profiler. spark is the standard: /spark profiler start, play for a few minutes, /spark profiler stop, and read the link it prints. It names the plugin, mod or system eating the tick. /spark health prints TPS and memory together, and /spark heapsummary tells you which classes are holding the heap - if the top entry is a plugin's own cache, you have found your answer and it is not a plan upgrade.
3. Read MSPT, not TPS. On Paper, /mspt shows milliseconds per tick. A tick has 50 ms. At 45 ms you are one entity farm away from visible lag while TPS still reads 20.0, so MSPT warns you earlier.
4. Drop `view-distance` by two and restart. Free, reversible, and the biggest single lever on a busy server. If that fixes it, you had a distance problem, not a memory problem.
5. Check the garbage collector, not the average. A server with 20 TPS and a 3-second freeze every ten minutes has a GC problem - usually an oversized heap or a plugin allocating hard in a loop. /spark gcmonitor reports pauses as they happen.

Modpacks change the arithmetic#

A modpack is a different kind of workload, and the sizing advice above shifts in three specific ways.

Class loading is real memory. Three hundred mods means tens of thousands of classes, and metaspace lives outside the heap. This is why a modpack that "should fit in 6 GB" dies on a 6 GB container with -Xmx6G: the heap was fine and the process still went over. Give the same pack -Xmx4500M on the same plan and it often runs.

The first start is the worst start. A modded server loads and registers everything, then generates spawn chunks with whatever worldgen mods the pack ships. Peak memory during that first ten minutes can be well above the steady state, and people size for the steady state and get killed in the first minute. Start it once with nobody online and watch the peak.

Worldgen mods multiply everything. A pack with a large biome mod generates more varied, more structure-dense terrain, which costs memory to hold and disk to store. Pregenerating with Chunky before anyone logs in converts an unpredictable run of lag spikes into one long boring job you can schedule overnight.

Practical modded numbers: 30 to 80 mods on Fabric with the usual performance set runs happily in 6 GB. A 150-plus-mod Forge or NeoForge pack wants 8 to 10 GB. A 1.12-era kitchen-sink pack with hundreds of machines wants 10 GB and Java 8, which is its own trap - see modded Minecraft without the crashes for the Java version matrix and how to read a crash report that is actually about memory.

What happens when you hit the limit#

There are three different failures and they look nothing alike, so learn to tell them apart:

• `java.lang.OutOfMemoryError: Java heap space`. The JVM asked for space inside its own heap and could not get it. You get a stack trace, usually a crash report, and often a server that limps for a while first. Raise -Xmx if there is room under the container limit; otherwise raise the tier or cut the load.
• `OutOfMemoryError: Metaspace` or `GC overhead limit exceeded`. The first is class-loading pressure, the second means the collector is running constantly and reclaiming almost nothing. Both usually mean a modpack that is one size too small for its plan.
• The log just ends. No exception, no crash report. The process was stopped from outside because the container went over its memory limit. On RE:NODE that is deliberate: at the limit the server is stopped and restarted clean rather than left to swap, because a swapping Minecraft server is worse than a restarting one. The cost is anything the world had not saved yet, which is why a short autosave interval and real backups matter. A crash watcher also notices repeated restarts - three in an hour raises a warning on the server page and opens a ticket automatically, which is usually the first time somebody realises -Xmx was set to the whole plan.

Whichever it is, take the tier that fits with a little headroom rather than the largest one you can afford. Moving up changes the limit on the server you already have, so the world, plugins and configuration stay exactly where they are and there is no penalty for starting smaller. When to upgrade your plan covers the signals that mean it is genuinely time.

FAQ#

Is 2 GB enough for a Minecraft server?

For up to about five players on vanilla or Paper with view-distance=8, yes, comfortably. Set -Xmx to around 1500M so the JVM's off-heap use still fits, keep the plugin list short, and do not run a web map on it. 2 GB is not enough for any modpack.

Does a bigger world need more RAM?

Almost not at all. Only loaded chunks are resident, so world size drives disk use rather than memory. What a big world does change is generation: players exploring unpregenerated terrain create the worst lag spikes on most servers, and a world border plus pregeneration fixes that without more memory.

Should -Xms and -Xmx be the same?

On a dedicated game server, yes. The heap is going to fill to roughly the same level every session, so letting the JVM grow and shrink it only adds work. Equal values also make the memory graph easier to read, because a flat line at the top then means something.

Why does my server use all the RAM I give it?

Because that is how a generational collector works: it fills the young generation, collects, and fills it again. High usage is not a shortage. The signal to look for is usage pinned at the limit with no drop after a collection, plus rising MSPT.

Do more plugins mean more RAM?

Less than people assume. A typical plugin costs a few megabytes of classes and whatever it caches. What plugins really cost is main-thread time, which shows up as tick rate rather than memory. The exceptions that genuinely eat heap are web maps, block loggers with large in-memory queues, and anything that caches regions or chunk data.

How much RAM does a modded server need per player?

The wrong question for modded. The pack's own footprint - mod classes, registries, worldgen - dominates, and it is paid whether one person is online or eight. Size for the pack first, then add roughly 250 to 500 MB per concurrent player beyond the first handful.