RE:NODE

Guides12 min read

How to upload a Valheim save to a dedicated server

Move a single-player or co-op Valheim world onto a dedicated server: where the .db and .fwl files live, how to upload them, and how to fix a world that resets.

1 reader

To put a world you have been playing locally onto a Valheim dedicated server, you copy two files - YourWorld.db and YourWorld.fwl - from your PC into the server's worlds_local folder while the server is stopped, then set the server's world name to YourWorld, exactly as the file is spelled. Start it, and the server loads your world instead of generating a new one. That is the whole job. Everything below is what goes wrong when one of those four details is slightly off, which is how most people end up on a fresh map wondering where three months of building went.

The good news first: nothing in this process can damage the world on your PC. You are copying, not moving, and the original stays where it was until you delete it yourself.

What a Valheim save actually is#

A Valheim world is two files with the same name and different extensions:

FileSizeWhat is in it
Name.fwlA few hundred bytesThe world name, the seed and some metadata
Name.db5-200 MBEverything else: buildings, terrain changes, items on the ground, explored map, boss progress
Name.fwl.old, Name.db.oldSame as aboveThe previous save, kept automatically
Name_backup_auto-...Same as .dbTimed automatic backups, if enabled

The two main files are a pair and always travel together. The .fwl holds the seed, and the terrain is regenerated from that seed every time a zone loads; the .db holds every change made on top of it. Upload the .db alone and the server pairs it with a seed it made up, and the result is a world where your buildings float over the wrong landscape - or, more often, the server ignores it and generates a new world.

Characters are not part of the world. Your character, its skills and its inventory live in a separate .fch file on each player's own machine, under characters_local. You do not upload characters, and you do not need to: every player joins the dedicated server with the character they already have. This is also why the move does not lose anybody's gear.

Find the world on your PC#

On Windows, single-player and self-hosted worlds are in:

code
%USERPROFILE%\AppData\LocalLow\IronGate\Valheim\worlds_local\

Paste that line into the address bar of File Explorer and press Enter - AppData is hidden, so browsing to it by clicking usually fails. On Linux the same folder is:

code
~/.config/unity3d/IronGate/Valheim/worlds_local/

What you should see is one .db and one .fwl per world, plus .old copies and possibly a few backups. Pick the pair with the name of the world you play on, and check the modified time on the .db - it should match the last time you played.

The folder is empty

Then your world is stored in Steam Cloud rather than locally. Valheim keeps cloud worlds somewhere you are not meant to dig for, and the supported way out is through the game:

  1. Start Valheim and click Manage saves on the world selection screen.
  2. Select the world and use the option to move it from cloud to local.
  3. Quit the game, and look in worlds_local again.

Moving it to local turns off cloud syncing for that world. That is what you want here: once the world lives on the server, the server is the copy that matters, and a cloud copy on your PC would only drift out of date.

The world was hosted from inside the game

If one of your group ran the world with the in-game "Start server" option, the files are on that person's PC, in their worlds_local, not yours. They have to send you the pair, or do the upload themselves. Joining someone else's in-game hosted world never puts a copy of it on your machine.

Xbox and Game Pass versions

The Microsoft Store and Game Pass releases on PC keep saves in a different, containerised format rather than as plain .db and .fwl files in worlds_local. The upload described here needs the plain pair. If your group plays on Game Pass, search for the current method for that version before you start, because it has changed between releases and anything stated here would date quickly.

Before you upload: three checks#

These take two minutes and prevent the three most common failures.

  • Quit to the main menu first. Valheim writes the world on a timer and on exit. A world copied while you are still in it is a snapshot of the last save, not of what you see on screen. Quit, wait for the menu, then copy.
  • Note the exact file name. Midgard, midgard and Midgard with a trailing space are three different worlds to a Linux server. Copy the name from the file rather than typing it from memory.
  • Match the game version. The server must run the same Valheim version as the clients, and a world saved by a newer version cannot be loaded by an older server. If you have been playing on the public test branch, the world is a test-branch world; use a test-branch server or wait for the update to reach the main branch.

