Minecraft Server Player Slot Scaling: How to Handle 50, 100, or 500+ Concurrent Players
# Minecraft Server Player Slot Scaling: How to Handle 50, 100, or 500+ Concurrent Players
Running a Minecraft server for a handful of friends is easy. Scaling that same server to handle 50, 100, or even 500+ concurrent players is an entirely different challenge. Without the right configuration, hardware, and architecture, your TPS will crater and players will experience rubber-banding, inventory glitches, and constant timeouts.
This guide walks through every layer of the scaling problem — from single-server config tweaks to multi-server proxy networks — so you can grow your community without sacrificing performance.
---
Understanding Why Player Count Kills Performance
Every connected player generates continuous server load:
- Chunk loading — Each player loads a radius of chunks around them. At view-distance 10, that's ~441 chunks per player.
- Entity tracking — The server must track and sync entity positions for every player within range.
- Network I/O — Packets for movement, inventory updates, and world state must be sent to every client.
- Game logic — Hunger, effects, advancements, and statistics are ticked every 1–20 ticks per player.
At 20 players these costs are manageable. At 200, they overwhelm a single server without careful tuning.
---
Phase 1: Optimizing a Single Server for Higher Player Counts
Reduce Simulation and View Distance
The single biggest win for player scaling is reducing how much world the server simulates per player.
In paper-world.yml (per-world or global):
chunks:
auto-save-interval: 6000
delay-chunk-unloads-by: 10s
In spigot.yml:
world-settings:
default:
view-distance: 6
simulation-distance: 4
Or set these directly in server.properties:
view-distance=6
simulation-distance=4
Dropping simulation distance from 10 to 4 can reduce chunk tick load by over 80%. Players rarely notice the difference in casual gameplay.
Throttle Entity Tracking in spigot.yml
world-settings:
default:
entity-tracking-range:
players: 64
animals: 32
monsters: 40
misc: 16
display: 128
entity-activation-range:
animals: 16
monsters: 24
raiders: 48
misc: 8
water: 8
villagers: 16
flying-monsters: 32
Reducing entity-tracking-range means the server sends fewer entity update packets to each player, directly cutting network and CPU overhead at scale.
Paper Async and Threading Options
In paper-global.yml:
async-chunks:
threads: -1
Setting threads to -1 lets Paper auto-tune async chunk I/O based on your CPU core count, which is critical when dozens of players are loading chunks simultaneously.
Increase Netty Thread Count
In server.properties:
network-compression-threshold=256Lowering the compression threshold reduces CPU for packet compression but can increase bandwidth. For servers with fast local networks or powerful CPUs, set this to 64. For bandwidth-limited hosts, 512 reduces CPU cost at the expense of slightly larger packets.
In your launch flags, also expose more Netty threads:
-Dio.netty.eventLoopThreads=4For 100+ player servers, set this to 8 or higher.
---
Phase 2: Moving to a Proxy Network (Velocity or BungeeCord)
Once you hit the ceiling of a single server (~100–150 players on good hardware), the next step is a proxy network. This distributes players across multiple backend servers while presenting a single IP to players.
Velocity vs. BungeeCord
Velocity (by PaperMC) is the modern choice:
- Significantly better performance than BungeeCord
- Native support for Paper, Pufferfish, and Purpur
- Modern forwarding mode bypasses legacy security issues
Enable Velocity forwarding in paper-global.yml:
proxies:
velocity:
enabled: true
online-mode: true
secret: "your-secret-here"
And in velocity.toml:
player-info-forwarding-mode = "modern"Network Topology for 500+ Players
A typical large-network layout:
[Players] → [Velocity Proxy x2 (load balanced)] → [Lobby x2]
→ [Survival x4]
→ [Minigames x8]
- Proxy nodes: Lightweight, handle routing only. 2–4 vCPUs, 2GB RAM each.
- Backend servers: Heavy lifting. Dedicate one JVM process per game mode.
- Lobby servers: Keep these fast — they're the first impression. Cap them at 50–80 players each.
Redis for Cross-Server Synchronization
For features like cross-server chat, friend lists, or global bans, use RedisBungee or a plugin like LuckPerms with a shared MySQL/MariaDB backend. Redis handles pub/sub messaging between backend servers with sub-millisecond latency.
---
Phase 3: Hardware and OS-Level Scaling
CPU Is King
Minecraft is largely single-threaded (the main game tick). Prioritize high single-core clock speed over core count for backend servers:
- Good: AMD Ryzen 9 7950X, Intel Core i9-13900K
- Avoid: High-core-count server CPUs with low base clocks (Xeon E5 era)
For proxy nodes, multi-core matters more since Velocity is genuinely multi-threaded.
NVMe Storage for Chunk I/O
At 100+ players, chunk read/write can saturate slow storage. NVMe SSDs reduce chunk load times by 5–10x compared to HDDs, directly reducing the queue depth that causes lag spikes when players move through unexplored terrain.
Monitor Before You Tune
Before blindly tweaking configs, you need real data. Tools like [PulseNode](https://pulsenode.tech) give you AI-powered, real-time visibility into TPS, player count trends, memory pressure, and performance anomalies — so you can see exactly when and why your server struggles as player counts rise. This makes it far easier to identify whether your bottleneck is chunk loading, entity processing, or network I/O.
---
Quick Reference: Config Targets by Player Count
| Players | view-distance | simulation-distance | Architecture |
|---------|--------------|--------------------|--------------|
| 1–30 | 10 | 8 | Single server |
| 30–80 | 7 | 5 | Single server, tuned |
| 80–150 | 5–6 | 4 | Single server, optimized |
| 150–500 | 5 | 3–4 | Velocity proxy + 3–5 backends |
| 500+ | 4–5 | 3 | Full network, Redis, DB cluster |
---
Final Thoughts
Scaling a Minecraft server isn't just about throwing more RAM at the problem. It's about understanding where your bottlenecks are — chunk loading, entity tracking, network I/O, or plugin overhead — and addressing each layer systematically.
Start with single-server optimizations, monitor your actual TPS and memory curves, and only add proxy complexity when you genuinely need it. Most servers under 150 players can be made very stable with proper config tuning alone.
When you're ready to grow, [PulseNode](https://pulsenode.tech) helps you track performance across all your backend nodes in one place, so scaling decisions are based on real data rather than guesswork.