Why trust this guide
By Victus Cloud · Reviewed by Victus Cloud · No individual author claimed. Verify paths, versions, and backups before changing a live service.
Evidence-led, product-agnostic
Start with the workload, not a magic RAM number
Minecraft capacity cannot be reduced to players multiplied by a fixed amount of memory. Edition, server version, software, world size, view distance, simulation distance, plugins, mods, farms, generated chunks, and player behavior all change the workload. Ten players exploring in different directions can create more work than a larger group standing in one built-up area. A heavily modded server may retain far more objects and code in memory than a small Paper server. Treat any sizing chart as a starting hypothesis, then measure the real server.
Before comparing plans, write down the maximum simultaneous players you actually expect during the next month, the software you will run, the number and size of worlds, and whether you use a curated modpack. Also decide what experience matters: a private server can tolerate an occasional generation pause, while a public server may need conservative view distances and scheduled pre-generation. Do not buy for a hoped-for peak hundreds of players away. Choose enough room to test safely, confirm that upgrading is possible, and revisit the decision when evidence changes.
Victus plan details are the source of truth
CPU allocation, memory, storage, backups, locations, and panel controls can vary by product and plan. Check the current plan and panel before ordering or changing settings. This guide does not promise dedicated CPU time, a particular processor, or an included backup feature.
What RAM does—and what more RAM does not do
RAM holds the Java heap, loaded chunks, entities, plugin or mod state, caches, and other runtime data. Too little memory commonly appears as long garbage-collection pauses, an out-of-memory error, or the process being terminated by a limit. More memory can prevent that pressure, but it does not make a saturated main thread execute ticks faster. Allocating an enormous heap can also lengthen some collection cycles and leave too little memory for the JVM, native libraries, file cache, and the host environment.
| Workload shape | Reasonable test allocation | What to validate |
|---|---|---|
| Small current-version vanilla/Paper server for a few friends | Start around 3–4 GiB | Peak heap use, chunk generation pauses, plugin footprint |
| Moderate Paper server with several plugins and active exploration | Start around 4–8 GiB | Peak players, multiple worlds, garbage-collection behavior |
| Curated lightweight modpack | Start around 6–10 GiB | Pack publisher guidance, client/server mod list, loaded dimensions |
| Large modpack or complex public server | Use pack guidance, then load-test | Sustained heap, CPU tick time, storage and backup size |
These ranges deliberately overlap because labels such as ‘small’ and ‘modded’ hide important differences. A pack publisher may specify a minimum; that minimum is normally a compatibility floor, not proof that the server will handle your player count. Leave operating headroom rather than setting the Java maximum equal to every byte shown on a plan. On a managed game panel, use its memory/startup controls rather than editing an unknown launch command, and verify whether the panel sets Java flags automatically.
Why Minecraft CPU selection is mostly about tick work
Much of a Minecraft server's world simulation is coordinated by a main tick thread. Other work can use additional threads, including networking, chunk tasks, garbage collection, and some plugin or mod operations, but many cores do not automatically rescue a slow tick. A plan with more CPU allowance can help only when the server can use it and the underlying scheduling provides it. Clock labels and processor names alone are not reliable cross-generation benchmarks, and a virtual CPU is not necessarily an exclusive physical core.
- Prefer evidence about sustained tick time over a marketing CPU label.
- Ask whether CPU resources are shared, limited, burstable, or dedicated if the product page does not say; do not assume.
- Keep view distance, simulation distance, entity counts, redstone, and chunk generation in the capacity conversation.
- For proxy networks, size each backend for its own workload instead of adding all memory into one server.
- Check storage space and I/O behavior too: world saves, logs, maps, and backups are part of the system.
Build a repeatable baseline
Create a backup before testing. Record the server version, Java version, software build, startup flags, plugin/mod list, world sizes, view and simulation distances, and the time window. Test with representative behavior: teleport through existing regions, generate new terrain, visit farms, and run scheduled jobs. Synthetic players do not reproduce every interaction, but an unchanged test route makes before-and-after comparisons much more useful than asking whether the server ‘feels faster.’
version
mspt
tpsCommand availability depends on server software and permissions. On recent Paper builds, mspt can expose milliseconds per tick; other software may not provide it. Twenty ticks per second has a 50 ms tick budget. Short spikes happen, so inspect sustained patterns and percentiles rather than one reading. If the server runs in a managed panel, panel CPU percentages may be relative to its allocation and may not map directly to whole-machine utilization.
Measure memory without chasing the sawtooth
Java heap usage normally rises as objects are allocated and falls when garbage collection runs. That sawtooth is healthy by itself. Warning signs are usage returning to an increasingly high floor, very frequent long pauses, allocation failures, or a crash report naming memory. Observe through several normal peaks and at least one save/restart cycle. Do not treat the panel showing high allocated memory as proof of a leak: committed heap, used heap, resident memory, and a panel limit are different quantities.
- Establish a quiet baseline after startup and spawn loading.
- Measure during the real peak with the normal plugin/mod set.
- Change one variable, such as simulation distance or a single plugin, at a time.
- Repeat the same activity and compare tick time, pauses, and used memory.
- Keep the change only if it helps without breaking gameplay; document the result.
A defensible buying and upgrade decision
Choose enough RAM for the observed live set plus headroom, and enough CPU allocation to keep representative tick work below budget. If memory is comfortable but ticks are slow, adding RAM is unlikely to fix the cause; profile plugins, entities, chunks, and generation. If ticks are healthy but the process reaches its memory limit, investigate the heap and then test a modest memory increase. If both are constrained, reduce workload first so an upgrade does not merely postpone the same failure.
Finally, plan for reversibility. Confirm how an upgrade affects billing, whether a downgrade is possible, and whether changing plan can restart or move a service. Keep a tested independent backup before any change. Victus offerings may evolve, so current panel and checkout information outrank examples in this article. The goal is not the largest plan; it is a measured server with enough headroom and a clear next action when demand grows.