Valheim 1.0 landed on 9 September 2026, and if you've taken a server through a major Valheim patch before you already know roughly how that day went. Someone updates their client, tries to join, gets bounced straight back to the menu. Then three more people do the same thing, and your Discord has filled up before you've even got the panel open. Two days later Iron Gate shipped a hotfix, and a lot of servers went through the same thing again.
Here's the order I'd do it in, whether you're still on a pre-1.0 build or sitting on the launch build. None of it is difficult. It's four things really, and three of them are one click, but the sequence matters, and the backup step is the one everybody skips. If you are still choosing a host, Valheim servers from LOW.MS handle the backup and the update from the same panel.
Which build you want to end up on
The build that went out on launch day reports itself in the server log as Valheim version: 1.0.7 (network version 39). On 11 September Iron Gate posted "Hotfix 1.0.10 & 1.0.12", and the dedicated server build that came with it logs Valheim version: 1.0.12 (network version 40). That's the current one as I write this.
The network version is the bit to care about. A client and a server on different network versions is exactly the mismatch Valheim bounces people for, so a server still on 1.0.7 should be treated as unjoinable for anyone whose Steam client has patched. If you updated on launch day and haven't touched it since, you're not done.
Heads up: restarting doesn't update anything. A restart starts the same build again. I've seen a server restarted a full day after the hotfix that was still happily running 1.0.7. The update is its own step, below.
Back up first, and don't talk yourself out of it
A major version bump is the one update where "it'll probably be fine" has genuinely bitten people. 1.0 changed how worlds are stored on disk, and there's no undo button once the server has loaded your world under the new build and written a save over the top of it. So back it up. Twice, ideally.
Stop the server first, then take the backup. On a LOW.MS server that's Create backup on the Backups tab, and lock it with the toggle on its row so the rotation can never eat it. It takes seconds. Do it with the server stopped rather than running. Archiving a world mid-write is how you end up with a backup that restores to something broken, which is arguably worse than having no backup at all, because you'll trust it.
Then pull a copy down to your own machine as well. I know that sounds like belt and braces. Download on the backup row hands you the zip, or download the world folder itself from the Files tab. A backup on our infrastructure covers you against an update going wrong. A copy on your own desktop covers you against everything else, including, and I've watched this happen more than once, restoring the wrong thing at two in the morning because you were tired and every entry in the list looked much the same as the others.
The world lives in config/valheim/worlds_local/ on the Files tab. On 1.0 that's a folder named after the world rather than a pair of files, so download the whole folder. Our save location guide walks through which files matter if you want the detail.
There's one more reason to have that backup before anyone plays. Iron Gate's 1.0.12 notes say items on armour stands and item stands could lose their durability and upgrade level in worlds that have been loaded on 1.0, and they're telling people not to take high-level gear off stands "without using backups if you have been playing 1.0". So tell your group to leave the trophy weapons where they are until you've got one.
Then update the server
On a self-hosted box that's a SteamCMD run against the Valheim Dedicated Server package (Steam app 896660, a separate product from the game client's 892970). With us it's a button: the Game updates card on the Overview tab tells you an update is waiting, Update installs it, and the server stops and restarts on its own to do it.
That's the whole update. Really. It pulls the new build and validates the install as it goes, so a half-finished download from some previous run gets repaired rather than quietly carried forward into the new build. Coming from a pre-1.0 build it'll be a much bigger pull than usual. Give it longer than you think before you decide it's hung.
Watch the Console tab while it comes back up. Check the version line says 1.0.12. The first boot of an older world on 1.0 runs slower than normal, especially on an established world with a lot built on it, because the game converts the world to the new save format as it loads it. A world that usually takes 60 seconds might sit there for several minutes doing apparently nothing. Don't restart it halfway through out of impatience. That's a good way to turn a slow load into a broken one.
Update the server before your players update their clients, if you can. Valheim won't let a client onto a server on a different build, so whenever Iron Gate push a patch your group is locked out until the server catches up, and they'll all discover that within roughly the same ten minutes. If you know a patch is coming, post in your Discord the night before. It saves you the pile-on.
If you'd rather never do this by hand again, add an Update task under Scheduled tasks on the Settings tab, and the next hotfix gets picked up on its own. Same rule applies: a restart alone won't do it for you.
What the new save format does to your world
This one did ship. The 1.0 patch notes list a "New save system" that "Splits world data across chunks to reduce how much data is serialized and written to improve performance, and is designed to be resilient against mid-write failures". It's the system Iron Gate had on the public test branch since May.
In practice a world stops being a .db and a .fwl sitting next to each other. It becomes a folder named after the world, full of small .chunk files plus a handful of _main files, and only the chunks that changed get rewritten on each save. Valheim's own auto-backups are folders now too.
An older world converts itself the first time a 1.0 server loads it, and you don't need to help. What we've seen on converted servers is the original pair renamed to .db.old and .fwl.old, a separate copy with _backup_ and a date and time in its name (that's the world as it was just before conversion), and then the new folder beside them. Your old flat auto-backups are left alone.
So if you open the Files tab after updating and your world looks structurally different from how you left it, that's expected rather than a fault, and there's nothing for you to fix. Leave the folder alone. And don't point World Name at that _backup_ copy by accident, because it'll load your world as it was the moment before conversion.
The PTB notes also said the new system "has not been tested with mods". That was then, and the mod scene has been catching up since launch, but anything that reads or writes world files directly (world editors, save tools) needs a build made for the folder format before I'd let it near a world.
What crossplay actually means for a dedicated server
1.0 added PlayStation 5 and Nintendo Switch 2 alongside the existing PC and Xbox platforms, with full crossplay between all of them. It's a genuinely good change if your group has always been split across hardware and has spent the last few years working around it.
There's a temporary exception. The 1.0.12 hotfix couldn't be uploaded to Switch 2, and Iron Gate say "crossplay is not currently supported between Switch 2 and other platforms" until it is. Their workaround is for Steam players and dedicated servers to go back to the default_old branch, the 1.0.7 launch build, which means giving up the 1.0.12 fixes, and they add there's no workaround at all for PlayStation 5 and Xbox players to join Switch 2 players. Unless the Switch 2 players are most of your group, I'd wait for Iron Gate's fix. If you do need the old branch, open a ticket and we'll sort it with you.
For a dedicated server, crossplay isn't a thing you switch on and then forget about. Two things change.
The first is how people find you. A crossplay server registers a join code, printed into the log on startup, and console players use that instead of an IP and port. Your Steam players can carry on connecting the normal way, so you'll end up handing out two sets of instructions rather than one. On our panel the current code is on the Join your server card on the Overview tab once the server is up, and it's in the Console startup lines too. It changes every time the server starts.
The second is mods, and this is the bit worth slowing down on, because the version you'll read nearly everywhere is wrong. The usual line is that crossplay and mods are mutually exclusive: flip crossplay on, nothing loads at all, end of discussion. That's tidier than the truth, and it's in some of our own older guides too, which we've been working through.
All the -crossplay flag actually does is move the server off Steam matchmaking and onto PlayFab, which is the whole reason console and Microsoft Store players can reach you. It doesn't touch mod loading. What it does do is pull the rug out from under any mod that leans on Steam networking, or that keys off SteamID64 for admin and permitted lists, because there's nothing left for those to hook into. Plenty of mods work exactly that way, which is why the Valheim modding community's own wiki tells you to avoid crossplay because a decent amount of mods don't support it. A decent amount isn't all of them, though. Server-side-only mods written with vanilla clients in mind are still actively maintained and still work.
The harder limit is the one nobody can engineer around: console players can't install mods. So the moment a PlayStation, Switch 2 or Xbox player joins, anything that needs the mod present on the client is off the table regardless of what the server is running.
For our servers that makes it a per-mod question rather than a yes or no, and server-side-only is the category worth looking at first. The Mods tab searches the whole of Thunderstore, and the last-updated date on each row is the quickest way to see whether a mod has a release from after 9 September. Client-side vs server-side mods is the article for telling the kinds apart.
On our panel crossplay is the Crossplay checkbox in the General group on the Manage tab. Tick it, save, restart. Your world modifiers stay exactly where they were, because they're separate fields on the same tab rather than part of a startup line you have to swap.
Players can't connect after the update
Most post-patch connection problems are one of about six things, and they're quick to rule out in order.
Client version mismatch. By far the most common, and always worth checking first. Steam sometimes doesn't pick the update up until the player restarts Steam entirely, and a client still sitting on the old build gets rejected with no useful message at all. It just bounces them. Get them to verify their game files, or simply restart Steam.
The server didn't actually finish updating, or never got the hotfix. Check the Console for the version line on startup and confirm it says 1.0.12, the same as your players. If the update timed out partway through, just run it again. It's safe to re-run: it checks what's on disk against Steam's manifest and pulls back only what's missing or damaged, so you aren't starting the download from nothing.
A ban list or whitelist that's ignoring people. 1.0 brought in a new player ID format, and on the 1.0.7 launch build the ban list and whitelist only recognised the new style (Iron Gate's example is V_123456789) and ignored the older style entries (Steam_123456789). 1.0.12 fixed it. So if a whitelisted friend was refused, or someone you banned walked straight in, update before you start rewriting permittedlist.txt or bannedlist.txt.
Mods. If you're modded, assume every single one is broken until proven otherwise. A version bump the size of 1.0 breaks BepInEx plugins as a matter of routine, and a plugin that throws on load can stop the server accepting connections at all rather than failing politely in the background the way you'd hope it might. Check the Console for exceptions during startup. The fastest diagnostic is boring but reliable: take the mods off, confirm vanilla comes up clean, then put them back a batch at a time once the authors have caught up. Our mods after 1.0 guide has the detail.
Password. Two separate rules here, and they get muddled together constantly. Length first: at least 5 characters, which is Valheim's own floor and the number the panel enforces. The rule that actually catches people is the second one, and it's oddly specific. On a public server, the password can't appear anywhere inside your world name or your seed name. Not match them, be contained in them. So a world called Midgard with a password of gard won't start, and neither will anything similar you've not thought about. It doesn't quietly carry on without a password either: the server writes Error bad password: to the log and shuts down on the spot. If the server died within seconds of somebody changing the password, open the Console, search for that line, and you've got your answer.
Crossplay confusion. If you switched crossplay on in the same sitting as the update, half your group will be trying the old IP and port while the rest use the join code. Steam players can use either, console players need the code. People just need telling which one applies to them. And if one of them is on Switch 2, see the exception above.
If you're still stuck after all that, the can't connect guide goes deeper, and the general troubleshooting guide covers the performance and world-loading side of things.
Should you update straight away?
If you're running vanilla with a group of friends, yes. Update, play, go and see the Deep North.
If you're running a modded server with a community on it, I'd check your mod list first. Mod authors couldn't properly update against a build they hadn't seen, so the days after any major Valheim release are a stream of half-working plugins, hasty fixes and forum threads full of people hitting the same crash. Look at each mod's Thunderstore page for a release since 9 September. Your world isn't going anywhere. And there's a real difference between telling your players "we're updating on Friday, once the mods have caught up" and telling them "the server's been down since Tuesday". The one thing I wouldn't do is sit on 1.0.7 for long, because your players' clients won't wait with you.
Either way, the backup comes first. If the update does go badly, Restore on the Backups tab puts you back exactly where you were, with the server stopped. That's a five-minute problem rather than a lost world, and the gap between those two outcomes is about ninety seconds of effort before you started.
If something looks wrong and you'd rather not poke at it yourself, open a ticket from the panel with your service name and roughly when it broke. We'd much rather look at it before you've tried six things than after.