Valheim 1.0 lands on 9 September 2026, and if you've taken a server through a major Valheim patch before you already know roughly how that day goes. 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.
Here's the order I'd do it in. 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.
One bit of honesty first. I'm writing this before 1.0 has actually shipped, and the current stable build as I type is 0.221.12, from February 2026. So what follows is the procedure that's held for every Valheim patch since we started hosting the game, and I'll flag the two or three places where 1.0 might behave differently from the patches that came before it, because there are a couple.
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 is a bigger jump than a normal patch, it may change 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.
In the LOW.MS Control Panel, stop the service first, then open Cloud Backup in the sidebar and run one. It takes seconds. Do it with the server stopped rather than running – archiving a world file 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. File Manager into your world folder and download it, or connect over SFTP on port 8822 if the world has grown large enough that the browser starts struggling. A cloud 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 files sit under the Valheim folder in your service root, in worlds_local. Our save location guide walks through which files matter if you want the detail.
Then update the server
Stop the service if you haven't already. Open Steam Update in the sidebar. Run it.
That's the whole update. Really. Steam Update pulls the Valheim Dedicated Server package – Steam app 896660, which is a separate product from the game client's 892970 – 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. On a major version it'll be a much bigger pull than usual. Give it longer than you think before you decide it's hung.
Start the server once it finishes, and watch Web Console while it comes up. First boot after a big patch runs slower than normal, especially on an established world with a lot built on it, because the game is upgrading data as it loads rather than simply reading it back. If the new save format below does land in 1.0, that first load also converts the world and writes a backup before it does, which is more work again. 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 newer client onto an older server, so the moment 1.0 goes live your entire group is locked out until the server catches up – and they'll all discover that within roughly the same ten minutes. Post in your Discord the night before. It saves you the pile-on.
The save format question
Iron Gate shipped a new world save system to the public test branch back in May, in patch 0.221.13. Instead of a world being a .db and a .fwl file sitting next to each other, worlds get their own folders and the .db is split into chunks, with backups kept in separate folders again. The stated goals were faster saves and less corruption – both good things, and both overdue.
Two details from those patch notes are worth holding onto. The first is that when the server loads a world which isn't already chunked, it takes a backup before converting it, specifically so nothing is lost if the conversion hits a bug. Sensible design, and not a reason to skip your own backup. The second matters more if you're modded: Iron Gate noted plainly that the new save system hasn't been tested with mods. They said they don't believe there'll be problems. They also didn't promise there won't be.
What I can't tell you is whether any of that ships as part of 1.0. It's been sitting on the public test branch since May, Iron Gate haven't confirmed it for the stable release, and I'm not going to guess in either direction just to sound more certain than I actually am. Treat it as one more reason to take the backup, not as settled fact.
The practical version: if you open File Manager 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. Iron Gate's own note on the test build was explicit that you shouldn't be shuffling files around by hand when moving between branches, and I'd extend that to the update itself. Let the server convert the world on its own. Don't try to help it.
What crossplay actually means for a dedicated server
1.0 adds PlayStation 5 and Nintendo Switch 2 alongside the existing PC and Xbox platforms, with full crossplay between all of them. That's the headline. It's a genuinely good one if your group has always been split across hardware and has spent the last few years working around it.
For a dedicated server, though, 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 publishes a Join Code, printed into the log on startup, and console players use that instead of an IP and port – your Steam players carry on connecting the normal way, so you'll end up handing out two sets of instructions rather than one. Watch Web Console on the first boot after you enable it and pull the code out of the startup lines.
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're 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 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. Mod Manager in the sidebar covers the curated list. For anything outside it, open a ticket and we'll get it on there for you. And do check before 1.0 rather than after – see the note above about the new save system not having been tested with mods.
On our platform crossplay is a startup-line choice rather than a checkbox. Open Commandline Manager in the sidebar and you'll find a small set of predefined command lines, including a plain default and a "Default (With Crossplay)" one that adds the -crossplay flag. Pick the crossplay line, save it, restart.
One thing worth knowing before you switch, because it isn't signposted anywhere: the crossplay line and the "Additional Configuration" line are separate options, and only the second of those carries the Preset and Modifiers fields from Service Settings through to the running server. So if you've spent an evening tuning combat difficulty, raid frequency and portal rules through those fields, then move over to the crossplay line, all of it quietly stops being applied. Nothing errors. The world just plays differently. If you need both at once, open a ticket and we'll build you a custom startup line that carries the crossplay flag and your modifiers together.
Players can't connect after the update
Most post-patch connection problems are one of about five 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. Check Web Console for the version line on startup and confirm it matches what your players are running. If Steam 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.
Mods. If you're modded, assume every single one is broken until proven otherwise. A major version bump 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 Web Console for exceptions during startup. The fastest diagnostic is boring but reliable – move the mods out of the way, confirm vanilla comes up clean, then put them back a batch at a time once the authors have caught up. Our mod installation guide has the detail.
Password. Two separate rules here, and they get muddled together constantly. Length first: our panel asks for at least 8 characters, which is us being stricter than the game. Valheim's own floor is 5. 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 service died within seconds of somebody changing the password, open Web 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. Both routes still work. People just need telling which one applies to them.
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 on day one?
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 wait. Not long – a few days. Mod authors can't properly update against a build they haven't seen yet, so the first 48 hours after any major Valheim release tend to be a stream of half-working plugins, hasty fixes and forum threads full of people hitting the same crash. Add Iron Gate's own note that the new save system hasn't been tested with mods and the case for sitting it out for a few days gets easier to make. 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".
Either way, the backup comes first. If the update does go badly, Cloud Restore puts you back exactly where you were – 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.