Valheim 1.0, One Month In: What the Patches Did to Dedicated Servers

The 1.0 server at a glance

Iron Gate's launch post leads with the Deep North, and for players that is the headline: a new biome, more than 40 weapons, a new boss, achievements. For the person who runs the box, the story is quieter and more important. The dedicated server is the same Steam tool it has always been, but the files it writes and the IDs it reads are not.

We installed the current public build of the dedicated server (Steam app 896660, build 25730807, which reports itself as version l-1.0.17, network version 40) on a Linux machine today and generated a fresh world, so the numbers below are what the shipping server does, not what a host's sales page says.

The 1.4 GB figure is an empty world with nobody in it, so treat it as a floor, not a plan. Memory grows with explored area, building and players, which is why our Valheim requirements guide still recommends real headroom. The more useful observation is the start-up time. On a fresh world the server logged "Game server connected" about 26 seconds after launch, then spent another 21 seconds placing world locations before it opened the Steam server and registered its lobby, so a health check that pings the port too early will think a perfectly fine server is broken.

The patch month: what touched servers

Iron Gate shipped a steady run of fixes after launch, from 1.0.10 on 11 September to 1.0.17 on 6 October. Most of the notes are gameplay: battleaxe tiers, achievements, a shield variant on PS5. Read them as a server owner, though, and a different list falls out:

The pattern is clear enough: the risky part of 1.0 for servers has been the save and terrain code, not the network code. If you skipped updates during September because things looked stable, this is the month to catch up. On the 1.0 base itself, the notes also list an optimised network cost for terrain manipulation, a minimap memory leak fix, faster world generation and some IPv6 fixes, all of which are server-side wins you get just by updating.

The new save format, and the backup you must keep

This is the change that matters most. Before 1.0, a world was a single .db file with a .fwl metadata file beside it, and the 1.0 server still checks for that old .db first (our log shows it looking for worlds_local/DgsTest.db before creating the new layout). The 1.0 patch notes describe a new save system that "splits world data across chunks to reduce how much data is serialized and written" and is "designed to be resilient against mid-write failures".

On disk it looks like this. Our test world, after its first save, was a folder rather than a file:

worlds_local/DgsTest/
  _main.1.db2
  _main.1.fwl2
  _main.1.chunks
  _main.1.ok
  00_00__0_1.chunk

Three practical consequences follow.

