How to Size Hardware for a Valheim Dedicated Server
Sizing a Valheim server is less about hitting a spec sheet than knowing which resource runs out first. In practice that’s single-thread CPU speed, then RAM, and disk barely registers until your backups pile up. The honest answer to “what do I need?” is that a small friend-group world runs comfortably on modest hardware, and the only way to know your own numbers is to run it and watch. Read the requirements listed on the dedicated server’s own Steam page for the vendor’s figures — this post is about what those figures don’t tell you.
CPU: clock speed beats core count
The world simulation is not meaningfully parallel. A dedicated server spends its time ticking physics, creature AI, and terrain state, and much of that work lands on one thread. A four-core CPU with fast cores will usually serve a group better than a sixteen-core CPU with slow ones. This is why cheap VPS plans with many weak vCPUs can disappoint while a small plan on modern hardware feels fine.
Two cores is a sensible floor — one for the game loop, one for everything else the OS and SteamCMD are doing. Beyond that, prefer newer/faster cores to more of them.
Watch for shared-CPU throttling. Budget cloud instances often advertise burst performance with a sustained baseline far below it. A game server runs at a steady load forever, which is exactly the profile burstable plans handle worst. If your provider talks about CPU credits, read that section carefully before committing.
RAM: enough headroom, then stop
Memory use grows with how much of the world has been explored and how much is loaded around your players, and it grows further with mods. The pattern to plan for is not a fixed number but a shape: it climbs during a session and settles, and it’s higher on an old, heavily built world than on a fresh one.
Practical approach:
- Give the server a machine where you can watch memory over a real session rather than guessing from a table.
- Leave clear headroom above the peak you observe. A server that swaps to disk stutters in a way no amount of network tuning will fix.
- Add margin if you run BepInEx plugins, because some cache a lot.
Check it live on Linux with:
free -h
or, for the process specifically:
ps -o pid,rss,comm -C valheim_server.x86_64
rss is in kilobytes. On Windows, the Details tab of Task Manager shows the same thing.
Disk: small, but be honest about backups
The server install itself is small, and a world file is small. What actually fills a disk is your retention policy. Dated archives every few hours, kept for weeks, on a world that grows all year, adds up quietly.
- Size the disk for install + world + (backup size × retention count), then double it.
- Prune old archives in the same script that creates them.
- An SSD is nice for load times and save writes, but Valheim is not a disk-bound workload. Don’t pay for fast storage before you’ve paid for fast cores.
Network: upstream and latency, not throughput
Bandwidth is rarely the constraint; upstream capacity and consistency are. A home connection with generous download and thin upload is the classic bad fit for self-hosting, because the server’s job is almost entirely uploading world state to clients.
Two things matter more than raw speed:
- Consistent latency. Jitter shows up as rubber-banding far sooner than a lower average ping would.
- Physical location. Put the server near the majority of your players. Nothing you buy compensates for a transatlantic hop.
If your group is spread across continents, accept that someone will have a worse experience and pick the location that helps most people.
How to measure instead of guess
Run the server for a couple of real sessions with everyone on, then look at the numbers. On Linux:
top -b -n 1 | head -20
uptime
The load average from uptime compared against your core count tells you whether you’re
CPU-bound. On Windows, Resource Monitor with the server process pinned gives the same
picture.
What to look for:
- One core pegged at 100% while others idle → you’re single-thread limited. A faster CPU helps; more cores won’t.
- All cores busy → something else is on the box, or a mod is doing real work.
- Memory near capacity with swap activity → add RAM before anything else.
- Everything idle but players complaining → it’s the network, not the machine. See How to Reduce Lag on a Valheim Dedicated Server.
Where the load really comes from
Player count matters less than you’d expect for a friend-group server; what drives cost is how much stuff exists and how spread out everyone is:
- Large builds with many pieces are physics and networking work every tick.
- Players in separate biomes force the server to keep several regions active at once, rather than one.
- Long-running worlds accumulate explored terrain, dropped items, and structures.
- Tamed creatures and item-heavy bases add per-tick work that never goes away.
A brand-new world with four people in one base is a much lighter job than the same four people a year later with outposts on three continents. Size for where you’ll be, not where you start.
Sensible defaults for a small group
Without pretending to publish benchmarks: pick a machine with two or more reasonably modern cores, enough RAM that your observed peak sits well under capacity, an SSD if it’s free, and a connection with stable upstream near your players. Then measure and adjust. A spare desktop from the last few years, a small NAS with a real CPU, or a mid-tier VPS all land in that envelope.
If you’re choosing between a home box and rented hardware, the decision is usually about uptime and upstream rather than specs — Paid Valheim Hosting vs Self-Hosting: How to Decide covers that trade-off, and How to Host a Valheim Server on a VPS covers the setup if you go rented.