How much RAM does a modded Minecraft server need?

By Niko Catarino

Updated 2 October 2026

This guide covers Minecraft Java Edition. Test Bedrock workloads separately.

Find the author’s server recommendation for the exact pack release you plan to run. Use that as a starting point, then test your saved world. Counting players or mods cannot establish the RAM requirement: five people exploring different dimensions create a different test from five people sharing a build site.

Fill in the workload record before increasing your allocation. Associate every result with its pack, game, loader and Java versions. For the installation baseline, follow the custom-modpack preparation guide.

Define the workload you will compare

Preserve a world backup. Write down the service memory limit, Java heap settings, CPU allocation and host sharing constraints you can verify. Test the pack instead of inferring its fit from advertised clocks or slots.

Include the activities your players expect:

Session	What to repeat	Evidence to save
Startup and joining	Launch the pack and have players connect	Memory use, startup/mod errors and joining outcome
Existing bases	Operate the active entities, farms and machines	Pauses, tick time, active chunks and gameplay outcome
Exploration	Visit new terrain with the expected player spread	Generation work, tick spikes and memory pressure
Persistence	Stop/start, then revisit the saves and actions	Repeat performance and world/player state

Scroll to see all columns →

Hold the world state, observation duration, settings and player activity comparable between runs. If the workload changes too, the result cannot isolate your setting change.

Compare tick time with the reported symptom

At the usual rate of 20 ticks per second, the average budget is 50 milliseconds per tick. TPS measures the rate the server delivers, and MSPT measures tick duration. Keep spike context plus median and 95th-percentile values where the profiler supplies them. Short stalls can disappear inside an average. spark’s TPS and MSPT explanation.

Note who experiences the issue and whether server tick time rises when it occurs. Low client FPS, slow simulation and connection delay need separate evidence.

Paper bundles spark from 1.21. Other server implementations need a compatible profiler for their game version and loader. A Bukkit plugin cannot stand in for a Fabric mod. Read the installation instructions before installing a package. Paper profiling reference.

On a server with compatible spark, capture the affected activity with:

/spark tps
/spark health show --memory
/spark profiler start

Reproduce the activity while the profiler runs. Finish that session by saving a local profile:

/spark profiler stop --save-to-file

Add the returned file path to the workload record. Run commands with the required server permissions. A default stop/viewer flow can upload the result; the documented file option retains it for review before you share it. spark command reference.

Inspect the sampled work inside the selected thread. Frame percentages describe that thread’s time, rather than total host CPU. A root showing 100% is expected. Expand costly frames and compare them with the recorded activity and tick durations. Viewer reference.

Check both heap pressure and service memory

Java uses -Xmx for the maximum heap and -Xms for its initial and minimum size. Thread stacks and other runtime structures also consume memory outside the heap. Leave room for that process memory and any other required services within the host/container limit. Setting the heap equal to the service limit does not demonstrate that the process fits. Java 25 command reference.

Read the launch values; a panel graph does not establish them. Match heap use and garbage-collection pauses against swapping, process/container pressure and the crash log.

Save the exact out-of-memory error. Heap exhaustion, a host/container kill and an allocation failure can lead to different investigations. A heap increase without spare service memory can push the failure into another limit.

Treat extra RAM as a test when observed pressure matches the fault. Expensive tick work still needs investigation.

Test simulation distance against gameplay

Java 1.18 added the dedicated-server simulation-distance property, separating simulation from viewing. That release describes entities, blocks and fluids outside the simulation range no longer receiving their normal updates. View distance governs loading/providing chunks for viewing. Confirm the behaviour of your implementation, including per-world overrides. Mojang’s 1.18 release notes.

Record effective view-distance and simulation-distance before the edit. Preserve the settings and stop through the normal workflow. Change one value, start again and repeat the recorded session. Include a gameplay check of the farms at the new range.

Keep the measured difference on your own server. A chunk radius cannot supply a reliable RAM formula across overlapping players, dimensions, generation, chunk loaders and mod behaviour.

Use the evidence to choose a test

Recorded evidence	Next controlled test
Stalls coincide with heap pressure and GC pauses	Verify spare process/service memory, then test a suitable heap change.
Tick work remains costly without matching memory pressure	Inspect the profiled simulation, mod, machine or entity work.
Exploration coincides with spikes	Compare travel in new terrain with travel in existing terrain before selecting a generation intervention.
One player reports trouble while server tick time stays healthy	Check the client’s performance and connection.
Swapping or host/container pressure occurs	Review competing processes and the full allocation with the host.

Scroll to see all columns →

Retain the original value, changed value and repeat outcome. Accept a change after intended gameplay and performance pass. To test mod removal, use a separate copy of the world and follow the author’s saved-data requirements.

Keep outside examples in their proper scope

The owner of a Reddit server report describes falling TPS around many entities despite low reported CPU/RAM use. That supports collecting workload evidence. Its replies provide neither a benchmark for your pack nor a basis for an immediate purchase.

Take the workload record to the host

Provide your exact pack release, active settings, workload record and relevant errors. Confirm the proposed service’s resource and runtime controls, then test fit using the same workload.

Review VYKIX Minecraft hosting alongside that pack record. A slot label or RAM-per-player calculator result cannot establish acceptable operation of your world and mods.