Minecraft: Java Edition Server Requirements Calculator

Minecraft Java Edition server requirements explained

Unlike most multiplayer games, a Minecraft server's hardware needs are driven less by player count and more by world activity — loaded chunks, ticking entities, redstone, and how fast players move through unexplored terrain. Here is what each resource actually does.

RAM

The official server documentation notes a single player adds only about 50-100 MB of memory on its own, with the practical figure rising when players travel quickly (boats, rails, elytra) and force rapid chunk loading. A vanilla or Paper server therefore needs surprisingly little: roughly a 1-2 GB base plus headroom, comfortably handling 10 players in 4 GB and 25 players in 6 GB.

• Vanilla / Paper / Purpur: 2 GB base + ~150 MB per active player. Paper-family forks use 20-30% less than vanilla.
• Light/medium modpacks (Forge/Fabric/NeoForge): 6-8 GB base before any players join.
• Heavy modpacks (RLCraft, All The Mods, Pixelmon, Create): 10-16 GB, and RAM rarely cures the lag — see CPU.

Critically, more RAM is not always better. Over-allocating (e.g. 16 GB to a small vanilla server) gives the garbage collector huge heaps to sweep, producing longer stop-the-world pauses and visible stutter. Right-size the heap and use proper GC flags instead.

CPU

This is the number that matters most. The vanilla server — and standard Paper/Spigot — runs the world tick on a single main thread. That thread handles entity AI, redstone, block updates, and most chunk work, and it is a hard ceiling: a 5 GHz dual-core will outperform a 3 GHz 16-core for ordinary gameplay. Practical guidance:

• Up to ~10 players, vanilla: 3.5 GHz+ modern core.
• 10-25 players: 3.5-4.0 GHz+ with strong single-thread IPC.
• 25-50+ players or heavy redstone/mob farms: 4.0 GHz+.

Extra cores help only for parallel chunk generation, GC threads, running multiple worlds/instances, or special builds like Folia (a Paper fork that splits ticking across regions). Modded servers are far more CPU-intensive — most modded lag is CPU, not RAM.

Storage

A new install plus a small world fits in a few GB; the server files alone need around 2 GB. Disk usage then grows with explored area and backups, not directly with players: a busy 20-player vanilla world over six months typically reaches 10-15 GB. Budget ~5 GB base plus room for backups. Use an SSD/NVMe — fast random reads keep chunk loading smooth and avoid the exploration stutter that spinning disks cause.

Network bandwidth

Minecraft is light on bandwidth: roughly 0.1-0.3 Mbps upload per active player under normal play, rising during heavy chunk streaming when players move fast. A 30-player self-hosted server wants 15-20+ Mbps upload, and on a home connection that uplink is shared with everyone else in the house. Latency and consistent upload matter more than raw throughput — a starved or jittery uplink makes the server miss ticks. Monthly egress works out to only a few GB per active player.

Optimizing a Minecraft Java server

Because the main tick loop is single-threaded, most real-world performance gains come from reducing how much the server has to tick rather than buying more hardware.

Use a performance fork

Switching from the vanilla JAR to Paper (or Purpur for even more tuning options) typically cuts CPU load and RAM use substantially while staying plugin-compatible. For modded servers, performance mods like Lithium (general tick optimization) and FerriteCore (memory reduction) are widely used.

Tune distances

Two settings in server.properties dominate load:

• view-distance — how many chunks are sent to clients. Dropping from the default 10 to 8 (or 6 on busy servers) sharply reduces chunk generation and bandwidth.
• simulation-distance — how far entities, redstone, and crops actually tick. Set this lower than view-distance, around 4-6, for large savings with little visible impact.

Limit entities

Reducing entity activation range (so distant mobs stop ticking) can reclaim a large share of tick time on populated worlds. Cap mob spawns per chunk, and watch for mob/item farms and entity-cramming spots that quietly eat the tick budget.

Tune the JVM

Use Aikar's flags — a well-known G1GC configuration tuned for Minecraft's allocation pattern. They keep garbage-collection pauses short and steady, avoiding the multi-second freezes that come from default JVM settings on a large heap. Pair them with a right-sized -Xmx/-Xms (set both equal) rather than an oversized heap.

Pre-generate and split

Pre-generating the world (e.g. with Chunky) moves expensive terrain generation off peak playtime. For very large communities, run multiple smaller server instances behind a proxy (Velocity or BungeeCord) instead of one giant world — this is the only practical way past the single-thread ceiling without exotic forks.

What to look for in a host for Minecraft Java

The single most important spec is CPU clock speed and single-thread performance, not advertised core count or total RAM. Many budget plans sell large RAM amounts on slow, oversubscribed CPUs — a poor fit for a game bottlenecked on one fast core. Look for hosts that publish their CPU model and clock speed and that limit how many servers share a physical core.

Other things that matter for this game specifically:

• NVMe/SSD storage — chunk loading is disk-sensitive; spinning disks cause exploration stutter.
• RAM headroom and a clear upgrade path — so you can grow from vanilla to plugins or a modpack without migrating.
• One-click / instant modpack and Jar switching — easy installation of Paper, Purpur, Forge, Fabric, and curated modpacks saves real setup time.
• Automated backups and easy restores — worlds are irreplaceable; check backup frequency, retention, and whether restores are self-service.
• Full console and file access (FTP/SFTP and a web console) — you will edit server.properties, drop in plugins/mods, and read logs.
• Low-latency location — pick a datacenter region near most of your players; ping affects perceived combat and block-break feel.
• DDoS protection — public Minecraft servers are common attack targets, so always-on mitigation is valuable.
• Custom JVM flag support — the ability to set Aikar's flags and your own heap size is a sign of a flexible host.

Whether you self-host on a home machine, rent a VPS, or use managed game hosting, weigh control versus convenience: a VPS gives full control but you manage the OS, security, and JVM yourself; managed hosting trades some control for instant setup and support.

CPU note: Vanilla and most plugin servers (Paper/Spigot) are single-thread-bound for the main game-tick loop, so per-core clock speed and single-thread IPC matter far more than core count. Aim for 3.5 GHz+ for small servers and 4.0 GHz+ (modern architecture) for 25+ players or heavy redstone/mob farms. A fast 4-core beats a slow 16-core. Extra cores only help with parallel chunk generation, GC threads, and multiple separate worlds/servers. Folia (a Paper fork) and a few mods spread ticking across cores, but the standard server does not.

Numbers are for the official server JAR running on a headless Linux box. Vanilla and Paper/Spigot are cheap on RAM; Paper/Purpur typically use 20-30% less than vanilla at the same player count. Modded servers (Forge/Fabric/NeoForge with large modpacks like RLCraft, All The Mods, Pixelmon, Create) need roughly 2-3x the RAM and far more CPU. Storage grows mainly with explored world area, not player count, so the per-player figure is a loose proxy; backups multiply disk needs. Allocating too much RAM (e.g. 16 GB+ for a small vanilla server) can actually hurt by causing long garbage-collection pauses — right-size it. A single server process realistically handles up to ~100-150 players on strong hardware before single-thread tick time becomes the bottleneck; larger networks use multiple instances behind a proxy (Velocity/BungeeCord).