7 Days to Die Dedicated Server: Hardware and Settings Guide

7 Days to Die is one of the most CPU-intensive survival games to self-host. Its Unity-based dedicated server simulates a fully destructible voxel world, entity AI for hundreds of zombies, and real-time physics for structural collapse — all of which stress the CPU far more than most game servers. This guide covers the hardware requirements, server configuration, and optimization settings needed to run a stable 7 Days to Die server on dedicated hardware.

Before you order hardware, compare dedicated server plans on our homepage to find a configuration that meets the CPU and RAM requirements below.

Hardware Requirements by Player Count

7 Days to Die uses a single-threaded main loop with auxiliary threads for chunk generation, entity AI, and network I/O. The game’s simulation is CPU-bound: the server’s tick rate (60 per second) must process zombie pathfinding, block damage, loot respawns, and player physics. When the CPU cannot keep up, the server desynchronizes and players experience rubber-banding, delayed block breaking, and zombie teleportation.

Player Count	CPU	RAM	Storage	Network
1–8 players	4 cores @ 3.5+ GHz	8–12 GB	256 GB NVMe	100 Mbps
8–16 players	6–8 cores @ 4.0+ GHz	12–16 GB	512 GB NVMe	250 Mbps
16–32 players	8–12 cores @ 4.5+ GHz	16–32 GB	1 TB NVMe	1 Gbps
32+ players	12–16 cores @ 4.5+ GHz	32–64 GB	2 TB NVMe	1 Gbps

CPU: The Primary Bottleneck

The 7 Days to Die dedicated server is single-thread bound. The main simulation loop — zombie AI, block physics, loot management, and player interactions — runs on one core. High-clock-speed CPUs are essential. An Intel Core i7-14700K or AMD Ryzen 7 7800X3D (with its large L3 cache) are ideal choices. The X3D cache helps with the game’s procedural world generation and block state lookups.

Do not use Xeon or EPYC processors for 7 Days to Die unless they have boost clocks above 4.5 GHz. The server will struggle to maintain 60 FPS simulation on lower-clocked server CPUs, especially during horde nights when zombie counts spike to 50–100+ per player.

RAM: World Size and Player Count Drive Consumption

7 Days to Die keeps the entire loaded world region in memory. A standard 8K map (8,192×8,192 blocks) uses approximately 4–6 GB of RAM for the world data alone. Each player adds 150–300 MB for their view distance, inventory, and active chunks. Zombie pathfinding data adds another 200–500 MB during horde nights.

For 16 players on a standard map, allocate 12–16 GB. For 32 players on a large map (10K or 12K), allocate 24–32 GB. Leave at least 2 GB free for the OS and file system cache.

Server Configuration: serverconfig.xml

The server configuration file (serverconfig.xml) controls all settings. Here are the parameters that most affect performance:

Parameter	Default	Recommended	Impact
ServerMaxPlayerCount	8	Set to your target	Controls max concurrent players
ServerMaxWorldViewDistance	10	6–8	Lower = less CPU load per player
ServerMaxAllowedViewDistance	12	8–10	Cap on client-side view distance
BlockDamageMax	5000	5000–10000	Higher = more block damage per swing
BloodMoonEnemyCount	8	4–8	Zombies per player during horde night
BloodMoonFrequency	7	7–14	Days between horde nights
ZombieFeralSense	false	false	True = constant zombie AI overhead
SaveGameLimit	5	3–5	Max backup saves kept
DynamicMeshEnabled	true	true	Helps chunk loading
MaxSpawnedZombies	60	40–60	Total zombies in world at once

Essential Optimization Steps

1. Pre-generate the World

7 Days to Die generates chunks on demand as players explore. This on-the-fly generation causes CPU spikes and disk I/O. Pre-generate the world using the -generateworld command-line flag before opening the server to players. A 6K map takes 20–40 minutes to pre-generate on a modern CPU. An 8K map takes 60–90 minutes.

2. Run as a Dedicated Server (Not from the Client)

Always run the dedicated server binary (7DaysToDieServer.exe on Windows or 7DaysToDieServer.x86_64 on Linux), not the game client with the “Host” option. The dedicated server uses a separate code path that is optimized for headless operation and consumes significantly less CPU and RAM.

3. Configure Linux for Game Server Performance

On Linux, apply these kernel optimizations:

• Set the CPU governor to performance: cpupower frequency-set -g performance
• Disable transparent huge pages: echo never > /sys/kernel/mm/transparent_hugepage/enabled
• Increase UDP buffer sizes: sysctl -w net.core.rmem_max=134217728; sysctl -w net.core.wmem_max=134217728
• Set swappiness low: sysctl -w vm.swappiness=10

4. Schedule Regular Restarts and World Saves

7 Days to Die servers accumulate memory over time due to the Unity engine memory allocator. Restarting the server every 12–24 hours clears leaked memory. Use the saveworld command via the console before restarting, or configure SaveGameLimit to keep the last 3–5 saves.

Monitoring and Troubleshooting

Common issues and their fixes:

• Server desync during horde night: CPU is saturated. Reduce BloodMoonEnemyCount and MaxSpawnedZombies. Also lower ServerMaxWorldViewDistance to 6.
• Out of memory crashes: Allocate more RAM or reduce ServerMaxWorldViewDistance. Check with htop or free -h.
• Player connection timeouts: Check firewall rules. 7 Days to Die uses UDP port 26900 by default (plus 26901–26902 for Steam).
• Slow chunk loading: Ensure you pre-generated the world. If you did, check that the disk is NVMe and not SATA.

Summary

7 Days to Die is one of the most demanding game servers to self-host, requiring high-clock CPUs, ample RAM, and NVMe storage. The key to a stable server is pre-generating the world, tuning the horde night settings, and running on a dedicated hardware that matches your player count. With the right configuration, 7 Days to Die provides a smooth survival experience for 8–32 players without the horde-night lag that plagues underpowered servers.

Find dedicated server hardware for 7 Days to Die hosting on our comparison page to match your community’s needs.