How Much RAM Does a Modded Minecraft Server Need? (2026 Guide)

If you're setting up a modded Minecraft server, the first question is always "how much RAM do I need?" Too little and your server freezes every few minutes. Too much and you're paying for memory that sits idle.

This guide gives you a starting number for every major modpack, then shows you how to measure what your server actually uses, which matters more. The same modpack with four friends at view distance 6 is a completely different machine than a public server with 30 people exploring fresh terrain.

What RAM Actually Does on a Minecraft Server

Minecraft runs on Java, and Java doesn't use memory the way most programs do. When you "allocate 8 GB," you're setting the size of the heap, a pool the server fills with objects and periodically cleans out. That cleanup is garbage collection (GC), and GC is the thing that actually hurts you.

What fills the heap:

• Loaded chunks: usually the biggest share. Every player keeps a square of chunks loaded around them, and since 1.18 the world runs from Y −64 to 320, so each chunk holds roughly double the block data it did in 1.16.
• Entities and block entities: mobs and items, plus every machine, chest, tank, and cable a modpack adds. Block entities tick and hold state; a big automated base is thousands of them.
• Mod registries: item, block, recipe, and tag tables. A 400-mod pack loads hundreds of thousands of recipes before a single player joins. That's fixed overhead you pay at startup no matter how empty the server is.

When the heap is comfortably sized, GC runs often, finishes in a few milliseconds, and nobody notices. When it's too small, the server is constantly out of room and Java falls back to a full "stop-the-world" collection that freezes every player at once for seconds. That's the stutter people blame on their internet. It's not the network. It's GC.

This is also why more RAM doesn't make a server faster. Once you have enough headroom that GC isn't struggling, extra memory buys you exactly nothing in TPS. RAM is a floor to clear, not a dial to turn up.

Allocated RAM vs. Plan Size: Read This Before You Buy

This one trips up almost everyone. The heap is not the only memory the server needs. On top of your -Xmx value, the Java process also uses:

• Metaspace: the loaded mod classes themselves. Substantial on large packs.
• GC bookkeeping: the structures the collector uses to track the heap.
• Thread stacks and off-heap buffers: networking and chunk I/O.

Together that's roughly 1–1.5 GB above your heap on a modded server. So if you buy an 8 GB plan and set -Xmx8G, the process reaches for about 9.5 GB, crosses its limit, and gets killed. The server just dies. Because the kill happens outside Java, there's no error in the log explaining why. If your server vanishes with no crash report, this is almost always the cause.

The rule: set your heap to about 80% of your plan size. The remaining 20% isn't wasted. It's what keeps the JVM alive.

Plan size	Set heap to
4 GB	-Xmx3G
6 GB	-Xmx5G
8 GB	-Xmx6G
12 GB	-Xmx10G
16 GB	-Xmx13G

Paper, Forge, or Fabric: Which One You're Running Changes Everything

Before the numbers mean anything, you need to know what server software you're on, because these cannot run each other's content:

• Paper / Purpur: plugin servers. Heavily optimized and light on memory. They run plugins (EssentialsX, LuckPerms, WorldGuard) and cannot load Forge or Fabric mods at all. This is what most SMPs and minigame networks run.
• Forge / NeoForge: the mod loaders nearly every big modpack targets: ATM10, Vault Hunters, RLCraft, Direwolf20. Heavier than Paper, and where all the large RAM numbers below come from.
• Fabric: a lighter, faster-updating loader. Performance mods like Lithium and FerriteCore live here, and some modern packs ship Fabric builds.

If a guide tells you it benchmarked ATM10 "on Paper," treat the whole page as unreliable. Paper cannot load ATM10 in the first place. In the table below, the plugin row is Paper; every modded row is Forge, NeoForge, or Fabric.

RAM Requirements by Modpack

These are heap figures (your -Xmx) alongside the plan size that leaves room for the JVM. They assume default view distance 10 and the player counts shown. Modpacks change fast, so treat this as a starting point and then measure. The next section shows you how.

