Sizing a 100-Slot Game Server Network: CPU, RAM, and Bandwidth Budgets Per Instance

A 100-slot game server network is not one server doing 100 players’ worth of work. It is usually 4 to 8 separate instances, each with its own tick loop, its own world state, and its own memory footprint, stacked onto one machine behind a shared uplink. That changes the sizing math completely. You are not sizing for peak player count; you are sizing for the sum of per-instance overhead, plus enough headroom for the worst instance at its worst moment.

This is a hardware budgeting guide, not a game-specific setup guide. If you already know which games you are running, use the numbers below to pick a machine class and validate it against our dedicated server comparison table before you order.

The Four Budgets You Are Actually Spending

Every multi-instance network draws from four finite pools. Whichever one runs out first sets your real capacity, and it is rarely the one people plan for.

• Single-core CPU headroom. Most game server binaries are effectively one to two threads deep for the simulation loop. Eight instances means eight cores that must each have low-latency access, not eight threads squeezed onto four cores.
• RAM. Each instance has a baseline (the binary, assets, engine overhead) plus a growth term tied to players and loaded chunks. The baseline is what kills you, because it is multiplied by instance count.
• Memory bandwidth. ARC and XenForo-style memory access patterns are not the issue; loaded world data is. More instances on fewer memory channels means more contention on the same DDR5 sticks.
• Uplink throughput and packet rate. Throughput is easy. Packet rate (packets per second, pps) is the constraint that actually disconnects you, because a provider rate-limits pps long before you saturate a 1 Gbps port.

Per-Instance RAM Baselines by Genre

These are measured resident-set baselines for an empty, freshly started instance with a default world loaded. They exclude player-driven growth, which is covered in the next section.

Instance type	Idle RSS baseline	Per-player growth	Practical ceiling
Minecraft (vanilla/Paper, 4 GB heap)	1.2–1.6 GB	15–40 MB	60–90 players
Valheim	1.0–1.4 GB	25–50 MB	16–30 players
Palworld	3.5–5.0 GB	45–70 MB	24–32 players
ARK: Survival Ascended	6.0–9.0 GB	90–160 MB	20–40 players
Rust (wiped map)	6.5–10.0 GB	80–140 MB	60–100 players
Enshrouded	2.5–4.0 GB	40–80 MB	8–16 players

Add the panel. Pterodactyl, AMP, or Pelican will sit at 300–900 MB depending on instance count and whether it uses a per-instance Docker container. Budget 1 GB for the panel and 0.5 to 1 GB for the operating system, database, and monitoring agents.

A Worked 100-Slot Mix

Suppose the network is four Minecraft instances at 25 slots, one Palworld instance at 8 slots, and one Rust instance at 50 slots. Assuming realistic mid-life memory use, not idle baselines:

Workload	Instances	RAM at load	Sim cores needed
Minecraft @ 25 slots	4	4 × 2.8 GB = 11.2 GB	4
Palworld @ 8 slots	1	4.5 GB	1
Rust @ 50 slots	1	11.0 GB	2
Panel + OS + DB	—	2.5 GB	1
Total	6	29.2 GB	8

With a 30% growth cushion and JVM/garbage-collection overshoot, that lands on 48 GB RAM and 12 to 16 physical cores. The extra four cores over the eight simulation threads are not waste; they are there so OS scheduling, backup compression, and a single misbehaving instance do not steal cycles from a tick loop. Ordering a 12-core / 48 GB (or 16-core / 64 GB) class machine is the right call, and it leaves room for one more Minecraft instance later.

Bandwidth: Throughput Is the Wrong Number

Bandwidth planning for game servers is dominated by packet rate, not bitrate. Small, frequent UDP packets mean the packets-per-second ceiling arrives first. A typical tick loop sends 20 to 64 updates per second per player, and each update is 40 to 200 bytes depending on entity density.

Concurrent players	Tick rate	Avg pps (in+out)	Sustained throughput
25	20 Hz	1,000–1,500	3–5 Mbps
25	64 Hz	3,200–4,000	10–16 Mbps
100 (across all instances)	mixed	8,000–14,000	25–50 Mbps

A 100-slot network at mixed tick rates typically peaks under 60 Mbps. What matters is that your port handles 15,000 pps without dropping. Ask any provider two questions before ordering: is the port a dedicated 1 Gbps or a shared one, and is there a pps filter or flood-protection threshold that will start dropping legitimate UDP during a raid night? A 1 Gbps port with a 10,000 pps cap is worse than a 200 Mbps port with no pps cap.

CPU: What to Actually Order

You want high all-core boost with strong single-core IPC, not the largest core count available. A 32-core part that drops to 2.4 GHz under load will lose to a 16-core part sustaining 4.2 GHz on eight loaded threads, because your bottleneck is tick loop latency, not aggregate throughput.

• Sweet spot for 100 slots: 12–16 physical cores at 3.5 GHz+ all-core boost, or 8 performance cores plus 8 efficiency cores if you pin simulation threads explicitly.
• Disable SMT/hyperthreading for the simulation cores if you see tick jitter. Two logical threads on one physical core can interfere; leaving HT off for game instances costs nothing here.
• Leave two cores unpinned for the panel, backups, and the OS. Multi-instance machines lose more time to scheduler contention than to raw CPU shortage.

Storage and I/O

Each game instance needs its own world directory, and world saves are write-heavy at autosave intervals. NVMe is the right choice, but the reason is not raw bandwidth — it is latency under concurrent writes. When six instances autosave in the same 30-second window, a SATA SSD queues writes and tick times spike. If you are running ARK or Rust with large maps, check that per-instance working sets fit comfortably; a 6-instance network wants at least 1 TB usable, in RAID 1 or RAID 10 rather than RAID 0.

Sizing Checklist Before You Order

1. Sum idle baselines for every instance, then add per-player growth at your target slot count.
2. Add 30% for growth, plus 2.5 GB for panel, OS, and monitoring.
3. Count simulation threads, then add 50% for headroom — that is your core count.
4. Estimate pps, not Mbps. Confirm the provider has no low pps cap on your port.
5. Confirm NVMe with RAID 1 or 10, and at least 1 TB usable.
6. Verify you can add RAM or a second NVMe later without re-racking the machine.

Run those six numbers against real hardware specs in our dedicated server comparison table and you will order the right machine the first time instead of the second.