Valheim Dedicated Server CPU and RAM Sizing for Large Builds

Valheim’s dedicated server is single-threaded where it counts. The game loop that simulates physics, AI, building stability, and ZDO updates runs on one core, and no amount of extra sockets will speed it up. That makes sizing unusually simple to get wrong: people buy 16 slow cores and get worse performance than a 4-core box with high single-thread clock. This is a concrete sizing model for large builds — 5,000 to 50,000 instances, 10 to 40 players — with the RAM and CPU numbers that hold up in practice.

How Valheim Actually Uses CPU

Three things dominate server CPU time: ZDO (zone data object) networking and serialisation, physics stepping for every placed piece and tamed creature, and the periodic save, which serialises the world to disk. Instances are the cost driver. A player’s starter base of 400 pieces is trivial. A completed castle with terraforming, 8,000 instances, 40 tamed boars, and a portal hub is where tick time collapses. In practice, a 20-player server with 30,000 total instances runs about 55–65% of one core at 20 TPS; the same world at 60,000 instances with 30 players approaches 95–100% of a core and starts dropping below 18 TPS during combat.

What matters for purchase decisions is single-thread performance, not core count. A modern 5.0–5.7 GHz boost core (Ryzen 7 7800X3D, Ryzen 9 7950X, Core i7-14700K) delivers roughly 30–40% more Valheim tick throughput than a 3.4 GHz Xeon Silver core at the same instance count, because the bottleneck is per-instruction latency rather than parallelism. For Valheim specifically, four fast cores beat sixteen slow ones every time.

World profile	Players	Instances	Save size	RAM (RSS)	CPU of one fast core
Small co-op base	2–5	3,000–6,000	15–30 MB	2.5–3 GB	15–25%
Mid server, few bases	8–12	12,000–20,000	40–80 MB	3.5–4.5 GB	35–50%
Large builds	15–20	25,000–40,000	90–180 MB	5–6.5 GB	55–75%
Mega-build / city	20–30	50,000–80,000	200–400 MB	7–9 GB	85–100%+

RAM: Why 4 GB Is a Trap for Large Builds

The Valheim server binary idles around 1.8–2.2 GB and grows with loaded zone data, not with player count directly. Each active zone region contributes instance data and physics structures; as players fan out across a map, more zones stay resident. A rule that holds across dozens of community servers: base 2 GB + roughly 60–90 MB per 1,000 instances held in memory + 200 MB headroom for the save operation. At 40,000 instances that lands near 5.5 GB, which is why 4 GB plans stutter the moment players build seriously.

Valheim also does not garbage-collect like a managed runtime — it is Unity/Mono, and memory fragmentation accumulates over long uptimes. Servers that run 14 days without restart commonly show RSS 40–60% above their post-restart baseline. Plan a daily restart at a low-population hour (04:00 local) and expect RSS to drop back to baseline each time. If it does not drop, you have a leak or a mod allocating unboundedly.

The Save Event Is the Real Spike

Every 20 minutes by default (saveinterval), Valheim writes the world: .db and .fwl files plus the per-player files. On a 300 MB world over NVMe that takes 1.5–3 seconds, during which the main thread stalls and all players see a hitch. On a SATA SSD it can take 6–10 seconds. On a shared spinning disk — still sold as “dedicated” by some budget hosts — 20+ seconds of freeze is normal and players will notice.

Storage sizing follows from this: budget 5× the live save size for rotations and backups, and keep at least 20 GB free so the write never contends with the filesystem nearing full. A 400 MB world with hourly snapshots retained for seven days needs about 400 MB × 24 × 7 ≈ 67 GB if you keep every snapshot, so either compress (Valheim saves compress to roughly 40–50% with zstd) or thin the retention.

Mod Load and Tick Budget

BepInEx mods are the biggest uncontrolled variable. Server-side mods that add per-tick work — custom AI, additional creatures, resource nodes that scan the world, or frequently-updated network objects — can double tick cost. A practical ceiling: keep total per-tick mod overhead under 40% of a single core. If a vanilla world uses 60% of a core and mods push it to 95%, you have no headroom for a combat night with 20 players and 60 tamed animals in one spot.

Measure rather than guess. Enable -logfile and watch for the “Time” line in server logs; anything consistently above 50 ms means TPS is dropping below 20. Pair that with pidstat -u 1 on the host to separate game-thread load from system noise. When CPU is the limit, the fix is a faster core, not more cores — the details of which bare-metal CPUs deliver that are covered under the high-clock dedicated server configurations used for game hosting.

Bandwidth and Player Count

Valheim’s network load is modest by modern standards: roughly 30–60 kbps per player steady-state, with bursts to 200–400 kbps during large base loads and zone transitions. Twenty players generate under 2 Mbps of outbound traffic in normal play. A 100 Mbps uplink is therefore fine for a 30-player server, but the connection quality — jitter and loss, not raw bandwidth — determines whether players see rubber-banding. Choose a host with a blended, low-latency path and a port that supports at least 1 Gbps so a mod download or backup burst never saturates link.

DDoS risk is low for private servers but non-zero for public ones. A basic 2–5 Gbps scrubbed uplink is proportionate; you do not need enterprise mitigation for a 20-player Valheim world, but you do need the provider to absorb a 1 Gbps UDP blast without null-routing your IP for six hours.

A Sizing Recipe That Works

Start from instances and concurrent players, then add margin. For up to 20 players and 40,000 instances: a 4-core/8-thread CPU with 5.2 GHz+ boost, 8 GB RAM, NVMe with 40 GB free, daily restart, 20-minute saves. For 30 players or 60,000+ instances: same core class but 12–16 GB RAM and a dedicated NVMe volume, plus a plan to cap instance growth per base. Beyond 40 players, Valheim stops being a good fit regardless of hardware — the single-threaded loop becomes the hard limit, and splitting into two worlds is usually better than buying a bigger machine.

Finally, test with your actual world before you migrate. Copy the save to the candidate host, connect 10 players, and watch tick time with everyone in the biggest base simultaneously. That ten-minute test tells you more than any spec sheet, and it is the same test worth repeating whenever you consider the next dedicated server upgrade for a growing community.