Valheim has an unusual hardware profile for a modern survival game: it is light on CPU, forgiving on RAM, and indifferent to GPU power on the server side. That makes it easy to host well, and equally easy to overspend on. The failure modes that hurt communities are not frame rate problems — they are world-save corruption, memory growth over long uptimes, and save stalls that freeze everyone for several seconds during a boss fight. This guide covers the hardware sizing that matters, the setup sequence that avoids the common traps, and the tuning values that keep a large build stable across weeks of uptime. For broader hardware comparisons across game titles, see the dedicated server reference on this site.
How the server actually uses hardware
The dedicated server runs a single process that consumes one thread for world simulation and a small number of additional threads for networking and save serialisation. Valheim’s world is zone-based: terrain and structures load as players move, and the server’s work scales with the number of active zones rather than the raw player count.
This produces a specific capacity curve. A server with eight players spread across a large continent can be busier than one with sixteen gathered at a single base, because the first case keeps many more zones resident. When sizing, think in terms of simultaneously active zones, and use a rule of thumb of roughly one active zone per player during exploration plus a few for base areas.
CPU: clock over cores, with a caveat
Because the simulation is effectively single-threaded, the highest clock you can get decides how fast entity-heavy areas process. A current-generation part with strong single-core performance at around 4.5 GHz handles a well-modded 40-player world comfortably. Core count beyond four contributes little for a single world.
The caveat is world size and base complexity. Very large builds increase per-tick work regardless of player count: a server that runs smoothly at 40 players in an undecorated world may stutter at 20 in a megabase.
| Community size | vCPU (physical cores) | RAM | Storage |
|---|---|---|---|
| 2–5 friends | 2 | 3–4 GB | Any SSD, 10 GB |
| 6–15 players | 2–4 | 6–8 GB | NVMe preferred |
| 16–30 players | 4 | 10–12 GB | NVMe, mirrored |
| 30–64 with mods | 6–8 | 16–24 GB | NVMe, mirrored, spare slot |
RAM: the number that grows while you are not looking
Memory use in Valheim rises as zones are loaded and does not always fall back cleanly. A server started with 3 GB and left running for two weeks often sits at 2.8 GB with a world that used 1.2 GB at launch. This is normal behaviour rather than a leak in the harmful sense, but it means you must size for the ceiling, not the starting point.
Give the process headroom of at least 50% above its steady-state usage after a week, and enable the automatic restart that most panel images provide. A nightly restart at a low-population hour resets the zone cache and is the single most effective reliability measure available.
ps -o rss=,vsz= -p $(pgrep -f valheim_server) | awk '{print $1/1024" MB RSS"}'
free -m
cat /proc/pressure/memory
Watch the PSI memory figure: if the “full” stall time climbs steadily across days, the process is thrashing and a restart or RAM increase is due.
Storage and save behaviour
Valheim writes the world to disk periodically and on shutdown. The save is not atomic in older server builds: the file is written in place, which means a crash or power loss mid-write can leave a truncated world. This is the most damaging failure mode a community can experience, and it is solved by storage discipline rather than faster hardware.
Three measures eliminate it almost entirely. First, keep the world directory on a filesystem with a sane commit interval so writes hit the disk promptly. Second, schedule a filesystem-level snapshot or a copy of the world directory every fifteen minutes using rsync or btrfs/ZFS snapshots. Third, retain at least a week of rotating copies, because corruption is often not noticed for days.
rsync -a --link-dest=/srv/valheim/backups/latest /srv/valheim/worlds/ \\
/srv/valheim/backups/$(date +%Y%m%d%H%M)/
Hard-link based snapshots cost almost no space for unchanged files and give you a full history to roll back to. Test a restore quarterly; an untested backup is a hope, not a plan.
Bandwidth and network behaviour
Valheim is bandwidth-light. Each player generates roughly 20–40 kbit/s at peak during heavy world interaction and considerably less when standing in a base. A 30-player server rarely exceeds 10 Mbit/s outbound, so even a modest dedicated uplink is ample.
What matters more is packet loss and path stability. The server uses UDP, and the game’s netcode tolerates some loss but not sustained loss. Measure from a representative player connection:
mtr -rwzc 200 --udp <server-ip>
Loss that persists to the destination hop will manifest as rubber-banding and delayed crafting responses. If it appears only after 21:00 in the player’s time zone, the constraint is the ISP’s evening path rather than your server, and a different datacenter location may resolve it.
Mods and the real capacity cost
Server-side mods that add creatures, terrain generation, or persistent item tracking increase per-tick work substantially. A pack with fifty small quality-of-life mods is much cheaper than one with three that add active AI entities. Loading additional zones through mods can triple the memory footprint.
Test the actual mod pack at the expected player count before committing to a plan. A server that runs vanilla content at 45 players may be comfortable at 20 with a heavy pack and the same hardware.
Setup sequence that avoids the common traps
Install the server via SteamCMD into a dedicated unprivileged user, write a systemd unit with a restart policy and a memory ceiling, and configure the world to autosave more frequently than the default while keeping backups enabled. Protect the world directory with the backup job before inviting the first player.
systemctl edit valheim.service
# MemoryMax=16G
# Restart=on-failure
# RestartSec=15
Set MemoryMax slightly above the steady-state ceiling so a genuine runaway is contained and restarted automatically instead of triggering a host-wide OOM event.
Where the money should go
For Valheim specifically, spend on RAM headroom, reliable NVMe, and a provider with good network paths rather than on core count. A modest four-core machine with 16 GB and mirrored storage will serve a 40-player community better than a 24-core machine with 8 GB on a congested uplink. Valheim rewards boring infrastructure choices — predictable memory, frequent backups, and honest measurements of the world your players actually built. For more sizing data across survival titles and hardware classes, see the game server hardware guides on bestdedicatedwebhostingserver.com.



Leave a Reply
You must be logged in to post a comment.