Minecraft Server RAM for 2, 5, 10 and 20 Players

Why player count matters less than you think

The table is organised by headcount because that is the question people ask. But a player connection itself is cheap. What actually fills a Minecraft server's memory is loaded chunks, entities, and on modded servers, the mods themselves. Player count only matters indirectly, through how many chunks those players keep loaded.

Every player keeps a square of chunks loaded around them, sized by the view distance. Two players standing at the same base share almost all of those chunks, so the server holds roughly one square. Two players 10,000 blocks apart share none, so the server holds two full squares: twice the chunks, twice the block data, twice the entities and tile entities inside them. The same two people can double a server's memory use simply by walking in different directions.

That is why the table gives ranges and why a 20-player server that shares a spawn town can run in less memory than five explorers spread across a fresh world. When you size a server, think about how many distinct places your group is likely to be at once, not how many names are in the player list.

The second reason headcount is a weak guide is that most lag is not about memory at all. Minecraft runs its game loop on a single thread. Every 50 milliseconds it has to update every loaded chunk, every entity, every redstone circuit and every hopper, in order, on one CPU core. If that work takes longer than 50 milliseconds, the tick rate drops and everyone sees lag, no matter how much memory is free. CPU time per tick is what limits a busy server. RAM only decides whether the world fits in memory at all.

If you want the same question answered from the other direction, by server type rather than player count, read the companion guide How much RAM does a Minecraft server need?. This page assumes you already know what you are running and want the number for your group size.

View distance and simulation distance are the lever

Two settings in server.properties decide how many chunks each player loads, and they are the cheapest way to make a given amount of RAM go further.

view-distance is the radius, in chunks, that the server sends to each client. The default is 10, which is a 21 by 21 square of 441 chunks per player in a separate area. Dropping it to 8 loads 289 chunks per isolated player, about a third less. For a friend group, 8 to 10 is comfortable; you will not notice the difference in normal play, but the server will.

simulation-distance is the radius in which mobs move, crops grow and redstone runs. Chunks outside it stay loaded and visible but do not tick. Setting it to 5 or 6 cuts the CPU work per tick substantially without changing what players see, and it keeps entity counts down, which also saves memory. Farms only need to be inside the simulation distance of one player to keep working.

Practical rule: before you add RAM to a server that feels crowded, set view-distance to 8 and simulation-distance to 6, restart, and watch it for a session. Paper, Purpur and Spigot expose the same two settings and add per-world overrides on top. The Paper vs Spigot vs Purpur guide covers what else each of them lets you tune.

When to add RAM, and when it will not help

Add RAM when the server tells you it is out of memory. The signs are specific:

• java.lang.OutOfMemoryError in the log or crash report. The heap is full and Java could not allocate. This is the clearest signal.
• Long ticks caused by garbage collection. When the heap is nearly full, Java pauses the whole server to reclaim memory. In the log this shows up as "Can't keep up" warnings that come in bursts, or as watchdog reports where the stack trace does not point at any particular mod or plugin.
• The server process killed for exceeding its limit. On a host with a hard memory cap, the server disappears without a Java crash report at all, usually while chunks are generating or a large modpack is starting.

If you see any of these, move to the next size. The free crash analyzer reads a crash report or log and tells you whether the cause was memory, a watchdog timeout or something else.

RAM will not help with:

• Redstone lag. Clocks, large piston doors and item sorters are pure tick work. They run on the single main thread and use very little memory.
• Entity lag. Thousands of mobs in a farm, dropped items or minecarts cost CPU every tick. Memory is a minor part of it. Lower simulation distance, cap the farms or use Paper's entity limits.
• World generation. Generating fresh chunks is CPU-heavy and, on modded servers, extremely so. More RAM keeps the server from crashing during exploration but does not make the chunks arrive faster. Pregenerating the area your group will use is the real fix.

A simple test: if the server is laggy but the memory graph in your panel sits well below the limit, the problem is CPU, and the fix is in settings, farms or mods, not in the RAM slider.

What the extra RAM costs

On a flat monthly plan, oversizing costs you every day whether anyone plays or not. On pay-per-hour hosting, RAM is billed only while the server runs, which changes the decision. Alpenglow charges 1 credit per hour of 1 GB, credits cost €0.01 each, and the server sleeps when nobody is online, so an idle evening costs nothing.

Take a group that plays about 26 hours a month, for example three evenings a week at two hours each. A 4 GB server for those 26 hours is 4 × 26 = 104 credits, about €1.04. An 8 GB server for the same 26 hours is 208 credits, about €2.08. Doubling the RAM costs roughly one euro more a month. That is why the honest advice on pay-per-hour hosting is to start one size above the table if you are unsure, and to cut back later once you have seen the memory graph.

Worked example, five friends on a light Fabric pack. The table says 4 GB. They play three evenings a week, around 26 hours a month. That is 104 credits, about €1.04 a month. If two of them start a long expedition and the server hits an OutOfMemoryError, they change it to 6 GB and restart; the same hours now cost 156 credits, about €1.56.

Worked example, a 20-player SMP on Paper. Twenty people means the server is rarely empty, so assume it runs about 8 hours a day, 240 hours a month. At 6 GB that is 1,440 credits, about €14.40 a month. At 4 GB it would be 960 credits, about €9.60. The difference is small compared to the cost of the server being killed mid-session with 15 people online, so 6 GB is the right choice for a server that size with people spread across the map.

The Minecraft server cost guide compares this credit model with free hosts, flat plans and self-hosting in more detail.

Allocating RAM correctly on your own machine or another host

If you run the server yourself or on a host that lets you edit the start command, the number in the table is the Java heap size, set with the -Xmx flag. A typical start line for a 4 GB server looks like java -Xms4G -Xmx4G -jar server.jar nogui. Setting -Xms equal to -Xmx reserves the full heap at start and avoids the JVM growing it in steps during the first minutes of play.

Do not give Java all of the machine's memory. The JVM needs space outside the heap for its own bookkeeping, thread stacks and native libraries, and the operating system needs room for file caching, which is what keeps chunk loading from the disk fast. Leave 1 to 2 GB free for the OS. On an 8 GB machine, -Xmx6G is the sensible ceiling; on a 4 GB machine you are limited to a 2 to 3 GB heap, which is enough for a vanilla group but not a modpack. If the heap is set larger than the physical memory available, the server will be killed or swap to disk, which is worse than a smaller heap.

Modded servers on Forge, NeoForge, Fabric or Quilt follow the same rule, but check the pack's own recommendation; the modded server hosting guide walks through the setup. On Alpenglow you do not edit any of this: you pick a RAM size between 2 and 12 GB, and the JVM flags and Java version are set for you to match the software you chose. To change the size later, change the RAM in the panel and restart.