• Back up the folder, not a file. Any script that copies worlds_local/*.db is now copying nothing. Point it at the world directory and copy the whole thing.
• Do not hand-edit or partially copy chunk files. A world is now many files that only make sense together. Copy a world while the server is stopped, or use the server's own backups.
• Keep the conversion backup. When an old world is first loaded on 1.0, the game converts it and makes a backup of the original. Iron Gate's 1.0.15 notes explain why that backup matters: items on item stands and armour stands lost their levels and variants during conversion in the first 1.0 builds, the data "is lost in the conversion", and the bug was fixed in 1.0.12. If your world converted before that fix, the official workaround is to revert to that backup (losing progress since) or load a copy of it, collect the affected items, and carry them back.

The 1.0.17 line in the patch table is the other save bug to take seriously, and it was fixed only four days ago. The patch, released on 6 October, fixed "a rare bug that could erase all objects in parts of the world when one large world save chunk file was split into smaller ones". If you run a big, long-lived world, make sure the server is on 1.0.17 or later, and keep the server's rolling backups switched on. The relevant launch options are unchanged: -saveinterval (default 1800 seconds), -backups (default 4), -backupshort (default 7200 seconds) and -backuplong (default 43200 seconds).

Admin lists and the V_ ID prefix

The three permission files are where they always were, in the save directory (on Linux ~/.config/unity3d/IronGate/Valheim unless you pass -savedir): adminlist.txt, bannedlist.txt and permittedlist.txt, one platform user ID per line, case sensitive. Our test server created all three on first boot.

What changed is the ID itself. The manual still documents the format as [Platform]_[User ID], and in the 1.0 era that platform part can be the new V_ prefix. Iron Gate's 1.0.12 hotfix notes, from 11 September, fixed "a problem with banlist and whitelist that made them only compatible with new IDs (e.g. V_123456789) even though they should work with old IDs too (e.g. Steam_123456789)".

So, in plain terms:

• If your lists were written before 1.0 with Steam_ entries and the server is on 1.0.12 or newer, they should keep working.
• If you ran a 1.0 build older than 1.0.12, your old bans and allow-list may have silently stopped applying. Check who joined during that window.
• For new entries, take the ID from the server log or the in-game F2 panel rather than typing it from memory, and remember that adding anyone to permittedlist.txt blocks everyone else.

Crossplay, ports and the PlayFab relay

Valheim already had crossplay between Steam, the Microsoft Store and Xbox before 1.0. Iron Gate's 1.0 FAQ says crossplay now covers all platforms, and its general FAQ lists them: Windows, Linux, Mac, Xbox One, Xbox Series X|S, PlayStation 5 and Nintendo Switch 2. For a server owner, the important part is that none of this is automatic.

The server manual is explicit. Without the -crossplay argument, the server runs on the Steam backend and "only Steam users can see and join the Server". With it, the server runs on the PlayFab backend and anyone on any platform can join. The two backends behave very differently on the network:

• Steam backend. You forward the game port and the one above it (2456 and 2457 by default). The shipped start_server.sh comment asks for 2456 to 2458, so forwarding all three is the safe choice.
• Crossplay backend. Traffic goes through a relay, so no port forwarding is needed. Players connect with the public IP and port, a join code, or the server list. One catch from the manual: you cannot connect to a crossplay server with a local or loopback IP, which trips up people testing from the same LAN.

Two operational notes. If you run several crossplay servers on the same port from the same machine, give each one a unique -instanceid so they get separate PlayFab IDs. And plan your updates around the platforms: Iron Gate's patch posts repeat that patches can take a few days to reach every platform, while crossplay keeps working in the meantime. In practice that means a console player can be on a slightly different patch than your Steam server for a short window, and the studio has said it ships crossplay-sensitive fixes to all platforms at once to avoid breaking that. For the general picture of how console crossplay interacts with dedicated servers, see our crossplay explainer.

Staying on pre-1.0: the official branch

Iron Gate's 1.0 FAQ was blunt about mods: the studio "cannot guarantee that any mods will be functional when 1.0 releases", there is no official mod support on PC, and there was no public test branch before release. If your server lives on a mod stack that has not caught up, you do not have to improvise.

The dedicated server app on Steam carries a set of named branches. As of today they include default_pre1_0 (described as "Last stable build before 1.0"), default_old ("Previous stable", updated 25 September) and older ones going back to before Mistlands. With SteamCMD that is:

app_update 896660 -beta default_pre1_0 validate

The trade-off is real. Your players have to switch their game client to the matching branch, the save format will be the old one, and console players cannot join, because they cannot pick an old build. Treat the branch as a waiting room until your mods update, not as a home. And do not point a pre-1.0 server at a world that has already been converted to the 1.0 format.

If you have not upgraded yet

1. Stop the server cleanly with Ctrl+C, as the manual says, not by killing the window.
2. Copy the whole save directory, including the three permission files, somewhere off the machine.
3. Update app 896660 and confirm the log shows 1.0.17 or later.
4. Decide on -crossplay. If you add it, you can close the forwarded ports; if you do not, console players cannot see you.
5. Start once, let it convert the world, and check that the conversion backup exists before letting players in.
6. Re-check ban and admin lists with a test account.
7. Update your backup script to copy world folders, not .db files.

None of this needs new hardware. 1.0 did not change the cap or the ports, and an idle 1.0 server is light. If you are deciding whether to keep running it at home or move it, our VPS vs managed host guide covers that decision, and Iron Gate's own dedicated server guide lists every launch argument.

Related reading

• Valheim Dedicated Server Requirements (2026): RAM, CPU, Players
• Valheim Dedicated Server: VPS vs Managed Host, Decision Guide
• Crossplay on Dedicated Servers: PC, Xbox, and the PS5 Wall
• Who Owns Your Game Save? Host Data Lock-In and Lost Worlds