Don't Starve Together Server Requirements Calculator

How a Don't Starve Together server actually works

A DST server is organised as a cluster. A cluster always contains exactly one master shard and any number of secondary shards. In a normal world the master shard runs the Forest (Overworld) and a single secondary shard runs the Caves. Crucially, each shard is its own running process with its own configuration and its own port. Running caves therefore means running two copies of the dedicated server at once, and your hardware budget has to cover both.

RAM

DST is remarkably memory-light. A single shard typically uses around 1 GB, and the community guidance of "1 GB of RAM available per shard plus room for the operating system" holds up well in practice. A Forest-only server runs comfortably in about 2 GB total. Once you enable caves you are running two shards, so plan for roughly 3–4 GB for a small-to-medium group. Player count adds only a small amount of memory — on the order of 100 MB per active player — because the heavy cost is the loaded world, not the individual clients. Larger 16-slot community servers are usually fine in 4–6 GB unless mods push it higher.

CPU

This is where most people go wrong. DST's simulation is essentially single-threaded per shard, so what matters is single-core speed, not how many cores you have. A fast modern core can host a full server smoothly; a slow core will stutter no matter how many of them you stack. The practical rule is one free, fast core per shard: 2 cores for a Forest-only world and 3–4 cores when caves are enabled (one each for master and caves, with headroom for the OS and Steam updates). Lag almost always shows up as CPU saturation on a single shard long before RAM becomes the bottleneck, especially with many players spread across the map or with pathfinding-heavy mobs and structures.

Storage

The game files are small. Klei lists a minimum of around 1 GB of disk space, and the dedicated server install plus a couple of world saves comfortably fits in 5 GB. Mods and a long server history add a little more, so 10 GB of SSD is a safe, future-proof allocation. An SSD is strongly preferred over spinning disk: world saves and the periodic snapshots benefit from fast, low-latency writes, and faster storage shortens the long startup time when both shards load their worlds.

Bandwidth

Network use is modest. The server ticks at 15 updates per second by default and the per-player traffic is small, so a handful of GB per player per month is a generous estimate for a typical session schedule. The bigger network concern is latency and a stable connection rather than raw throughput — players feel jitter and packet loss far more than they feel a bandwidth cap.

Mods

Mods are the main variable. Custom world-generation, extra creatures and pathfinding-heavy content increase both RAM and, more importantly, per-tick CPU cost. A heavy mod list can raise memory use by roughly half again, which is why the planner applies a modded multiplier. Always monitor your first few sessions and trim the mod list or move to faster hardware if you see stutter.

Getting the most out of a DST server

Because DST is CPU-single-thread bound, your biggest lever is fast cores. Pick hardware with high single-core performance rather than a high core count; a 16-core server with weak cores will host worse than a 4-core box with strong ones.

Keep the tick rate at its default of 15 updates per second. Raising it increases precision slightly but multiplies network traffic and CPU load, and it is only worth changing for LAN play.

When you run caves, point both shards at the same mod install directory. Sharing the directory avoids duplicating mod files on disk and cuts the startup time of the second shard. Keep your mod list lean: each pathfinding-heavy or world-gen mod adds per-tick cost to every shard that loads it.

Put world saves on an SSD. The periodic auto-saves and snapshots are write-bursty, and slow storage shows up as brief hitches during a save. Schedule restarts during quiet hours so Steam updates and a clean reload of both shards happen without interrupting players.

Finally, measure before you scale. Watch per-process CPU and RAM during your first busy session. If one shard pins a core, that shard — usually the Forest with everyone online — needs a faster core, not more RAM.

What to look for in a host

The single most important spec for Don't Starve Together is single-core CPU performance. Look for a provider that publishes its CPU model or clock speed and favours modern, high-clock chips. Because each world with caves runs two processes, confirm the plan gives you enough CPU allowance for both shards plus the operating system — effectively two fast cores' worth of work.

RAM needs are modest, so do not overpay for memory you will not use. A 3–4 GB allocation covers most caves-enabled servers; only large or heavily modded communities need 6 GB or more. Make sure the host supports running multiple shards in one cluster and exposes the cluster and shard configuration, since some panels only enable caves through a specific setting or a second process.

Prefer SSD or NVMe storage for snappy world saves, and check that Steam Workshop mods are supported with easy mod management, since mods are central to most DST communities. A nearby data-centre location keeps latency low for your players, which matters more than raw bandwidth. Finally, look for automatic updates, scheduled restarts, easy world backups and clear access to config files so you can tune max players, caves and mods yourself.

CPU note: DST is bound by single-thread CPU performance, not core count. Each shard (master and caves) runs as its own process and is effectively single-threaded, so give it 2 fast cores for a Forest-only world and 3-4 cores when caves are enabled. Clock speed and per-core IPC matter far more than total core count.

A DST world with caves runs as TWO separate server processes in one cluster: a master shard (Forest/Overworld) and a secondary shard (Caves). Budget RAM and a CPU core for EACH process. Disabling caves halves the footprint; enabling them roughly doubles it.