A Don’t Starve Together dedicated server can run on modest hardware, but Klei’s published figures are compatibility floors, not player-count guarantees. The official baseline is a 1.7 GHz-or-faster processor, at least 1 GB of RAM and at least 1 GB of drive space. For a dependable world, size resources per shard: a Forest-only cluster has one shard, while a normal Forest-and-Caves cluster has two. Plan roughly one available CPU core and 1 GB of available memory per shard, then add capacity for the operating system, mods, growing saves and any game client sharing the machine.
What are the official Don’t Starve Together dedicated-server requirements?
Klei Entertainment lists the following minimums for its dedicated-server software (Klei Entertainment, 2025):
| Resource | Published minimum | How to interpret it |
|---|---|---|
| Processor | 1.7 GHz or better | A compatibility floor; Klei does not specify a required core count. |
| Memory | 1 GB RAM | Base software minimum, not a guarantee for a particular number of players, mods or world age. |
| Storage | 1 GB of hard-drive space | Space for the basic installation only; saves, logs, updates, mods and backups need additional room. |
| Graphics | Not specified for the dedicated server | The server is headless game-logic software, so client GPU requirements do not apply. |
The same Klei page labels Windows Vista/7/8 and Ubuntu 12.10 or newer for the server. Those labels are legacy, so check that the current server build and your chosen operating-system release are supported before deployment. The dedicated-server reference documents Windows and Linux x86/x86_64 builds rather than a universal platform target.
How much RAM does a DST dedicated server need?
Use 1 GB of available RAM per shard as a practical planning rule, not the 1 GB total in Klei’s minimum specification. A shard is an independent simulation process, and memory use can rise as the world gets older or more players and mods are added.
Forest-only worlds
A Forest-only cluster has one shard. Reserve about 1 GB for that process, then add memory for the operating system, monitoring, panel software, backups and other services. A machine with only 1 GB total therefore leaves almost no headroom and is likely to become unstable under real use.
Forest plus Caves
A conventional Forest-and-Caves cluster has two shards. Start with about 2 GB available to the game processes, plus the operating system and everything else on the host. This is a planning allowance, not a hard cap: older worlds, larger concurrent populations and mod collections can push usage higher.
Running the server and client together
If you play on the same computer that hosts the server, the game client and operating system compete with the shards. The practical performance guidance says most quad-core local machines with at least 4 GB of RAM can handle a light shared setup. Treat that as a starting point for an lightly modded, lightly populated world, not a universal recommendation; a busy cluster or a large mod list needs more memory.
What CPU does a Don’t Starve Together server need?
The useful rule is one fast, available CPU core per shard. The performance guidance notes that shards do not multi-thread, so sustained per-core speed matters more than buying a processor with many slow cores.
Core planning by cluster
- One-shard Forest: keep one core available to the simulation, with spare capacity for the operating system and other processes.
- Two-shard Forest plus Caves: make two cores available, ideally on a processor with enough additional capacity that background work cannot interrupt either shard.
Klei’s 1.7 GHz figure is the official floor, not a performance target. A modern CPU that can sustain its advertised speed under load is a safer choice than an older chip that briefly reaches a higher boost clock. Because no official formula maps player slots, mods or world age to a guaranteed CPU requirement, test the exact workload you intend to host.
Do Caves need extra CPU and RAM?
Yes. Caves normally add a second shard, so they create a second simulation that needs its own CPU time and memory allowance. They are not merely an optional map loaded inside the Forest process.
For a two-shard cluster, reserve one available core and about 1 GB of available RAM for each shard before counting the operating system, services or a locally running client. If the host is also doing backups, voice chat, web administration or other work, leave additional CPU and memory headroom rather than assigning every resource to the game.
Does a dedicated server need a graphics card?
No gaming GPU is required for the dedicated server. It runs headlessly and provides game logic; players’ computers render the game. Klei’s requirements page lists graphics hardware for Windows, macOS and Linux clients, but does not list a GPU requirement for the dedicated-server entry, so do not apply those client figures to a headless host.
How much storage should you allocate?
Klei’s floor is 1 GB of free drive space, but a production host should reserve substantially more. The additional capacity is consumed by cluster files, rolling saves, server logs, downloaded mods, updates and local backups. The exact amount depends on how many worlds and backup generations you retain.
SSD versus HDD
An SSD can make initial startup and routine autosaves feel quicker. The practical guidance describes the improvement during ordinary simulation as limited, so an SSD is a responsiveness upgrade rather than a mandatory requirement. An HDD can run the server when budget or capacity makes it preferable; prioritize reliable free space and a backup plan.
Should you host locally or rent a VPS?
Choose a local machine when you already have suitable hardware, can keep it online and want to avoid a recurring bill. A VPS is useful when you need a datacenter location close to distant players, predictable availability or a host that can be upgraded without replacing your computer. Compare the following rather than looking only at advertised core counts:
| Decision factor | Local host | VPS |
|---|---|---|
| CPU available to shards | Depends on what your computer is doing while hosting; reserve cores for the client if you play there. | Check whether the provider supplies sustained CPU or a shared/credit model that can throttle long workloads. |
| RAM after overhead | Physical RAM must cover the OS, server, client and other applications. | Verify guaranteed RAM and whether management software consumes part of the allocation. |
| Network | Upload stability, router configuration and your distance from players determine latency. | Datacenter geography can reduce latency, but measure the route to your actual players. |
| Storage and backups | You control disk type, capacity and backup schedule. | Check disk capacity, backup policy, restore process and whether backups cost extra. |
| Cost and upgrades | Higher upfront hardware cost but no monthly server rental. | Recurring monthly cost; confirm the price and upgrade path before choosing a plan. |
The performance guidance recommends a stable connection with good throughput. A VPS with CPU-credit limits may look adequate in short tests yet throttle during sustained simulation, so ask specifically about continuous CPU availability.
How do you install the dedicated server?
The dedicated-server reference documents a SteamCMD installation using app ID 343050. It also states that the server software can be installed without owning the game, while online hosting requires ownership of Don’t Starve Together.
- Prepare a supported Windows or Linux x86/x86_64 host and create a dedicated directory for server files, saves and logs.
- Install SteamCMD, sign in as appropriate for your deployment, and select the directory for the server files.
- Run the SteamCMD app-install command for app ID
343050, then verify that the download completes without disk-space errors. - Configure the cluster and shard settings for Forest, and add Caves if you need a second shard. Keep saves and configuration outside temporary directories so they survive updates.
- Start the server, watch the console and logs for both shards, and connect from a client you own to verify that the world saves and that remote players can reach it.
Exact launch scripts and configuration keys vary with the operating system and the current server reference. Follow the version-specific documentation for those files rather than copying a script written for an older release.
How can you size a host for your actual player group?
Use a workload-first process instead of converting Klei’s minimums directly into a player-slot promise.
- Define the cluster: record whether you will run Forest only or Forest plus Caves, how many concurrent players you expect, and which mods are essential.
- Count shards: assign one simulation allowance to each shard. Caves generally changes the count from one to two.
- Budget memory: start with about 1 GB available per shard, then add the operating system, administration tools, backups and any local game client. Leave room for growth as the world ages.
- Budget CPU: reserve one physically available, fast-enough core per shard. Avoid filling the remaining cores with unrelated jobs during play.
- Reserve storage: exceed the 1 GB software floor by enough to retain saves, logs, mod downloads, updates and backups without running the filesystem nearly full.
- Validate the network: test upload stability and latency from the locations where your players live. A powerful host cannot compensate for an unreliable uplink.
- Load-test safely: invite the intended number of players, use the planned mod set and exercise both shards. Watch per-core CPU, available memory, disk space and save times before opening the server permanently.
- Keep an upgrade path: decide in advance whether you will add RAM, move to faster storage, migrate to a larger machine or change VPS size if monitoring shows sustained pressure.
What are the common sizing mistakes and fixes?
- Treating 1 GB as a complete host specification: the figure covers the published baseline, not the OS and a growing world. Move to a host with additional available RAM and monitor usage.
- Counting total cores instead of per-shard performance: many slow or heavily shared cores can still produce simulation delays. Ensure a fast core remains available to every shard.
- Forgetting the Caves shard: a Forest-and-Caves cluster needs a second CPU and memory allowance. Recalculate the budget before enabling it.
- Filling the disk with logs and saves: reserve capacity and rotate or archive files according to your retention policy. A full filesystem can prevent saves and updates.
- Assuming a GPU will solve server lag: the headless process does not use a gaming GPU for rendering. Spend first on sustained CPU, RAM and network quality.
- Choosing a throttled VPS: CPU-credit plans may slow after sustained use. Confirm the provider’s continuous-performance policy and test under a realistic session.
- Testing only a fresh world: memory demand can increase with world age and player activity. Repeat tests after the world has accumulated the entities, structures and saves your group normally creates.
What should you monitor after launch?
Record CPU usage per shard, available RAM, disk free space, save duration and connection symptoms during peak play. A short spike is less concerning than a resource staying near its limit for an entire session. Keep dated logs of player count, mod changes and world age so you can relate a slowdown to a workload change rather than guessing.
Frequently Asked Questions
Can I run a DST dedicated server on 1 GB of RAM?
It may start because 1 GB is Klei’s published memory minimum, but that amount leaves little or no room for the operating system and background services. It should be treated as a compatibility test, not a reliable capacity target for a persistent multiplayer world.
How many players can the minimum hardware support?
No official conversion from the minimum CPU, RAM and storage figures to a guaranteed player count is published. Capacity depends on shard count, world age, mods, concurrent activity and what else the host is running, so measure the complete workload you plan to use.
Can I host the server on an ARM single-board computer?
The dedicated-server reference lists Windows and Linux x86/x86_64 builds, not an ARM build. An ARM device therefore requires explicit compatibility confirmation or an appropriate x86-compatible environment before you rely on it for hosting.
Is a fast internet download speed enough for hosting?
No. Stable upload performance, low latency to your players and consistent routing matter as much as headline download speed. Test from the players’ regions and investigate packet loss or latency changes during busy periods.
When should I move from local hosting to a VPS?
Consider moving when your home connection is unreliable, the machine cannot stay online, players are geographically distant, or you need simpler upgrades and backups. Compare sustained CPU policy, guaranteed RAM, location, backup and restore options, and the recurring price before migrating.