Valheim Dedicated Server World Size and RAM: Sizing Hardware for Long-Running Worlds

Valheim Worlds Grow, and So Does Your RAM Bill

Valheim’s dedicated server is unusually deceptive about resource requirements. A fresh world with 10 players runs comfortably on 4 GB. The same server, six months and 40 explored biomes later, can push past 12 GB — because Valheim stores all world modification data in memory and the world file grows continuously with terrain edits, terrain heightmaps, and every structure placed.

This guide explains how world size drives memory and how to size hardware so a long-running community server does not need a rebuild. For broader bare-metal selection, start with our dedicated hosting overview.

The Valheim World File, Quantified

World age / exploration	.db file size	.fwl size	RAM in use
Fresh world, one biome visited	3-8 MB	2-4 MB	2-4 GB
Mid-game, 5-10 biomes explored	40-120 MB	15-40 MB	5-8 GB
Heavy exploration, 20+ biomes	200-500 MB	80-200 MB	8-12 GB
Large building community, 500+ hrs	600 MB – 1.5 GB	200-500 MB	12-16 GB

The world consists of two files: world.db (ZDO data — every entity and modification) and world.fwl (world generation metadata). The .db file carries the memory cost. A 1 GB .db file typical of a large community build maps to roughly 12-16 GB of resident memory, because Valheim expands the compressed ZDO store into live objects.

Hardware Tiers by World Size

Community profile	vCPU	RAM	Storage
Private server, 5-10 players, fresh world	2-4	6-8 GB	NVMe 100 GB
Public server, 10-20 players	4	12 GB	NVMe 200 GB
Community server, 20-40 players, mature world	6-8	16-24 GB	NVMe 500 GB
Large building community, 40+ players	8-12	32 GB	NVMe 1 TB

Why 8 GB Is Not Enough Long-Term

Most Valheim hosting guides quote 4-8 GB because they are sizing for a fresh world. A server that will run for a year with an active building community should start at 16 GB minimum. Migrating a mature world to a larger plan later is possible but requires a full world transfer, and if the world has grown past the new host’s memory ceiling the migration fails. Sizing for 12 months of growth is cheaper than migrating twice.

CPU and the Tick Rate Problem

Valheim’s dedicated server runs a Unity simulation with a modable tick rate. Default is 20 Hz; many servers mod it to 30 or 60 Hz for smoother combat and building. Raising the tick rate multiplies CPU cost linearly. On a 2-core VPS, a 60 Hz tick rate with 20 players will pin both cores.

More importantly, Valheim’s server simulation degrades non-linearly with loaded entities. A base with 15,000 instances in view will drop tick rate regardless of CPU headroom. The solution is architectural: split large builds across the map rather than stacking them in one render zone.

Storage: The Save Stall

Valheim saves the world on a timer (saveinterval, default 1800 seconds) and on shutdown. During the save, the world is written to disk — and on a large world, that write blocks the tick loop. A 1 GB world written to SATA storage produces a multi-second freeze visible to every player.

• NVMe storage is mandatory once the world exceeds 200 MB.
• Keep saveinterval at 1800-3600; shorter intervals mean more frequent stalls, longer intervals mean more lost progress on crash. 30-60 minutes is a reasonable balance.
• Automate backups to a separate volume. Valheim’s backup system writes copies on save, which doubles I/O per save cycle.

Network Requirements

Valheim bandwidth per player is modest — roughly 30-70 Kbps at default settings, rising during large building projects and combat with many entities. A 20-player server sustains 1-2 Mbps with spikes during world syncs. Where Valheim differs is the join sync: when a player connects, the server sends world data, which on a large world can be several megabytes. Plan for a 1 Gbps port and 2-4 TB monthly traffic for a mid-size community server.

Mods Change the Calculus

• Valheim Plus / Jotunn packs — add native memory overhead and increase entity complexity. Budget 25-40% more RAM than a vanilla server of the same world size.
• Epic Loot and similar content mods — every player’s modified inventory is tracked as ZDO data, growing the world file.
• Server-side map/teleport mods — usually negligible, but mods that add persistent entities are not.

Sizing Checklist

1. Estimate the world’s 12-month .db size from your community’s building activity.
2. Multiply that size by roughly 12x for resident memory.
3. Add 35% if you run mods.
4. Set saveinterval between 1800 and 3600 seconds.
5. Ensure NVMe storage and separate backup storage.
6. Monitor RSS against physical RAM; alert at 80%.

Valheim is one of the few game servers where the correct sizing question is not “how many players” but “how big will this world get.” Provision for the world’s future size, not its current one. For current bare-metal options with the RAM ceilings this workload needs, see the hardware options on our main site.