The software you load
Plugins and mods can hold data before the first player joins. Their behavior matters more than a count alone; follow the pack author’s requirements.
Free server tool / Memory planning
Size a starting point around your players, software, and add-ons. See the estimate, leave some headroom, and choose a plan with confidence.
Step 1 of 3 / Minecraft memory planner
Pick your software first. We’ll tailor the questions to what you run.
Paper / Purpur · 20 concurrent players
01 / Make sense of the number
The runtime, add-ons and active world all need room. This breakdown shows how your inputs shape the estimate, before choosing a plan.
20 concurrent players · 10-chunk view distance
Planning assumptions, not measured heap allocations. Actual usage varies with the pack, loaded chunks, entities and server configuration.
Plugins and mods can hold data before the first player joins. Their behavior matters more than a count alone; follow the pack author’s requirements.
Players exploring separate areas load more terrain than players building together. View distance, entities and chunk loaders change that picture.
Plan memory also has to cover Java and other process overhead. The plan limit is not a suggested -Xmx value.
02 / Compare the software
Compare estimates for 20 players using your settings. Select a row to change your software; each engine counts only the add-ons it supports.
Solid bar: workload estimate. Muted extension: headroom and rounding. Values are targets before matching a plan. A supplied pack minimum applies only to your selected mod loader.
Illustration / Tick duration
03 / Look beyond memory
A server targeting 20 TPS has 50 milliseconds per tick. Expensive entities, generation, plugin work or blocking I/O can use that budget even with memory available.
See what a Spark capture reveals →A high heap snapshot can drop after collection. Look at pauses over time before deciding to resize the heap; a bigger allocation is not automatically smoother.
Collector, Java version and flags affect memory behavior. There is no universal “32 GB cliff” that applies to every runtime configuration.
Capture during the issue, change one setting and repeat with similar player activity. Keep both reports so you can compare the evidence.
Learn more: Spark’s TPS and MSPT guide.
A little help before you launch
The assumptions behind your estimate, and what to measure next.
Have a question of your own? Our team is here to help.
Ask our team (opens in a new tab)Or explore the guidesThe estimate combines a software baseline, concurrent players, relevant add-ons, view distance, and optional crossplay. It starts with the same workload model as our plan builder, respects a modpack minimum when supplied, and adds your chosen headroom (15% by default) before matching a tier. Simulation distance and world activity inform performance advice rather than a fixed memory surcharge. These are planning assumptions, not measurements or benchmark guarantees.
Use the pack author’s minimum when it is higher. Mod counts cannot capture every content pack, script, or generation system. Profile a representative session and leave room for peak use.
Only when memory pressure is contributing to the problem. Expensive world ticks, plugins, chunk generation, and CPU contention need their own investigation. Adding memory alone does not make that work finish faster.
Minecraft storage is subject to our Fair Usage Policy, including the 150 GB soft limit and increases on request. Contact us before approaching that limit.
More free server tools
Design a colourful two-line server message with a live preview. Copy server.properties or MiniMessage output with RGB gradients.
Turn a capture into a verdict, evidence and next steps. Inspect tick windows, memory and attributed add-on work.
Estimate the chunks in your world area, use measured rates for time and storage, and build Chunky commands.