Upload the world to the server#

The same steps work on any host. Where the panel matters, the RE:NODE details are noted.

  1. Stop the server. Not restart - stop, and wait until the console confirms it is offline. A running server holds the world in memory and writes it over the top of whatever you uploaded at its next save.
  2. Take a backup, even of an empty world. It is the only way back if you upload into the wrong folder or overwrite a world you wanted to keep.
  3. Open the server's files - in the panel's file manager, or over SFTP with a client like FileZilla or WinSCP.
  4. Find `worlds_local`. On a Linux server running with the default save location it is inside .config/unity3d/IronGate/Valheim/ in the server's root. If the Startup tab sets a -savedir, it is worlds_local inside that folder instead.
  5. Upload the `.db` and `.fwl` into worlds_local. If you uploaded a zip, unpack it there and check the two files sit directly in worlds_local, not in a subfolder named after the zip.
  6. Set the world name on the Startup tab to the file name without its extension, capitals included.
  7. Start the server and read the console as it loads.

On RE:NODE the file manager takes drag-in uploads and unpacks archives in place, so a zipped world is two clicks: drop it in, extract it. Each server has its own SFTP credentials in the panel, and SFTP and the file manager covers when to use which and the transfer problems people hit. The Valheim install already has crossplay on and a join password generated, so after the upload the world name is the only launch setting you need to change.

Cannot find worlds_local on the server

The folder starts with a dot, and some file browsers hide dot-folders. If you still cannot see it, the server may never have saved a world yet - the folder is created on first save. Start the server once with any world name, let it finish generating, stop it, and the folder will be there with a fresh world in it. That fresh world is harmless; delete its pair or leave it beside yours.

The reliable way to find any Valheim save, on any host, is to search for a file ending in .fwl. Wherever that is, that is the folder the server reads.

Set the world name and start#

The world name is the one setting that decides whether your upload is used. The server takes the -world argument, adds .fwl and .db, and looks for those files. If it finds them it loads them; if it does not, it quietly generates a new world under that name with a random seed.

What the server is actually run with
./valheim_server.x86_64 -nographics -batchmode \    -name "Longship Crew" -port 2456 -world "Midgard" \    -password "a-long-unrelated-phrase" -crossplay \    -saveinterval 600 -backups 4

On a panel you do not type that line; you fill in the world name field on the Startup tab and the panel builds the command. With -world "Midgard" the server looks for Midgard.fwl and Midgard.db. Spaces in world names work, but they are one more thing to get exactly right - if you are naming a new world, a single word saves trouble.

When the server starts, the console says which world it is loading. A line that names your world and then reports the map loading is success. A line about generating a world, or a load that finishes in a second for a world you know is large, means the name did not match. Stop the server, fix the name, start again - your uploaded files have not been touched.

Then join. Your base should be where you left it, each player's explored map should still be revealed, and defeated bosses stay defeated. The explored map is stored in each character's file rather than in the world, so a player who never visited an area will see it unexplored, which is correct.

When the server ignores your world#

Almost every failed transfer is one of these, roughly in order of how often each happens.

A new world appeared instead. The name on the Startup tab does not match the files. Look in worlds_local: you will see your pair and a second pair with the name the server used. Fix the name, delete the new pair, restart.

The world loads, but the terrain is wrong. The .fwl and .db came from different worlds or different points in time - typically a .db from today and a .fwl from a backup. Upload both again from the same folder, at the same moment.

The upload worked, then reverted. The server was running during the upload, and its next save wrote the old world back over the file. Stop it, upload again, and only start it once the files are in place.

The server will not start after the upload. A world saved by a newer game version, a file truncated by an interrupted transfer, or a .db uploaded as text by an FTP client in ASCII mode. Check the file size on the server matches the size on your PC to the byte. SFTP transfers binary by default; if your client has a transfer-mode setting, it should be binary.

