A Minecraft server is one of the few workloads that punishes under-provisioning immediately: the world keeps loading, chunks stay in memory, and a single greedy plugin or a badly sized heap turns every player’s session into a stutter loop. Running it on a Windows-based server rather than a shared game panel gives you direct control over Java flags, world storage, and firewall rules — but only if you size the machine honestly. This guide covers the numbers that matter.
The advice below targets a vanilla or lightly modded Java Edition server on Windows Server 2019/2022 or Windows 10/11 Pro. Bedrock server (bedrock_server.exe) has a different memory curve and is not the focus here, though the tipping table at the end applies to both.
How Much RAM a Minecraft Server Actually Needs
Minecraft’s memory use scales with the number of loaded chunks, not the number of players directly. A player walking through unexplored terrain forces chunk generation, which is the single biggest memory and CPU spike. As a rule of thumb: 2 GB handles 2–4 players in a lightly explored world; 4 GB is comfortable for 8–12; 6–8 GB covers 15–25 players plus a few plugins; and modpacks usually start at 6 GB for 2–4 players because each mod preloads classes.
Do not simply give the server “all the RAM.” Leaving at least 1–2 GB to the operating system prevents the Windows page file from thrashing during chunk generation. On a VPS with 8 GB total, a Java heap of 6 GB is usually the sweet spot; on 16 GB, allocate 10–12 GB to the server and leave the rest for the OS, antivirus exclusions, and the JVM’s own off-heap buffers.
Choosing the Right Java Runtime and Flags
Minecraft 1.17 and newer perform noticeably better on a modern JDK. Install a current LTS build (Java 17 or 21) rather than the legacy Java 8 that many old tutorials recommend. The two flags that matter most are the heap ceiling and the garbage collector: -Xmx sets the maximum heap, and pairing G1GC with a target pause time keeps ticks smooth under load.
A realistic start command for an 8 GB VPS looks like: java -Xms4G -Xmx6G -XX:+UseG1GC -XX:MaxGCPauseMillis=130 -XX:+ParallelRefProcEnabled -jar server.jar nogui. Setting -Xms and -Xmx to the same value (or close) avoids the JVM repeatedly growing and shrinking the heap, which shows up as periodic lag spikes in /tps output.
Storage: Why NVMe Changes Chunk Loading
World saves are read and written constantly, and chunk generation in an unexplored area is IO-heavy. On a spinning disk or a throttled SATA SSD, a burst of world generation can stall the whole server thread. A VPS with NVMe storage removes that bottleneck for modest player counts, and it also shortens the “Saving world…” freeze when an admin runs /save-all.
Keep the world directory on the fastest volume available. If the VPS has a separate data disk, put world/, world_nether/ and world_the_end/ there and leave the OS on its own volume. Back the world folder up on a schedule using Task Scheduler plus a simple PowerShell copy, so a corrupted region file never means a lost build.
Network, Ports, and Firewall Configuration
Java Edition listens on TCP 25565 by default. In Windows Defender Firewall, create an inbound rule for that port rather than disabling the firewall entirely — a “turned-off firewall” VPS is the fastest route to becoming part of a botnet. If you plan to let Bedrock clients join too, open UDP 19132 separately.
For administration, avoid exposing RDP directly to the internet. Restrict Remote Desktop to your own IP at the firewall, and manage the server through remote console or an RDP gateway instead. This is the same hardening principle used for any Windows server workload, and it matters more here because game servers are scanned constantly for weak RDP logins.
Sizing Player Slots from Realistic Data
Plugin-heavy servers should budget about 250–400 MB of heap per concurrent player once view-distance exceeds 8 chunks. Setting view-distance=10 and simulation-distance=8 in server.properties cuts memory pressure dramatically compared with the defaults while remaining visually fine for most players.
A practical sizing table for a Windows VPS: 2 vCPU / 4 GB for a friends server of up to 6 players; 4 vCPU / 8 GB for 12–20 players with light plugins; 6–8 vCPU / 16 GB for 25+ players or a modest modpack. Going below 2 vCPU causes tick lag the moment two players explore in different directions.
Monitoring Ticks, RAM, and Restarts
Watch /tps (ticks per second). Anything sustained below 20 means the server cannot keep up, and the usual culprits are too small a heap, an aggressive redstone build, or a plugin generating entities in an unloaded chunk. Memory should hover well under the -Xmx ceiling; if it sits near the maximum and the GC logs show constant collection, raise the ceiling or lower the view distance.
Schedule a nightly restart with Task Scheduler or a scheduled PowerShell job, issuing /save-all first and killing the Java process 30 seconds later. A fresh process clears accumulated entity and chunk leaks that even a healthy server builds up over days of uptime.
A Repeatable Setup Checklist
Install a current JDK, download the vanilla or Paper server jar, accept the EULA, set -Xms/-Xmx with G1GC flags, tune view-distance, open only TCP 25565, lock RDP to your IP, and automate a nightly save-and-restart. That sequence takes a Windows VPS from blank to a stable, low-latency Minecraft world in under an hour — and keeps it stable as your player count grows.
Plugins, Backups, and Avoiding Disaster
Every plugin is code running inside your server’s heap, and some of the most popular ones leak memory or spawn tasks that never terminate. Install plugins one at a time, watch /tps and process memory for a day, and remove anything that pushes memory steadily upward without settling. A backup taken before each change is worth more than any profiler.
Automate world backups with a PowerShell script that stops the save, copies the region folders to a timestamped archive, and restarts the save. Rotate to keep two weeks of daily archives plus a monthly full copy stored off the VPS. When a region file corrupts — and eventually one will — a ten-minute restore beats a lost build every time.
