Moving a Valheim world transfer save between a solo session and a dedicated server is the single most common question hitting the subreddit right now, because the 1.0 launch finally pushed the long-promised Deep North biome and the file format tweaks that go with it. If your old world from Early Access is sitting on your PC and you want to bring your friends onto a hosted server, or if you just want the safety net of a backup, the actual process is two files and a folder copy. This guide covers every supported path, the 1.0-specific gotchas, and what Coffee Stain Publishing confirmed about future save compatibility.
Why Valheim World Transfer Matters More After 1.0
The 1.0 release on 2026-09-09 shipped the Deep North biome, full controller rumble, and a rebalanced Mistle biome at the far edge of the procedural map. The change that matters for transfer is structural: pre-1.0 worlds now load with Deep North tiles appended to the unexplored edge of your seed, which means your existing base, portal network, and defeated bosses stay intact while the new content is just out there waiting. That sounds great, but it also means the world file format has been touched, and transferring an Early Access save that has not been opened in 1.0 yet requires the new client to "ingest" it on first load. This ingest step writes a fresh .fwl index file alongside the .db database, and the pair must be copied together or your map preview and minimap break.
For cooperative groups that have been hopping between a friend's PC and a rented dedicated box, valheim world transfer is also the only way to consolidate progress without losing days of portal grinding. Returning players who logged out during the Bog Witch patch and have not touched the game in months will find their saves still load cleanly, but the in-game Haldor trader inventory and the world seed will have rolled to a new biomeset on the map edge. The transfer process does not roll the seed back; it just preserves what you already explored.
What the 1.0 Patch Actually Changed For Saves
| Change | Pre-1.0 Behavior | Post-1.0 Behavior | Transfer Impact |
|---|---|---|---|
| World folder structure | Single .db per world | .db + .fwl index pair | Both files must travel together |
| New biome injection | Not applicable | Deep North generated on first 1.0 load | First transfer triggers ingest, may pause 30-60s |
| Backward compatibility | N/A | Reads EA .db files | One-way upgrade, no downgrade possible |
| Cross-play between PC and console | Not supported | Not supported (as of 1.0) | PC saves cannot move to PS5/Switch 2 |
| Cloud sync via Steam Cloud | Optional per-world | Forced on for single-player | Manual copies bypass Cloud overwrite warning |
According to the Valheim page on Steam, the world saves folder is the canonical location for every copy operation described below. Community data from the Valheim Wiki confirms the file structure has not changed at the directory level, only inside the file headers.
Who Should Bother With Manual Transfer
Most players will never need to touch a single file because Steam Cloud silently syncs single-player .db and .fwl save files between machines signed into the same account, replicating progress the moment Valheim closes cleanly on the source PC. The people who genuinely need a manual valheim world transfer are those whose setup falls outside that automatic cloud-sync path — for example, worlds hosted on a remote dedicated box, characters belonging to a different Steam account, or sessions saved on a NAS that Steam's cloud sync ignores entirely.
-
Co-op admins moving a shared world from a friend's PC to a rented dedicated server (or the reverse)
-
Returning players who want to keep an Early Access world while testing a new seed locally
-
Modded-server hosts who rolled back to a backup after a problematic mod update
-
Content creators archiving a specific build or seed before a public playthrough
If you fall into any of those buckets, the step-by-step that follows covers the three supported destination paths: copying the world folder and .fwl character file directly into a local AppData directory, uploading the .db via a dedicated server's control panel or FTP/SCP, and pushing a backup archive onto a NAS share that Steam Cloud can't reach — each with its own quirks around .fwl/.db ownership, write permissions, and .fwl autosave timing after the Valheim 1.0 Hearth & Home update.
Valheim World Transfer Step By Step (PC, Local And Remote)
The whole operation is built around two facts: every Valheim world is a folder containing a <worldname>.db and a <worldname>.fwl after 1.0, and every install of the game looks in the same on-disk location for those files. Once you know those two facts, every transfer path below is just "copy folder A to folder B and reload."
Where Valheim Stores Your World Files
The default save directory on PC is %AppData%\\LocalLow\\IronGate\\Valheim\\worlds\\ for single-player and locally hosted worlds, while a dedicated server (whether the official valheim_server.exe or a GPortal/Nitrado hosted instance) stores them in <server install>/worlds/. On Linux the equivalent path is ~/.config/unity3d/IronGate/Valheim/worlds/. The worlds folder is shared between single-player and locally hosted servers, so a "local co-op" world and a "solo" world both live in the same place and are interchangeable as long as you copy the matching .db and .fwl pair.
After the 1.0 release reshuffled the save format, a typical worlds folder contains three to four files per saved map, and recognizing each extension is the first step in any Valheim world transfer because mismatched pairs are the most common cause of "world won't load" errors when migrating between a local co-op host and a dedicated valheim_server.exe instance. The .db carries the actual terrain, build pieces, and character-tied data, the .fwl acts as the regenerable index, and the .db.old is the in-place session backup — so before you copy anything for transfer, confirm the three files share the exact world name and matching timestamp.
-
MyWorld.db— the actual world data -
MyWorld.fwl— the world index, regenerated on first 1.0 load -
MyWorld.db.old— auto-backup from the previous session (keep at least one)
The Five Transfer Paths
Five paths, zero overlap: each row is a distinct world transfer scenario with its own file set (.db plus .fwl, the .fwl only, or the full worlds folder) and one extra step that catches most returning players off guard. The "Extra Step" column is where guides usually fail to mention details like Steam Cloud silently overwriting your copied save on next launch, so the table makes that explicit per row before you touch any files.
| From | To | Files To Copy | Extra Step |
|---|---|---|---|
| Single-player (local) | Dedicated server (self-hosted) | .db + .fwl | Stop the server first |
| Dedicated server (self-hosted) | Single-player (local) | .db + .fwl | Bypass Steam Cloud overwrite |
| Single-player PC | Single-player PC (different Steam account) | .db + .fwl | Recipient must own the game |
| Dedicated server | Different dedicated server (hosting swap) | Entire worlds folder | Update worlds_local.zip backup on the new host |
| Early Access world | 1.0 single-player | .db only | First 1.0 load generates .fwl automatically |
The last row is the most common for valheim after 1.0 updates: you played hundreds of hours in Early Access, your save is still a plain .db, and you want to bring it into the new build. The good news is the new client generates the .fwl for you on first load, so you only need to copy one file. The bad news is that first load can take 30 to 60 seconds while the client streams the new biome, and it looks identical to a hang. Give it time.
Transfer #1: Single-Player To Self-Hosted Dedicated Server
This is the canonical valheim world transfer use case for returning players, and it lines up with the post-1.0 file format changes (.db plus .fwl) that Iron Gate introduced to support Steam Cloud world backups. On the PC that currently hosts the solo world, the move is one-way until you decide otherwise, so treat the local save as a checkpoint before promoting it to a dedicated server. The steps that follow assume a clean %AppData%\\LocalLow\\IronGate\\Valheim\\worlds\\ source and a freshly installed Valheim Dedicated Server tool, since cross-folder behavior of worlds_local.zip can otherwise leave Steam Cloud sync out of sync on the first launch.
-
Quit Valheim completely so the world file is unlocked.
-
Navigate to
%AppData%\\LocalLow\\IronGate\\Valheim\\worlds\\. -
Copy the folder named after your world (it contains the .db and, after 1.0, the .fwl).
-
Paste it into
<your dedicated server install>/worlds/. -
Open
worlds_local.zipon the server host and add the new world to the zip if you want Steam Cloud backups to include it. -
Edit
start_headless_server.bat(or your server's admin config) to reference the new world name. -
Launch the server, wait for the "World loaded" log line, then join from the client.
Community data from the r/Valheim subreddit reports that step 4 occasionally fails on Windows due to file locks held by the Valheim Easy Anti-Cheat service. The fix is to also kill the EasyAntiCheat_x64.exe process in Task Manager before copying.
Transfer #2: Dedicated Server Back To Local Single-Player
The reverse path is the one that trips up returning players the most, because Steam Cloud tries to push the older local .db and .fwl over the newer server save and silently overwrites progress, wiping days of 1.0 Mistlands and Ashlands exploration. The conflict happens because Steam Cloud treats both endpoints as authoritative, and the PC with the most recent sync timestamp wins, which is why the destination client must be forced into read-only mode. Skip the read-only flag and the next launch will quietly restore the stale local world, erasing the dedicated server's deep Bonemass, Moder, and Yagluth prep.
-
On the server host, make a manual copy of the .db and .fwl to a safe folder.
-
Launch Valheim on the destination PC, create a throwaway world with any name, then quit. This creates a fresh
worldsfolder Steam Cloud will recognize. -
Quit Valheim again so Steam Cloud flushes.
-
Copy the server's .db and .fwl into
%AppData%\\LocalLow\\IronGate\\Valheim\\worlds\\. -
Right-click the new files, choose Properties, and tick Read-only. This stops Steam Cloud from overwriting them on the next sync.
-
Re-launch Valheim and load the world. The map preview will show the unexplored edge filled with the new 1.0 biomes.
Treating your dedicated host as a staging sandbox before touching the real save is the safest pattern most valheim tips for returning players share, since the Early Access 1.0 Mistlands and Ashlands files take 20–40 minutes to resync over Steam Cloud and a wrong overwrite can erase hundreds of Plains, Mountain, and Swamp boss prep items in one sync. Spin up a duplicate world on the same server, import the .db and .fwl, then verify portal pairs, tombstone caches, and shared map markers render correctly before repeating the transfer on your real Midgard or custom-seeded save with read-only flags reapplied.
Transfer #3: Between Two PC Steam Accounts
Both Steam accounts must be valid Valheim licenses on the active branch before the donor uploads the .db and .fwl pair, since each character, map seed, portal network, and tombstone coordinate is cryptographically tied to the per-account entitlement rather than the world file itself. Iron Gate's per-account DRM means the recipient's Steam library needs Valheim installed and activated, and a family-shared install that hasn't been promoted to a full license will throw a deserialization error on load.
-
Copy the .db + .fwl pair via USB, LAN share, or cloud drive.
-
Place them in the recipient's
worldsfolder. -
Recipient launches the game with online mode disabled for the first load to prevent accidental Cloud sync back to the donor account.
Cross-platform between PC and the new PS5 or Nintendo Switch 2 release is not supported, as confirmed in the Valheim 1.0 release trailer by Iron Gate. Console saves live in a sandboxed container that the PC client cannot read.
What Changed In Valheim 1.0 For Returning Players
The 1.0 build is more than a new biome, and the valheim what changed in 1.0 list is longer than most returning players expect. Coffee Stain Publishing, which has been the publisher since the 2021 Early Access launch out of Skövde, Sweden, used the 1.0 milestone to ship quality-of-life features that have been on the community wishlist for years. The transfer-related items below are the ones that interact directly with world saves. The full 1.0 patch notes, including developer commentary on what made it into this build and what was intentionally held back, are documented in our Valheim Iron Gate News coverage, which pairs especially well with the transfer-related items below since both speak directly to how the world save is handled.
Headline Changes That Touch Existing Worlds
| Feature | 1.0 Status | Effect On Existing Saves |
|---|---|---|
| Deep North biome | Shipped | Appended at unexplored map edge on first 1.0 load |
| Ashlands rework | Live since Bog Witch patch | No migration step needed |
| Map sharing via shareable codes | Live | Works across all post-1.0 worlds |
| Controller rumble | Full support | No save impact |
| **Cross-progression between PC and console | Not supported | Worlds stay platform-locked |
| Steam Deck verified status | Maintained | Cloud sync can be disabled per-world via launch flag |
If you have not loaded a given save since before the Bog Witch patch, expect a one-time "world upgrading" dialog and a 20-40 second wait. The client is not crashing; it is hashing the existing world and reserving a region for the new Deep North tiles. This is also the moment the .fwl file is materialized if it was missing, so any valheim world transfer of an Early Access world should treat that load as a checkpoint.
The Coffee Stain Publishing Side Of The Launch
From a publishing standpoint, valheim coffee stain publishing news around 1.0 has focused on platform expansion and post-launch support. The 1.0 trailer confirmed the same-day PS5 and Nintendo Switch 2 launch, which means a new audience that has never seen a Valheim world will be loading fresh seeds rather than migrating ones. For PC players, the practical impact is a confirmed commitment to keep dedicated server builds synchronized with the client, which is the single most important thing for cross-host transfers. Past Coffee Stain updates (the Hildir's Request event, the Mistlands biome, the Ashlands reveal) have always shipped with server-side hotfixes within 48 hours, and 1.0 has followed the same pattern.
The trailer also shows the Haldor trader with new stock that includes 1.0-exclusive items, which is worth knowing for a transfer because traders are per-world, not per-account. If you have already killed Bonemass in your old world, you have a Haldor inventory that survived the transfer; if you have not, the new items will appear in his stock as soon as you defeat your first Forsaken boss in the imported world.
Hosting Setup And Common Transfer Pitfalls
After the .wld and .db files are moved, most world transfer headaches actually show up after the copy finishes: mismatched world seed registration, leftover .fwl player entries pointing at the old host's IP, and Steam ID re-authorization all surface once you try to reconnect. Getting the files onto the drive is the easy part; the subsections below walk through the hosting scenarios that consistently come up in valheim update today discussions, including the dedicated-server start_headless_server.bat config and the common ports (2456-2458 UDP) that need to stay open after the move.
Self-Hosted Dedicated Server On The Same PC
The simplest path is to keep the same PC as both the client and the dedicated server, just toggling between the two via separate Steam library folders. Copying a world between them uses the same worlds directory on disk, so technically the valheim world transfer becomes a no-op — you just start the server pointing at the existing world name. The wrinkle is that you cannot have the client and the server both writing to the .db at the same time, so always shut the client down before starting the server and vice versa.
Rented Server (GPortal, Nitrado, HostHavoc)
Rented hosts such as GPortal, Nitrado, and HostHavoc expose a web-based file manager that navigates straight to the same worlds directory used in a self-hosted Valheim dedicated server, so the transfer workflow mirrors the local-to-server path almost identically. The key advantage is that no SSH key or remote shell is required — you authenticate through the host's browser panel, drag the .db and matching .fwl files into the right subfolder, and the host writes them to the correct Valheim world save location. The procedure is:
-
Stop the server from the host's web panel.
-
Upload the .db and .fwl pair via the file manager or SFTP.
-
Restart the server and check the log for the "World <name> loaded" line.
-
If the server fails to start with a "world not found" error, the file names do not match the
world-nameline instart_params.bator the host's world config screen.
Rented hosts also enforce a per-server world size cap in the admin panel, which by default is 50 MB. Old worlds that have been heavily explored can exceed this, and the server will refuse to load them until the cap is raised. Community data suggests a safe upper limit of 200 MB for a long-running pre-Mistlands world, with a 500 MB cap required for any save that has explored the Ashlands plus the new Deep North edge.
Pitfalls That Look Like Transfer Bugs But Are Not
| Symptom | Actual Cause | Fix |
|---|---|---|
| Map preview is black after transfer | Missing .fwl index file | Re-load the world once in single-player to regenerate |
| Portals do not connect after moving to a server | Portal tags are world-specific and need re-paired | Re-tag with the portal naming item |
| World appears twice in the server list | Steam Cloud cached the old copy | Clear the local cache and re-sync from server |
| Bosses you already killed are respawned | Wrong .db was copied (e.g. backup file) | Copy the larger of the two .db files and re-test |
| Server boots but clients get "version mismatch" | Client and server on different 1.0.x patch numbers | Force both to the same version via Steam beta opt-in or rollback |
The first row is the single most common confusion around valheim world transfer after 1.0, because the .fwl file is new and was not part of any Early Access world. The community-recommended fix is always to open the world once in single-player first; that single load writes the index, after which the pair is safe to copy anywhere.
Valheim Tips For Returning Players And The Road Ahead
A player who left before Mistlands and is coming back for 1.0 faces the largest content gap the game has ever shipped, and the transfer mechanics above are only the entry point. The valheim tips for returning players below assume the world is already migrated and the player is about to log in for the first time since 2023 or earlier.
Pre-Login Checklist
-
Verify the world file made it intact by checking the file size against your pre-transfer copy.
-
Make sure the .fwl file is present, otherwise the map will be unreadable.
-
Confirm the server and client are on the same 1.0.x patch number.
-
Stockpile Core Wood and Iron before the first Deep North excursion, because the biome's enemies resist non-frost arrows.
-
If the world was heavily explored, raise the server's world size cap before the first launch.
Returning-Player Quick Reference
| Old Habit | New 1.0 Reality |
|---|---|
| Spam wooden clubs at Eikthyr | Still works, but Stagbreaker is now a viable early alternative |
| Ignore Haldor until post-Bonemass | The trader now stocks 1.0-exclusive items from day one |
| Build bases near the spawn meadow | New Deep North edge may overlap with your base perimeter after world upgrade |
| Skip the Bog Witch event | Required to unlock the Mistle biome content |
| Run a Linux server with default settings | Still supported, but 1.0 adds a valheim-server.x86_64 wrapper that handles logs better |
According to community data on the valheim update today front page, the most common returning-player complaint is a 30-60 second "world loading" pause that was not present pre-1.0. That is the Deep North ingest, and it happens exactly once per save.
Where Coffee Stain Is Headed Next
The 1.0 release does not end the roadmap. The Valheim roadmap on Steam still lists post-launch content drops, and Iron Gate has been transparent about a smaller patch cadence now that the version 1.0 milestone is hit. Expect the next few patches to be focused on server stability, console parity, and quality-of-life rather than new biomes, which is good news for valheim after 1.0 updates because it means fewer forced world migrations. The Deep North biome is the final biome, so future world files should remain backward-compatible indefinitely.
Frequently Asked Questions
Will my Early Access world break when I load it in 1.0?
No. The 1.0 client reads pre-1.0 .db files and performs a one-time upgrade that appends Deep North tiles to the unexplored map edge. Your bases, portals, defeated bosses, and inventory all survive intact. The upgrade is non-reversible — once a world has been opened in 1.0, it cannot be loaded in Early Access.
Do I need to copy both the .db and the .fwl for a Valheim world transfer?
For any save that has already been opened in 1.0, yes. The .fwl is the world index file and is required for the map preview and minimap to render. If your save is still from Early Access, you only need the .db; the 1.0 client will generate the .fwl automatically on first load.
Can I transfer a PC world to a PS5 or Nintendo Switch 2?
No. Cross-progression between PC and console is not supported in 1.0, and the world file format is sandboxed inside each platform's save system. PC worlds stay on PC, console worlds stay on console, and the two cannot be merged or migrated in either direction.
What is the safest way to back up a world before a server move?
Stop the server, copy the entire worlds folder to a dated backup directory, then verify the .db file size matches what the server reports in its admin panel. Community testing suggests keeping at least three rolling backups (today, one week ago, one month ago) because a corrupted .db may not show symptoms until several in-game days have passed.
Is the new Deep North biome generated automatically during a transfer?
Yes, but only on the first 1.0 load. The biome is appended to the unexplored edge of the seed, so it does not overwrite your existing terrain. If you want to explore it quickly, sail to the far north edge of your current map; the new tiles are guaranteed to be there after the upgrade.