Everything is there except my items. Items in your inventory belong to your character, not the world. If you are joining with a different character, you will not have them. Items left in chests are in the world and should be exactly where you put them.

Players see "incompatible version". The server updated and the clients did not, or the other way round. Every client and the server must be on the same build. Restarting the server on most panels pulls the latest version; clients need Steam to finish its update.

Moving a world back, or to another host#

The same two files carry a world in every direction.

To bring a server world back to single player, stop the server, download the pair from worlds_local, and put it in your PC's worlds_local. It appears in the world list the next time you start the game. Doing this once a month is a reasonable habit anyway: it is a copy of the world that no host controls, and a copy you have opened in the game is a copy you know works.

To move from another host, the process is the same with the steps reversed at the old end: stop the old server, download its worlds_local pair, upload to the new one, set the name. Hosts that run on Linux keep the world in the same .config/unity3d/IronGate/Valheim/worlds_local/ path unless they set -savedir; Windows-based hosts usually expose it under AppData or a -savedir of their own choosing. The files themselves are identical across both.

If the world is running mods, move the mods too. A world built with a mod that adds pieces, like Valheim Plus or a building mod, contains objects the vanilla game does not know about. Without the same mod on the new server, those pieces vanish or fail to load. Valheim mods with BepInEx on a server covers which mods need to be on the server and which only on the client.

Keep a copy that is not on the server#

Once your world lives on a server, that server is the only up-to-date copy. Your PC's version stops changing the moment you upload. Treat that seriously.

  • Lower the save interval. The default -saveinterval is 1800 seconds, which means up to thirty minutes of building can be lost to a crash. 600 costs a short hitch every ten minutes and caps the loss.
  • Back up before every game update and before adding any mod. Updates occasionally change the save format, and a world saved by the new version cannot be opened by the old one.
  • Back up somewhere other than `worlds_local`. Valheim's own automatic backups sit next to the world, on the same disk. They protect you from a corrupt save, not from a deleted server or a bad upload.

On RE:NODE every Valheim plan has backup slots, stored off the machine they protect; a backup can be taken on demand, run on a schedule from the Schedules tab, downloaded, and restored with a button. Backups that actually restore explains why the restore half is the part to test. For everything else about running the world once it is up - admins, ports, crossplay codes and world modifiers - the Valheim dedicated server guide is the reference, and Valheim world modifiers and presets covers changing the difficulty of a world you have already moved.

FAQ#

Will my character and inventory carry over?

Yes, because they were never in the world. Characters are stored on each player's PC and travel with them to any server. What stays behind on the old machine is only the world itself, which is what you upload.

Can I upload a world that was played in co-op from inside the game?

Yes. A world hosted with the in-game server option is an ordinary world in the host's worlds_local folder. The person who hosted it sends you the .db and .fwl pair, and you upload it exactly as described here.

Do I need to upload the .old and backup files?

No. Only Name.db and Name.fwl are needed. The .old pair and the timestamped backups are only useful as a recovery copy, and the server creates its own as soon as it saves.

Can I use a world seed instead of uploading files?

Not directly. The dedicated server has no seed setting. Create the world in single player with the seed you want, quit to the menu so the files are written, then upload that pair - the seed travels inside the .fwl.

Can two worlds live on the same server?

Both can be stored in worlds_local, but the server runs one at a time - whichever the world name points at. Switching is a stop, a change of name on the Startup tab, and a start. Each world keeps its own progress.

My group plays on Xbox. Can they join a world I uploaded from PC?

Yes, with crossplay enabled on the server. Xbox players join through the join code the server prints when it starts with crossplay on, and PC players can use the code or the address. The world file does not care which platform the players are on.


Comments

Completely anonymous: no account, no email, no cookie. We store the name you type, the text and the time - nothing else. Links are limited and markup is not rendered.

0/2000