Valheim server lag: zone ownership and desync

Most Valheim server lag is not the server running out of CPU. It is one of three other things: a player on a poor connection who owns the zone everyone is standing in, a crowded scene producing more updates than the game is willing to send each player, or a base with so many objects that every client struggles to load and simulate it. A short freeze every half an hour is a fourth, separate thing - the world save. Each has a different fix, and buying a bigger plan cures only one of them. This post explains how Valheim divides the simulation, how to tell which kind of lag you have, and what to change in what order.

If you are still setting the server up, start with the Valheim dedicated server guide; this post assumes the server runs and the complaint is that it does not run well.

How Valheim splits the work between server and players#

Valheim does not simulate the world on the server the way Minecraft or Factorio do. The world is divided into square zones of 64 by 64 metres. Every persistent thing in the world - a wall piece, a chest, a tree, a dropped stack of wood, a tamed boar - is stored as a ZDO, a zone data object, and every ZDO has an owner. The owner is the machine that simulates it and sends its state to everyone else.

When a player walks into an area nobody else is in, they become the owner of the objects there. Their game runs the creature AI, the physics of falling trees and the fire in the hearth, and the server relays the results to anyone else who arrives. The server itself owns objects only in areas no player is near, and stores the world on disk.

That design has consequences you can feel:

• Your experience depends on other people's connections. If the owner of the area is on mobile data, the monsters you are fighting are being simulated on their phone hotspot. You see them teleport.
• Your experience depends on other people's PCs. A player whose machine is struggling simulates their zones slowly, and everyone near them sees it.
• Ownership is sticky. It moves when the owner leaves the area or disconnects, not when someone with a better connection arrives.
• The server's CPU matters less than you would expect. It handles networking, saving and unattended zones. It is rarely the bottleneck for a group of ten.

A dedicated server still helps a great deal - the world no longer depends on one person's PC being on, and no player pays the cost of hosting while also playing - but it does not change who simulates the zone you are standing in.

Telling the kinds of Valheim lag apart#

Before changing anything, work out which one you have. The symptoms are distinct once you know what to look for.

The F2 key in the game opens a network overlay showing ping and the data being sent and received. It is the quickest way to establish whether a player's connection is the problem, and it is client-side, so every player can check their own without admin rights.

The important distinction is between the second and third rows. If lag follows a particular person, it is ownership and their connection. If it follows a particular place or moment - the main base, the boss arena, a raid - it is object count and network throughput. The fixes do not overlap.

Instance counts: why big bases hurt#

Every build piece is an object. So is every torch, every plant in a farm, every item lying on the ground, every animal, every smelter and every sign. A modest cabin is a few hundred pieces. A long-running group base with a great hall, a farm, a stable, smelting row and a harbour is easily many thousands, and a world with several such bases holds an enormous number of objects in a handful of zones.

That costs in three places:

1. Loading. When a player arrives, their client has to receive and instantiate every object in the surrounding zones. That is the stall on teleporting home and the long load screen on joining.
2. Simulation. The owner of the base zones simulates everything active in them: fires, cooking stations, beehives, growing plants, animals and their AI. The cost grows with what is ticking, not with what is merely standing there.
3. Structural integrity. Valheim calculates support for every building piece. Large builds on tall stacks of supports are expensive to settle when they load, which is part of why a big hall stutters as you approach it.

Some things are far more expensive than their size suggests:

• Tamed animals. A breeding pen with forty wolves or thirty lox is forty or thirty creatures running AI on whichever player owns that zone. Animal farms are the single most common cause of lag at a mature base.
• Items on the ground. Every dropped stack is a physics object. A pile of a hundred stacks of stone outside the smelters is a hundred objects to sync. Put them in chests.
• Fires and lights. Torches, braziers and hearths cost mainly frame rate on each client, since each is a light source, a particle effect and a fuel counter. Dozens of them in one view is noticeable on weaker machines.
• Terraforming. Raised, lowered and levelled ground is stored as modifications to the terrain. A base on a hilltop flattened by hand carries a lot of terrain data that every visitor must load.

