Valheim server CPU and disk sizing: what the hardware needs

A Valheim dedicated server needs one fast CPU core more than it needs many cores, and fast storage more than it needs a lot of it. For up to ten players, one to two vCPU on a modern, high-clock processor is enough for a vanilla world, a third core helps a heavily modded one, and 10-20 GB of SSD or NVMe holds the server, the world and a sensible set of backups with room to spare. The thing that hardware cannot fix is that much of Valheim's simulation runs on the players' machines, not the server - so a slow server and a slow player look alike, and it pays to know which you have before buying more of anything. Memory is covered separately in how much RAM a Valheim server needs; this post is about the rest.

Why Valheim leans on one thread#

Valheim is a Unity game, and like most Unity games its server does the bulk of its work on a main thread. Each frame, that thread processes incoming network messages, updates the objects it owns, and works out what to send to whom. Other threads help with networking and with writing saves, but the main loop cannot be split across cores. When it is busy, adding cores does nothing; making each core faster does.

That is why the advice for Valheim, as for many game servers, is to prefer clock speed and per-core performance over core count. Reading CPU usage for single-threaded servers explains why a server at "25%" on a four-core view can be completely saturated, and game server CPU requirements covers the general picture across games.

There is a twist specific to Valheim that makes its server lighter than its reputation suggests. The world is divided into zones, and each zone is simulated by the first player who enters it. Monsters, physics and building stability in that zone are calculated on that player's machine; the server stores the result and relays it to everyone else. The server only simulates zones nobody owns. In practice that means:

• A server with ten players spread across the map does far less simulation than you might expect, because most of the work is on the clients.
• A player with a weak CPU or a poor connection makes their zones lag for everyone near them, and no server upgrade helps.
• The server's CPU load comes mostly from synchronising objects between players, not from running the world.

So the server's job is mainly bookkeeping: tracking every object (the game calls them ZDOs), deciding which ones each client needs, and sending changes. That cost scales with how many objects are near active players and how many players are moving through busy areas at once.

What actually uses the server's CPU#

In rough order of impact on a typical group world:

Terraforming is worth a separate mention. Every terrain edit is stored as a modification to its zone, and zones heavy with edits cost more to load, save and send. A base built on a flattened plateau is noticeably heavier than one on natural ground. Terraforming on servers and performance by biome go into both.

Mods are the wildcard. A quality-of-life mod that changes a crafting menu costs nothing on the server. A mod that adds creatures, spawners or world-wide systems can add significant load, and a few mods that scan every object on a timer can saturate a core on a mature world. If you run mods, measure CPU on a quiet evening before and after adding each one.

Clock speed, cores and what a vCPU is#

Hosting plans sell CPU as vCPU or as a share of a core. Two numbers matter: how many you get, and how fast each one is.

• How fast. A modern desktop-class core at a high clock will run the same Valheim world with lower frame times than an older or low-clock server core. Hosts rarely tell you exactly what you are getting, and on shared nodes the model is often not stated at all. If ping is fine and players still see stutter as the group grows, per-core speed is the suspect.
• How many. One full core runs a small vanilla world. A second core gives the save and networking threads room to work without stealing time from the main loop, which smooths out the hitch when the world saves. Beyond two, a vanilla server gains little; a modded one may use a third.
• Hard limits versus bursting. On some hosts, CPU is a hard throttle: you get exactly the share you paid for and no more. On others, you can burst above it when neighbours are quiet. A hard limit is predictable; burst is faster on a good day and slower on a bad one. Shared CPU and noisy neighbours explains the difference.

On RE:NODE, CPU is a hard throttle to the share bought, measured in percent of one core, so 150 is 1.5 vCPU. A server at 100% of its share is slow, not broken, and is never suspended for it - but if your graph sits at the limit while players complain, the share is too small for what the world is doing.

Storage: install size, world files and backups#

Valheim is modest on disk. The numbers:

The .db grows with explored area, building pieces, items, tames and terrain edits. Exploring to the far edges of the map grows it; so does a group that builds a lot. Very large worlds on long-running servers can pass these figures, especially with mods that add content.

The server keeps its own rolling backups beside the world, four by default, controlled by -backups, -backupshort and -backuplong. Those copies sit in the same folder on the same disk, so count them in the disk budget. They protect against a corrupted save, not against losing the disk or the server. Real backups need to be somewhere else; Valheim backups and world corruption covers how to set that up.

Adding it up, a vanilla server with a long-lived world and its built-in backups fits in well under 5 GB. 10 GB is comfortable for most groups; 15-20 GB leaves room for a large mod set, logs, a second world or an archived old one. How much storage a game server needs and what to do when the disk fills up are the general versions.

NVMe, SSD or hard disk: what changes#

