Player Capacity Optimization

The 7 Days to Die dedicated server defaults to 8 concurrent players, but the cap is just a configurable property — there's no hardcoded ceiling. Whether you can sustain 16, 24, or more players is a hardware-and-tuning question, not a license question. This guide covers the property to change, the related settings that scale alongside player count, and the hardware reality of pushing past the defaults.

The One Property to Change

In serverconfig.xml:

<property name="ServerMaxPlayerCount" value="8" />

The default is 8. Increase it to whatever number you intend to support. The server will accept connections up to that count and refuse the next one with "server full". The number itself is just a gate — it doesn't allocate anything proactively. The actual cost shows up at runtime as more players load chunks, more entities exist, and the worst-case Blood Moon spawn count grows.

Related Settings That Scale With Capacity

Raising ServerMaxPlayerCount alone gives you nothing. The settings below interact and need to be tuned together.

PropertyDefaultWhy it matters at scale
ServerMaxPlayerCount8The hard upper bound. Set first, then tune the rest.
ServerMaxAllowedViewDistance12 (range 6–12)Controls how far each client can ask the server to render around them. Each chunk loaded is RAM and CPU. Lowering this from 12 to 8 or 9 on busy servers is the single biggest scaling win — the in-XML comment notes "high impact on memory usage and performance".
MaxSpawnedZombies64Hard cap across the map. Default ties exactly to BloodMoonEnemyCount × 8 players; increase as your roster grows but be aware each additional zombie has steady CPU cost.
BloodMoonEnemyCount8Per-player concurrent cap during Blood Moons. See Balancing the Blood Moon for the layered-cap interaction.
LandClaimCount1One claim per player. With more players, "all the good claim spots are taken" emerges as a social problem; consider raising to 2 if your map is big.

The view-distance setting is the underrated lever. Going from 12 to 8 reduces the rendered chunk area to ~44% of its prior size — RAM and CPU drop accordingly, and most players can't tell the difference in practice.

Hardware Reality

There's no published official "this many players needs this much CPU" table from The Fun Pimps, and benchmarks vary by mod set, view distance, and player behavior. What you can plan for:

  • Single-thread CPU is the bottleneck. The Unity simulation tick (zombie AI, physics, networking) runs predominantly on a single core. A modern CPU with high single-thread performance (Zen 4/5, Intel 13th gen+, etc.) outperforms older many-core server CPUs at this workload, period. Boost-clock matters more than core count.
  • RAM scales roughly linearly with players + view distance. A safe budget is the server itself plus 0.5–1 GB per concurrent player at default view distance, plus headroom for the OS. Heavy overhauls double those numbers. If you trim view distance, you can push capacity for the same RAM.
  • Bandwidth is rarely the bottleneck. Per-player upstream is small (typically tens of kbps active, low hundreds of kbps in extreme bursts). Even a 100 Mbps uplink handles dozens of players easily. If you're seeing rubber-banding, look at CPU and tick rate first, not raw bandwidth.
  • Disk I/O matters more than people expect. Save ticks write region files; on spinning rust, this stalls the simulation tick. Use SSD for the save folder.
  • Avoid oversold VPSes. A "4 vCPU" plan that shares physical cores with other tenants will bottleneck under sustained load. Dedicated CPU plans (e.g. AWS dedicated, OVH dedicated, etc.) give the consistency this workload needs.

Practical Capacity Recommendations

These are starting points to test against, not absolute thresholds. Monitor RAM, CPU tick time, and player feedback after each adjustment.

Target capacitySuggested settingsHardware floor
4–8 players (defaults work)Defaults4 cores modern CPU, 8 GB RAM, SSD
9–16 playersServerMaxPlayerCount=16, ServerMaxAllowedViewDistance=10, MaxSpawnedZombies=806 cores high single-thread, 16 GB RAM
17–32 playersServerMaxPlayerCount=32, ServerMaxAllowedViewDistance=8, MaxSpawnedZombies=100, BloodMoonEnemyCount=48+ cores high single-thread, 32 GB RAM, dedicated CPU host
32+ playersSame as above; consider running multiple smaller servers instead — at this point you're past the practical sweet spot of one Unity simulation thread.This is unusual for 7D2D; verify the use case before throwing hardware at it.

Diagnosing a Server That's Choking

Symptoms when you're past your capacity envelope:

  • Rubber-banding when zombies spawn (CPU ran out of tick budget).
  • Chunk-load stalls when players move (disk I/O or RAM pressure).
  • Save-tick pauses visible in journalctl or the log (slow disk).
  • Mass disconnect at Blood Moon start (the 22:00 spawn-burst exceeds tick budget).

The diagnostic flow:

  1. Run mem and chunkcache over telnet to see live load (see Admin Command Deep Dive).
  2. Check the log for "long simulation" warnings (see Server Log Masterclass).
  3. Drop ServerMaxAllowedViewDistance by 2 first — usually the biggest single-step relief.
  4. If still struggling, lower BloodMoonEnemyCount per player.
  5. Last resort: drop ServerMaxPlayerCount to whatever your hardware actually sustains, and tell the truth in your community announcement.