You cannot see an instance count from the vanilla server console, but the size of the world file is a reasonable proxy. A new world's .db is a few megabytes. A world past 100 MB has a lot in it, and if the lag is concentrated where the building is, that is the reason.

The network side: why crowded scenes desync#

Valheim limits how much data it sends to each peer per update. When a scene has more changing objects than fit inside that budget, updates queue up and arrive late, and late updates look like rubber-banding, enemies that hit you from metres away and doors that open twice. This is why ten players fighting a raid inside the main base can desync while the same ten players spread across the map do not.

Three things make it worse:

• More players in one place. Each player in the area adds their own changes to sync and another stream to send to.
• More moving objects. Creatures, projectiles, falling trees and physics-driven items are the expensive ones.
• Poor routes. Jitter and packet loss turn a budget that would have been enough into one that is not. Latency, jitter and packet loss explains how to tell those apart, and reading traceroute and mtr how to prove where a bad route starts.

The vanilla game gives you no setting for the send limit. The community answer is a networking mod - Better Networking is the best known - that raises the rate limits and compresses traffic. It runs under BepInEx, so it is a PC-only option, and how much of it must also be installed on clients depends on which of its features you use; read the mod's own page for the current requirements before rolling it out. Treat it like any mod: test it on a copy of the world, and expect it to need an update after a game patch. The mechanics of installing BepInEx mods on a server are in Valheim mods with BepInEx.

Crossplay adds another consideration. Players joining through the crossplay relay have one more hop between them and the server than a Steam player joining by IP. For most groups that is a few milliseconds and not worth worrying about, but a Steam-only group that turned crossplay on by default loses a little for nothing. Valheim crossplay and Xbox players covers when it is worth having.

What the server itself needs#

The server process is light, but it is not free. It holds the world in memory, relays every update between players, simulates unattended zones and writes the world to disk.

Two server-side numbers matter more than the rest.

Clock speed. The main loop leans on one thread. A second core helps because saving and networking can run alongside it, but beyond two cores you are paying for capacity the game will not use. CPU vs RAM for game servers explains why one pinned core can look like a quarter-used CPU on a graph.

Memory over time. Memory climbs as more of the world is explored and loaded, and on a long-running server it does not all come back. A weekly restart keeps it flat. On RE:NODE, a server that hits its memory limit is stopped and restarted clean rather than left to swap, which protects the machine but ends the process without a save - so watch the memory graph against the limit and move up a tier before it becomes a pattern, not after.

The save hitch, and how to shrink it#

Valheim writes the whole world on a timer set by -saveinterval, 1800 seconds by default. On a small world the save is instant. On a large one it is a visible freeze for every player, and it happens on a schedule, which is why players report it as "lag every half hour".

The server log tells you how long each save takes:

World saved ( 1842.35ms )

The exact wording has varied a little between versions, but the timing is there. If that number is in the seconds and the freezes line up with it, you have found your lag.

What helps:

1. Fast storage. The write is the expensive part. NVMe turns a multi-second freeze into a short one - what NVMe actually changes is honest about where that matters, and a big Valheim save is one of the places it does.
2. A smaller world. Clearing dropped items, culling animal pens and demolishing abandoned outposts all shrink the file and the time to write it.
3. A sensible interval. It is tempting to push -saveinterval up to save less often. Do not go far: the interval is also exactly how much progress an unclean stop loses. Ten to twenty minutes is a reasonable compromise for a large world.

# Save every 15 minutes, keep 4 rotating backups-saveinterval 900 -backups 4

A freeze that happens at irregular moments rather than on the save timer is something else - usually a new area being loaded, or a mod. Check the log timestamps before assuming.

Fixes in the order worth trying#

Work down this list and stop when the lag stops. Most groups never get past step five.