Modpack	MC	Heap	Plan size	Players
Vanilla / Paper (plugins only)	1.21	4–6 GB	6–8 GB	20–40
Fabric + performance mods	1.21	3–4 GB	4–6 GB	10–20
Create: Above and Beyond	1.16.5	5–6 GB	7–8 GB	8–12 ⚙
Pixelmon	1.20.2	6–8 GB	8–10 GB	10–15
RLCraft	1.12.2	5–6 GB	7–8 GB	5–10 ⚙
Vault Hunters 3	1.18.2	8–10 GB	10–12 GB	5–10
Better MC (BMC4)	1.20.1	8–10 GB	10–12 GB	8–12
FTB Direwolf20	1.21	6–8 GB	8–10 GB	5–10
Enigmatica 10	1.21	8–10 GB	10–12 GB	5–8
All the Mods 10 (ATM10)	1.21	10–12 GB	13–16 GB	5–10
GregTech: New Horizons	1.7.10	6–8 GB	8–10 GB	3–6 ⚙

⚙ = CPU-limited before it is RAM-limited. These packs tick huge numbers of machines or entities. Buying more memory will not raise their player ceiling; a faster CPU core will.

Note how little the version column moves with the year: RLCraft is 1.12.2 and GTNH is 1.7.10, and both are lighter on memory than a modern 1.21 pack with half the mod count. Post-1.18 world height is a big part of why.

How to Find Your Actual Number

The table is a starting point. Your server is the real answer, and finding it takes about a week:

1. Start from the pack's own recommendation. CurseForge and Modrinth list a suggested allocation on every modpack page. For a handful of players, the server needs roughly that much heap; for 10+, add a few GB.
2. Add the JVM overhead to get your plan size: heap ÷ 0.8, per the rule above.
3. Run it for a week of normal play, including at least one session where someone explores new terrain. Chunk generation is the heaviest thing your server ever does.
4. Read the memory graph, then adjust: up if you see the symptoms below, down if you're sitting at half usage after a busy evening.

Reading memory the right way

Install spark (it works on Paper, Forge, NeoForge, and Fabric) and run /spark heapsummary. Or just watch the memory graph in your panel.

Now the part that confuses everyone: a Java heap that looks 90% full is usually fine. Java doesn't tidy up until it needs the space, so used memory climbs steadily, drops sharply during a collection, and climbs again. That sawtooth is a healthy server.

What matters is the level right after a collection, not the peak. If usage falls back to 40–60% after each GC, you have plenty. If it only falls to 85–90% and immediately climbs again, the server is short on memory and about to start stuttering.

Is It RAM, or Is It CPU?

Both look like "lag," but they need opposite fixes. Buying RAM for a CPU problem is the most common way people waste money on hosting.

It's RAM if…

• The server runs fine, then freezes hard for 2–10 seconds, then recovers, over and over.
• Heap usage stays above ~85% immediately after garbage collection.
• The console shows java.lang.OutOfMemoryError: Java heap space.
• The process dies with no crash report at all. That's the container OOM-killing a JVM whose -Xmx was set too close to the plan size.
• It gets noticeably worse when someone explores new chunks.

It's CPU if…

• TPS sits consistently low (say 12–18) without the freeze-and-recover pattern.
• MSPT is steadily above 50 ms.
• It's bad even with one or two players online.
• /spark profiler shows time going into mod tick methods rather than GC.
• You're running big mob farms, GregTech machine arrays, Create contraptions, or lots of chunk loaders.

If the symptoms are in the second list, more RAM will change nothing.

The Cheapest Fix Nobody Tries First: View Distance

Before buying more memory, open server.properties and look at two settings:

• view-distance: how many chunks each player can see. This is your single biggest lever on memory, because loaded chunks scale with the square of the distance. Going from 12 to 8 cuts each player's loaded area from 625 chunks to 289, a 54% reduction, and most players won't notice on a modded server.
• simulation-distance: how far out entities, redstone, and crops actually tick. This one is mostly CPU. Dropping it to 6 is a common fix for entity-heavy packs.

Try view distance 8 and simulation distance 6 before you upgrade. On a crowded server it often does more than adding 4 GB.

The Quick Rule

If you just want a number to start from, these are plan sizes, not heap:

• 6 GB: plugin servers, light Fabric packs, small friend groups.
• 8–10 GB: most mid-size packs (Direwolf20, Pixelmon, Better MC).
• 13–16 GB: kitchen-sink and expert packs (ATM10, Enigmatica, Vault Hunters) or 10+ players.

