Capacity planning
How to choose a game server size without guessing
A practical way to estimate player capacity, account for mods and world activity, and choose a plan you can verify after launch.
A community roster is not the same as the number of people who play at once. Good sizing starts with the busiest real session you expect, then adds the work created by the game, world, plugins, mods and backups.
Three orders to carry forward
- Use simultaneous players—not total members—as the baseline.
- Treat mods, plugins, world generation and entity-heavy builds as extra workload.
- Choose a measurable starting point, watch the panel during a real peak, then adjust.
Start with the busiest session
Count the people likely to be connected at the same time during your busiest normal event. A Discord with 80 members may only put 12 players online together. Planning for all 80 can waste money; planning for the average of five can fail on event night.
Write down a normal peak and an event peak. The normal peak should guide the starting plan. The event peak tells you when to watch closely or temporarily move up if the storefront supports plan changes.
- Normal simultaneous-player estimate
- Largest scheduled event in the next 30 days
- Whether spectators, bots or proxy connections also occupy slots
Account for what the world is doing
Two servers with the same player count can behave very differently. Fresh terrain generation, automation, large farms, dense entity counts, scripted addons, map changes and modpacks can all add work. A mostly vanilla private world is a different workload from a heavily modified public community.
List the features you consider essential before buying. This is more useful than choosing a plan from a generic RAM-per-player rule because the game loop and installed content determine where pressure appears.
Put the server near the crew
Capacity cannot fix a poor network route. Choose a location that is reasonable for the group, especially the players who join competitive or timing-sensitive games. Ask where the regular players live and test from more than one connection when possible.
RadarHost currently lists Chicago, Illinois, United States as its server location. That can be a practical starting point for groups concentrated in eastern Canada and the northeastern United States, but every player's route is different and should be tested rather than promised.
Verify during a real peak
After launch, observe the server during the busiest real session—not while it is empty. Note player count, world activity, console warnings, restart behavior and whether scheduled work overlaps with play. Keep one change log so you can connect a new plugin, mod or map to any new problem.
If the experience degrades, reproduce the issue before upgrading blindly. A broken plugin, runaway entity count or network problem may not be solved by buying a larger plan.
- Record the peak connected-player count
- Check console output for repeated warnings or failures
- Confirm backups and restarts complete outside peak play
- Change one major variable at a time and record the result