1. Identify the kind. Use the table above. Do not start rebuilding the base because of one player's Wi-Fi.
2. Move zone ownership. If lag follows one player, have them leave the area or relog, and have the player with the best connection arrive first. Ownership passes to whoever is still present. For a planned boss fight or a raid, the best-connected player walks in first.
3. Clear the ground. Pick up dropped items around the base and smelters. This is free and often dramatic.
4. Cull the farms. Cap tamed animals to what you need. Thirty boars produce no more useful meat than eight.
5. Shorten the save, not lengthen it. Check the World saved timings; if they are long, reduce the world rather than raising the interval.
6. Spread out. Move the next project a few zones away instead of extending the main base.
7. Turn crossplay off if nobody needs it. Steam players then connect directly.
8. Try a networking mod, for a PC-only group with a busy base, after testing on a copy.
9. Restart weekly on a schedule, so memory never drifts upward for a month. Restart schedules that help covers timing.
10. Upgrade the plan only if the server's own CPU graph sits at its limit when the lag happens. Reading a server load graph shows what that looks like.

The last step is last for a reason. More memory does nothing for a zone owned by someone on hotel Wi-Fi, and more cores do nothing for a client rendering three hundred torches.

Mods that help, and mods that cost#

Mods sit on both sides of this problem.

Helpful, in the right situation: networking mods that raise send limits; server-side cleanup mods that remove dropped items after a time; mods that let a server own more zones itself. They change how the game behaves at a level the vanilla game never expected, which is exactly why they help and exactly why they break on patch day.

Costly: anything that adds a lot of objects. Building packs with hundreds of new pieces encourage bigger builds; farming and planting mods multiply plants; creature packs add AI. Overhauls that add biomes and bosses raise memory use and load times. None of that is a reason not to use them, but it is a reason to size for them.

A modded server also cannot accept Xbox players, because console players cannot install mods. If the group includes anyone on Xbox, the only mods available are those that run on the server alone. Before you troubleshoot lag on a modded server, read the BepInEx log for errors: a mod throwing an exception every frame is lag that no setting will fix.

Troubleshooting#

The server stutters every 30 minutes exactly. The world save. Check the World saved line for its duration, and work on the save rather than the network.

One player always lags and drags others with them. That player is owning zones on a poor connection or a struggling PC. Check their ping in F2. Wired instead of wireless fixes more Valheim lag than any setting.

Everyone desyncs at the base, nobody does in the field. Object count and the send budget. Clear ground items and animal pens first.

Low frame rate at the base for everyone. Client-side cost of lights, pieces and terrain. A faster server will not help; fewer torches and fewer pieces in one view will.

Lag started right after an update. A mod is out of date, or the world is being converted. Read the log from the start of the boot. What to do when a mod update breaks has the rollback drill.

The server restarted itself mid-session. Usually the memory limit. Look at the memory graph before the restart and at the restart pattern - why your game server keeps restarting tells the causes apart.

FAQ#

Does a more expensive server fix Valheim lag?

Only if the server's own CPU or memory is at its limit when the lag happens. Most Valheim lag comes from zone ownership, object counts or the per-player send budget, and none of those change with the plan. Check the graphs first, then decide.

Why does lag stop when one particular player logs off?

They owned the zones everyone was in. When they leave, ownership passes to another player, and if that player's connection and PC are better, everything smooths out. Have the best-connected player enter busy areas first.

Is it worth raising the save interval to stop the freezes?

A little, not a lot. The interval is also how much progress a crash or an out-of-memory stop loses. Making the world cheaper to save, and saving to fast storage, is better than saving rarely.

How many players can Valheim handle before lag is unavoidable?

The game caps a vanilla server at ten, and ten is fine on a sensibly built world. What makes lag unavoidable is ten players in one dense base during a raid, not ten players in the world. Mods that raise the cap go beyond what the networking was designed for.

Do torches and fires lag the server?

Mostly they cost frame rate on each player's machine, as light sources and effects. Fuel and burning are simulated by the zone owner, which is cheap per fire. Dozens of fires in one view are a client problem rather than a server one.