Storage speed matters for Valheim in three places: starting the server, saving the world, and taking backups.

Saving. Valheim holds the world in memory and writes it out every -saveinterval seconds (1800 by default). During that write, the server pauses or slows, and players can feel it as a short freeze. On fast storage it is usually brief. On a hard disk with a large world it can be long enough to cause rubber-banding or a stalled join. How much of the save happens off the main thread has changed between game versions, so do not rely on any fixed figure: the log prints a World saved line with the time taken, and that is your number.

Starting. Loading a large .db from a hard disk is slower, which lengthens every restart.

Backups. Copying the world, on a schedule or before an update, is faster on fast storage and competes less with the running game.

Past the jump from spinning disk to SSD, the gains are smaller. NVMe over SATA SSD helps most on big worlds and when several servers share a disk. What NVMe actually changes covers where the difference is real and where it is marketing.

If you are stuck on slower storage, lower -saveinterval anyway rather than raising it. A shorter interval means smaller pauses more often, and it caps what you lose if the server stops uncleanly. Autosave intervals discusses the trade-off.

Sizing by group size#

Putting CPU, disk and memory together for a vanilla or lightly modded world:

These are starting points. A small group that builds a vast base on a terraformed mountain can need the next row up; a large group that plays casually and spreads out may not. The right way to size is to start a tier lower than you fear, watch the graphs for a week, and move up only if something is actually at its limit. CPU vs RAM for game servers and when to upgrade your plan explain how to read that.

For comparison, RE:NODE's Valheim ladder runs from Starter at 2 GB, 15 GB of disk and 1 vCPU to Premium at 8 GB, 50 GB and 3 vCPU, all on NVMe. Moving between tiers changes the limits on the existing server, so the world stays where it is.

A worked example

Take a group of six who have played the same world for four months. They have one large main base on a levelled hill, two outposts, a pen of around twenty wolves and a handful of mods that add items and recipes but no new creatures. The .db is about 90 MB.

On a 1 vCPU, 3 GB server, the evenings look like this: CPU sits near the limit whenever four or more people are at the main base, the World saved line reports a pause of a couple of seconds, and memory hovers just under 3 GB. Players report a short freeze every half hour and rubber-banding at the base, but not at the outposts.

Reading that: CPU is at its limit only when players are in the dense area, so the base is the load, not the player count. The save pause matches the freeze. Memory is close but not at the limit. The sensible changes are a second core (which gives the save and network threads room and takes the base load off the limit), culling the wolf pen to a handful, and moving memory to 4 GB for headroom. Disk is not the issue: 90 MB plus four backups is under half a gigabyte. A bigger disk would have changed nothing; a faster one would only shorten the save pause slightly on storage that is already fast.

Running past ten players with a mod changes the picture: more players means more objects synchronised and more data sent, and the game was not tuned for it. The player limit and larger groups covers what that costs.

Telling a hardware limit from everything else#

Before upgrading, check that the server is really the bottleneck:

1. Watch the CPU graph during the lag. If it sits at the plan's limit, the server is short of CPU. If it is well below, adding CPU will not help.
2. Check who is near the lag. If the stutter follows one player, it is probably their machine or connection owning the zone. Have them move away or relog and see whether it clears.
3. Check save timing. If the freeze is regular and matches the save interval, look at the World saved timing and the storage.
4. Check memory. A server near its memory limit can behave badly before it is stopped. Look at the memory graph alongside CPU.
5. Check the network. Rubber-banding with low CPU and stable saves is often latency or packet loss. Valheim server performance and lag goes through the rest.

Reading a server load graph is a short guide to interpreting the shapes you will see.

FAQ#

How many CPU cores does a Valheim server need?

One full core runs a small vanilla world; two cores is the comfortable figure for a full group of ten, mainly so saves and networking do not compete with the main loop. More than two helps only heavily modded servers.

Is a Valheim server CPU or RAM heavy?

Neither, by the standards of newer survival games. It uses modest memory that grows with the world, and its CPU load is mostly one thread. Most of the world simulation runs on the players' machines.

Does an NVMe drive make Valheim run better?

It makes saves, starts and backups faster, which shortens the freeze when the world saves. It does not change frame rate in between. The big difference is going from a hard disk to any SSD.

How big does a Valheim world file get?

A new world is a few megabytes. A world played by a group for months is commonly somewhere between 20 and 150 MB, depending on exploration, building and terraforming. Mods that add content can push it higher.

Why does my Valheim server lag even though CPU usage is low?

Because a lot of the simulation is done by whichever player owns each zone. A player with a weak PC or poor connection makes the area around them lag for everyone, regardless of how idle the server is. Latency and packet loss also show up as lag with low CPU.