7 Days to Die Server Requirements Calculator
7 Days to Die is one of the most demanding survival games to self-host, but not for the reason most people expect. Its dedicated server is bound far more by single-thread CPU speed and your map/mod choices than by raw RAM or bandwidth. Get the CPU and storage right and a modest box will happily run a community server; get them wrong and even 64 GB of RAM won't stop horde-night lag.
Use the calculator below to estimate RAM, CPU, storage, and bandwidth for your server, then read on for accurate, version-aware requirements, optimization tips, and ready-made tier recommendations for everything from a 4-player co-op map to a 30-player crossplay community.
7 Days to Die dedicated server requirements
7 Days to Die runs a standalone dedicated server (available on Steam and via SteamCMD for Windows and Linux) that is separate from the game client. The numbers below assume you run the dedicated server on its own - running the server and a game client on the same machine roughly doubles RAM needs and competes for the all-important CPU thread. They are also version-aware: as of mid-2026 the current stable branch is V2.x (Survival Revival, with V2.6 shipping in April 2026), which kept the v1.0-era memory optimizations but added bigger hordes and tougher AI.
RAM
The official minimum is 8 GB, and RAM is driven more by map size and mods than by player count. A tiny co-op server is comfortable on 8 GB; the officially recommended 8-player community server sits around 12 GB. The per-player cost itself is small - on the order of 0.1 GB of base server memory per connected player - but loaded chunks, spawned entities, and steady world growth push real-world usage higher over time.
Map size is a major factor. On the v1.0 engine, a pregenerated 4k map uses roughly 1.8 GB while a 10k map uses around 2.4 GB; maps larger than 8k climb further. (For context, Alpha 21 was hungrier at roughly 2-3.5 GB for the same maps before later optimizations.) Most vanilla servers never need more than 16 GB. 32 GB is only justified for very large maps, large crossplay populations, or heavy overhaul mods. Note the long-standing memory creep: usage rises the longer a save runs, which is why scheduled restarts are standard practice.
CPU
This is the requirement that trips most people up. The core simulation loop - world ticks, zombie AI, and pathfinding - runs primarily on a single thread. That makes high single-core clock speed the dominant factor, not core count. Target a CPU with 4.0+ GHz base and 4.5+ GHz boost. Two cores can run a basic server, four cores is a good baseline, and six is plenty; additional cores mainly help the OS, disk I/O, and RCON rather than game performance. Blood moon (horde) nights are the true stress test: hundreds of pathfinding zombies pile onto one core, so always size for that peak, not average load.
Storage
The server install plus a fresh world fits in roughly 15-20 GB, so 20 GB is a bare minimum; allocate 30-50 GB for comfortable room, and more for modded or long-running worlds (a rough guide is ~10 GB per 100 hours of active play). Storage type matters more than capacity: use NVMe SSD for the save directory so auto-saves and chunk loads don't stall the simulation tick. World saves grow steadily as players explore and modify terrain, so expect the on-disk footprint to creep up on long-running servers.
Network / bandwidth
Bandwidth is the lightest requirement. Each player consumes roughly 50-100 KB/s of upload, so even a 16-player server only needs a few Mbps of stable upstream - easily a few tens of GB of egress per active player per month. What matters far more than throughput is consistent, low latency (ideally under 50 ms to your players) and low jitter. A nearby data center beats a faster but distant connection.
Vanilla vs. modded
Vanilla servers are well-behaved: 8-16 GB RAM and a fast CPU cover almost any realistic population. Heavy overhaul mods such as Darkness Falls, Undead Legacy, and War of the Walkers change the picture - they can add 4-8 GB of RAM and roughly double total needs, while also adding CPU work to every tick and growing the on-disk footprint. On a modded server, plan for more RAM, more storage, and fewer concurrent players than vanilla on the same hardware.
Optimizing a 7 Days to Die dedicated server
The single biggest lever is protecting the main simulation thread. Because the world tick and AI pathfinding run primarily on one core, your goal is to keep that core below ~80% utilization, especially during blood moon nights - which grew larger in the V2.x updates. Edit serverconfig.xml with these high-impact settings:
- MaxSpawnedZombies and MaxSpawnedAnimals: lower these gradually on busy servers - every active AI entity adds pathfinding work to the tick thread.
- BloodMoonEnemyCount / blood-moon party size: trim this if horde nights cause stuttering or rubber-banding. This is the most common cause of \"good CPU but still lags\" reports.
- ServerMaxAllowedViewDistance: reducing view distance shrinks the number of loaded chunks and entities each client streams.
- SaveDataLimit and auto-save interval: keep auto-saves on a sane interval (roughly 5-10 minutes) so disk writes don't stall the tick - and put the save directory on NVMe.
Hardware and OS tuning:
- Use NVMe storage exclusively for the save directory; chunk loading and saves are latency-sensitive.
- Set a high-performance power plan and pin the server process to your fastest cores at high (not realtime) priority.
- Leave 20-30% single-core headroom reserved for horde nights and large parties - do not size to average load.
- Restart busy servers every 4-8 hours. The engine accumulates game objects and memory over a long-running save (a known memory creep), and a scheduled restart resets that creep.
For modded servers, audit your modlets: a single poorly written script can dominate the tick. Remove the worst offenders rather than chasing micro-optimizations, and cap player count lower than you would on vanilla, since mods add both RAM pressure and per-tick CPU cost. Finally, monitor disk latency and single-core CPU during peak hours - those two metrics predict felt performance better than total CPU or RAM graphs.
What to look for in a host for 7 Days to Die
Because 7 Days to Die is bound by single-thread CPU speed, the most important question to ask any host is the actual CPU model and clock speed of the machine your server will run on. A high advertised RAM number means little if the cores are slow or oversold shared cores; look for hosts that publish their CPU clock speeds (4.0 GHz and up) and are transparent about whether cores are dedicated or shared.
Storage type matters next. The save directory benefits enormously from NVMe SSDs, since auto-saves and chunk loading can otherwise stall the simulation tick. Prefer hosts that use NVMe rather than SATA SSD or spinning disks, and check how much disk you actually get - long-running and modded worlds grow well past a fresh install.
For multiplayer reliability, prioritize:
- RAM headroom: enough to cover world growth and any mods, not just day-one usage - long-running saves grow over time and the engine has a known memory creep.
- Location and latency: a data center close to your player base keeps ping low; published test IPs let you measure before committing.
- DDoS protection: public servers are common targets, so always-on filtering is valuable.
- Easy mod and config access: one-click or simple install for overhaul mods and modlets, plus FTP/SFTP and direct access to serverconfig.xml.
- Console/RCON and automated restarts: the engine benefits from periodic restarts (every 4-8 hours for busy servers), so scheduled-restart tooling helps fight memory creep.
- Backups: automatic, restorable world backups protect against corruption.
Finally, confirm you can scale RAM or move to a faster CPU tier without rebuilding, since requirements rise with player count, map size, mods, and each major game version.
CPU note: Heavily single-thread-bound: the core simulation/world tick and zombie AI pathfinding run primarily on one thread, so high single-core clock speed (4.0+ GHz base, 4.5+ GHz boost) matters far more than core count. The V2.x (Survival Revival) updates offloaded some work to extra threads, but the main tick is still effectively one core, and bigger Blood Moons since 2.0 raise that single-core load. Horde/blood-moon nights are the real stress test - watch single-core utilization, not total CPU. 4-6 fast cores are plenty; extra cores only help background tasks (chunk I/O, RCON, OS).
Numbers are for the standalone dedicated server (not host+client on one box, which roughly doubles RAM and competes for the critical CPU thread). The official minimum RAM is 8 GB; The Fun Pimps recommend ~8 players, with 16-20 achievable on strong single-thread hardware. 25-50 is possible but the single-threaded tick and blood-moon spawns make consistent performance hard past ~16-24. World/map size drives RAM more than player count: on the v1.0 engine a 4k map uses ~1.8 GB vs ~2.4 GB for a 10k map; the older Alpha 21 was hungrier (~2-3.5 GB for the same maps), and maps over 8k plus long-running saves keep climbing as more game objects are created. The per-player cost itself is small (~0.1 GB of base server memory each); the 0.4 GB/player figure here is a real-world buffer for loaded chunks, spawned entities and world growth. Vanilla rarely needs more than 16 GB; heavy overhaul mods (Darkness Falls, War of the Walkers, Undead Legacy) can add 4-8 GB and roughly double total RAM. Bandwidth is light (~50-100 KB/s upload per player). 7DTD has a long-standing memory creep - usage climbs the longer a save runs - so scheduled restarts every 4-8 hours are standard. Version note: as of mid-2026 the current stable branch is V2.x (Survival Revival, V2.6 released April 2026); it kept the v1.0-era memory optimizations but added bigger hordes and tougher AI, so size for the peak.