TL;DR / Summary: A whitelisted server for a handful of friends needs about two gigabytes of RAM, a backup, and a restart schedule. It does not need the biggest plan on the page, and the network latency matters more than the CPU.
Sizing for a small whitelist
Minecraft’s memory use scales with loaded chunks, world size, and plugins. Two to four friends in a small world load far fewer chunks than a public server, and the requirement drops accordingly.
Two gigabytes is workable for a vanilla world with a handful of players. Add one gigabyte per major plugin suite or per doubling of the player count.
A whitelist also reduces the surface for attacks and the load from random joins, which is a genuine resource saving rather than only a security measure.
CPU, disk, and the metric that matters
Single-thread performance matters more than core count. The game loop is largely one thread, so a fast two-core machine beats a slow eight-core one.
Disk matters mainly for world saves and startup. An SSD reduces save stutter, and the world folder should be on fast storage rather than a network mount.
Reasonable baseline
- CPU: two fast cores, prioritising clock speed
- RAM: 2–4 GB, with the heap set explicitly
- Disk: 20–40 GB SSD, world saves included
- Bandwidth: modest; a dozen players use very little
- Location: the region closest to most players
Location is the one item people skip and regret. A hundred milliseconds of latency changes how the game feels more than any specification.
Configuring the server sensibly
Set the memory heap explicitly and leave headroom for the operating system. A server that consumes all available memory starts swapping, and swapping is worse than running out.
Reduce view distance. Most small servers run a distance the players cannot usefully see, and the chunk loading costs real CPU.
Every chunk you load is a chunk the server has to tick forever.
Disable features nobody uses: telemetry, unused world generators, and plugin modules that came bundled and were never configured.
Whitelist and access
Enforce the whitelist from the first launch, not after the world exists. A griefed spawn is the fastest way to end a small server.
Give each friend their own account rather than a shared login. Shared accounts make it impossible to trace a problem and impossible to revoke one person’s access.
Keep operator permissions for yourself only. A single mistaken command from an operator can remove terrain that took weeks to build.
Backups and restarts
Copy the world folder on a schedule while the server is running, but take a full stop-backup-start once a day. Live copies can be inconsistent.
Keep at least three backups: one recent, one a week old, one a month old. World corruption is rare and catastrophic, and the weekly copy is what saves the build.
Restart on a schedule to release memory. A nightly restart at a quiet hour prevents most gradual memory growth from becoming a crash.
When to move to a bigger plan
Watch memory pressure and tick rate rather than player complaints. A server that struggles at ten players will not be fixed by a faster CPU alone.
If the world has grown large and the disk is full, the answer is storage, not compute. If tick rate drops with a small world, the answer is CPU or fewer plugins.
For plans with explicit CPU models and RAM, VPS hosting for game servers lists the specifications clearly enough to choose by clock speed rather than by price alone. Pick the region first, then the smallest plan that fits, and upgrade only when the measurements ask for it.
Mods, plugins, and the real cost
Each plugin adds memory overhead and startup time. A server with twenty plugins needs more RAM than the player count alone would suggest.
Modded worlds are heavier again, because the game loads additional assets and generates new terrain types. Plan for double the memory of a vanilla server of the same size.
Test after each addition. A single plugin that leaks memory will look like a general capacity problem within a week.
Add one thing, run for a day, then add the next.
Remove plugins that were installed and never configured. They consume resources and nobody remembers why they exist.
Keep a list of what is installed and what it does. Future-you will not remember, and a support forum will ask.
Managing the whitelist over time
Add players one at a time and remove them when they stop playing. A whitelist that only grows becomes a public server with extra steps.
Review it quarterly against who actually logged in. Names nobody recognises are the ones to remove.
A whitelist is a maintenance task, not a one-time setting.
Keep the list in version control. Restoring a world without the matching list produces a server nobody can join.
