The plan picker makes this look like a player-count question. Five friends, one number, done. Then one of those friends installs a large modpack and another decides to build an industrial district.
RAM matters, but buying more of it is not a universal fix. Start with a sensible amount for your setup, leave some breathing room, and check what the server uses when people are actually playing.
A small survival server can start around 4 GB.
For a few friends on vanilla or a light Paper setup, I would start by looking at 4 GB. More players or plugins can push that toward 6 to 8 GB; substantial modpacks often need 8 to 12 GB or more. Treat those as planning ranges. The exact pack requirements and a busy evening on your server matter more than a generic table.
Minecraft Java Edition · Hosting plan memoryMinecraft server RAM at a glance
Count the people who will be online together. Your Discord might have forty members; your Tuesday evening server might have four. These starting ranges cover the whole server container, including room outside Java's heap.
| Players online | Server setup | Plan RAM |
|---|---|---|
| 1 to 5 | Vanilla or lightly configured PaperA small survival world with modest distances and few extras. | 4 GB |
| 5 to 15 | Paper or Purpur with pluginsAllow room for exploration, extra worlds and plugin data. | 6 to 8 GB |
| 15 to 30 | An active survival communityMeasure peak usage; farms and loaded chunks can change the result. | 8 to 12 GB |
| A small group | A substantial Forge, Fabric or NeoForge modpackFollow the exact pack's server recommendation first. | 8 to 12 GB+ |
| 30+ | A large community or demanding modpackStart from measured demand. CPU, configuration and architecture also matter. | Profile first |
These are estimates for modest distances and a reasonably configured server. A big farm, custom plugins or a demanding pack can change them. Use the pack author's server requirements first.
A 2 GB allocation can work for some very small or older setups, but offers little breathing room for a new Java survival server. At the other end, choosing 16 or 32 GB does not automatically increase the number of players your CPU can handle.
Player count is only part of the picture
Ten players building one village and ten players exploring in opposite directions are different workloads. So are ten quiet bases and ten bases full of machines. Here is where the extra work comes from.
Players spread across the world
Everyone heading off in a different direction means more separate areas to keep loaded. A group building together shares more of that work.
View and simulation distance
View distance controls the world data sent to players. Simulation distance controls how far away entities update. Start modestly, then test changes.
Mods, plugins and extra worlds
Count what the add-ons do, not just how many you installed. A small command plugin and an extra world do not ask the same things of a server.
Farms and active machinery
The factory has to run as well as fit in memory. More RAM does not make its processing cost disappear.
World size on disk is different from RAM usage. A 10 GB world does not need 10 GB of memory simply because the saved files are that size. Loaded chunks and active data determine the live workload.
A modpack changes the starting point
For a substantial pack and a small group, investigate 8 to 12 GB or more as a starting range. A light pack may need less. A world that has been growing for months may need more. Check the server requirements for the exact pack and version before choosing.
- Find the server recommendation.
Check the pack's official page or installation guide. Launcher RAM instructions are for each player's client and may differ from server requirements.
- Match the loader and version.
Use the server pack for the Minecraft release and Forge, Fabric or NeoForge version the author specifies. Resource needs can change between releases.
- Test an ordinary busy session.
Include exploration, separate bases and the machines your group uses. A freshly started empty server is not representative of an established world.
More RAM helps if RAM is the problem
At 20 ticks per second, the server has 50 milliseconds to finish each tick. If the work keeps taking longer, the game slows down. Giving that work more storage space does not automatically make it finish sooner.
Look for out of memory errors, a confirmed container memory kill, or heavy garbage collection with a nearly full heap. Check the allocation and investigate possible leaks.
If ticks are slow but memory has room, profile the plugins, entities and loaded chunks before buying a larger memory allocation.
Healthy tick times plus high ping calls for a connection check. If just one player has low FPS, look at their device and settings. Their shaders are not running on your server.
A profiler such as spark can show where a busy server spends its time. Save a report while the problem is happening, not after everybody has logged off.
A quick check during your busiest session
- Watch container memory in your hosting panel.
Look at peak usage with your usual group online. Compare it with the plan limit, and keep the console logs if the server stops unexpectedly.
- Check heap usage and tick performance together.
With spark installed and the appropriate permission, run
/spark tpsin game to check tick performance. Follow spark's documentation for a profile and memory inspection. In the panel console, omit the leading slash. - Check what happens after garbage collection.
A rising and falling memory graph is often Java doing its job. What matters is whether pressure stays high after collection and whether performance suffers.
- Change one thing, then compare.
Adjust a demanding setting, resolve an expensive plugin or increase the allocation if measurements support it. Repeat a similar session so the comparison means something.
Keep a small record. Note your Minecraft and pack versions, online player count, peak container memory and tick performance. That is more useful than a rule such as “one gigabyte per ten players.”
Your Java heap is not your whole allocation
The -Xmx startup option caps Java's heap. Java also uses memory outside the heap, so a plan with 8 GB of container memory should not automatically use -Xmx8G.
Paper's shared hosting guidance suggests leaving roughly 1,000 to 1,500 MB outside the heap and gives a 6,500 MB heap as an example for an 8 GB allocation. The right headroom depends on the workload and the host's limits. On a VPS, also reserve memory for the operating system and any other services.
Illustration only. Follow your host's startup configuration; avoid changing managed flags blindly.
Minecraft server RAM, answered
Can I get away with 2 GB?
For some older versions or very small setups, yes. For a new Java survival world, I would look at 4 GB first. It gives you more room for world generation and Java overhead. Check the exact version you plan to run.
My world is 10 GB. Do I need 10 GB of RAM?
No. That is the size of the saved files on disk. The server loads the chunks and data it currently needs, not the entire world at once.
Should Xmx match the RAM on my plan?
Not unless your host explicitly allows extra memory for overhead. Xmx caps the Java heap, but the process uses memory outside it too. Follow your host's startup settings and leave that room available.
Sources & useful links
The ranges above are our starting suggestions. These references explain the settings and measurements behind them.
- PaperMC: Java memory allocation and overhead
- PaperMC: view distance and simulation distance
- spark: the Minecraft tick loop
- spark: commands and performance inspection
Published October 4, 2026. Guidance for Java Edition; pack requirements and real usage take priority over generic estimates.
Keep reading
Still unsure what your world needs?
Send us the pack or Minecraft version and how many friends will be online. We can help you pick a starting point.