Past 16 GB, the Minecraft server itself is rarely the reason. The things that genuinely justify more are high view distances on a populated server, world pregeneration, live map renderers like Dynmap or BlueMap, and running several servers on one machine. If none of those apply to you and 16 GB isn't enough, you have a CPU problem or a badly behaved mod, and more memory won't touch either.

RAM Isn't Everything: CPU Matters More Than You Think

Minecraft's tick loop is single-threaded, so TPS depends on how fast one core is, not on how many you have or how much memory you bought.

The order matters, though. Clear the RAM floor first, then spend everything else on CPU. A fast Ryzen core with a 6 GB heap will beat an old Xeon with 16 GB on any pack that fits in 6 GB, but give that same Ryzen an ATM10 world and it will still stutter, because no clock speed rescues a heap that's too small to hold the pack. Once you're past the floor, extra memory does nothing and extra clock speed does everything.

At Revitalize, every game node runs modern AMD Ryzen processors with high single-clock boost, not repurposed server Xeons. You can see the exact hardware on our pricing page.

JVM Flags That Actually Help

Don't use default JVM args. These Aikar-optimized flags are the community standard and reduce GC stutter significantly:

-Xms6G -Xmx6G -XX:+UseG1GC -XX:+ParallelRefProcEnabled
-XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions
-XX:+DisableExplicitGC -XX:+AlwaysPreTouch
-XX:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4
-XX:G1MixedGCLiveThresholdPercent=90
-XX:G1RSetUpdatingPauseTimePercent=5
-XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem
-XX:MaxTenuringThreshold=1 -XX:G1NewSizePercent=30
-XX:G1MaxNewSizePercent=40 -XX:G1HeapRegionSize=8M
-XX:G1ReservePercent=20 -XX:InitiatingHeapOccupancyPercent=15
-Dusing.aikars.flags=mcflags.emc.gs
-Dfile.encoding=UTF-8

Set -Xms and -Xmx to the same value as each other. A fixed heap avoids the JVM resizing it mid-tick. But set them to about 80% of your plan size, not the full amount. The example above is tuned for an 8 GB plan. Setting -Xmx8G on an 8 GB plan is the mistake from earlier in this guide: it leaves nothing for metaspace and off-heap buffers, and the server gets killed with no crash report.

If your heap is 12 GB or larger

The flags above are the standard set, which is tuned for heaps under 12 GB. Large heaps need a bigger young generation and bigger regions, or you'll get long pauses anyway. For -Xmx12G and up, change these five values:

-XX:G1NewSizePercent=40      (was 30)
-XX:G1MaxNewSizePercent=50   (was 40)
-XX:G1HeapRegionSize=16M     (was 8M)
-XX:G1ReservePercent=15      (was 20)
-XX:InitiatingHeapOccupancyPercent=20  (was 15)

This matters for ATM10, Enigmatica, and anything else in the 13–16 GB tier. Running a 14 GB heap on the small-heap flags is a common reason a well-specced server still stutters.

Our custom panel includes a built-in Java flags tuner with both presets, so you don't have to paste any of this by hand.

Storage Speed Is the Hidden Bottleneck

Modded servers hammer the disk during chunk generation, especially with terrain mods like Biomes O' Plenty or Terralith. NVMe vs SATA SSD is the difference between 30-second world loads and 3-minute ones. Avoid spinning rust entirely. Every Revitalize server uses NVMe storage, with no exceptions and no "SSD cache" tiers.

How Player Count Changes the Math

A player sitting in an already-built base costs roughly 100–200 MB. A player walking into unexplored terrain costs several times that, because the server is generating and holding new chunks as fast as they move. Player count matters far less than how spread out everyone is. Ten people in one base is cheaper than three people in three different dimensions.

For a heavy pack like ATM10, as plan sizes:

• 1–5 players: 13 GB
• 5–10 players: 16 GB
• 10–20 players: 16 GB, with view distance reduced to 8
• 20+ players: more CPU, not more RAM

That last line is the important one. Past roughly 20 concurrent players on a heavy pack, you stop running out of memory and start running out of tick budget. The server can't finish its work inside the 50 ms it has per tick. No amount of RAM fixes that.

If you're running a public server with 20+ concurrent, you need to upgrade your CPU allocation too, not just RAM. Our VPE (Virtual Pulse Environment) lets you resize both independently in the panel without opening a ticket.

Frequently Asked Questions