You do not have to delete anything to start a new Valheim world, and you cannot lose a character by doing it. Characters live on each player's own machine; the server only holds the world. Change the -world name to one that does not exist yet, restart, and the server generates a fresh world beside the old one. Everyone logs in with the same character, the same inventory and the same skills, standing at the sacrificial stones of a map nobody has explored. The only real work is deciding what to do with the old world - archive it properly, because "we will never go back" lasts about a month - and agreeing as a group whether veteran characters are welcome in the new one.
Where worlds and characters actually live#
Most of the confusion about resetting comes from assuming the server stores players. It does not. A Valheim dedicated server stores worlds and three list files, and nothing else about the people who connect to it.
| Thing | Where it lives | Files |
|---|---|---|
| The world | Server, in worlds_local | Name.db, Name.fwl |
| Previous save and automatic backups | Server, beside the world | Name.db.old, Name_backup_auto-... |
| Admin, ban and allow lists | Server, in the save directory | adminlist.txt, bannedlist.txt, permittedlist.txt |
| Characters | Each player's PC | characters_local/<name>.fch |
On Windows, a player's characters are here:
%USERPROFILE%\AppData\LocalLow\IronGate\Valheim\characters_local\A character saved to Steam Cloud sits in a characters folder instead and is synced by Steam. Either way, the server never sees the file; the client sends the character's state when it connects. That is the whole reason a reset cannot touch characters - and, as covered further down, the reason a server cannot stop a player bringing a fully geared character into a fresh world. Valheim save and file locations has every path on both operating systems.
What a character carries into a new world#
Because the character file belongs to the player, almost everything about the character survives the move. A few things are stored on the character but filed under a particular world, so they do not follow.
| Carries over | Does not carry over |
|---|---|
| Inventory and equipped gear | The map you explored (stored per world) |
| Skills and skill levels | Your bed spawn point (stored per world) |
| Known recipes and discovered materials | Boss kills as world progress (global keys) |
| Appearance, beard and hair | Buildings, chests and everything in them |
| The selected Forsaken power | Portals and their tags |
| Food and status effects at logout | Trader stock unlocked by world progress |
The per-world entries are keyed to the world's internal ID, not its name. Delete a world called Midgard and generate a new one with the same name and you still get a blank map and a spawn at the stones, because the new world has a new ID. Go back to the old world later and your map and bed are there again, because the character kept them filed under the old ID.
The global keys line is the one that changes the game. Boss kills on a server are world state - one kill unlocks things for everybody, as boss progression on shared servers explains. A new world starts with no keys, so the raids that depend on world progress and Haldor's later stock reset with it, even though the players themselves have killed every boss. If your server runs with -setkey playerevents, raids are chosen from each player's own progress instead, and that progress belongs to the character, so a veteran on a fresh world can draw raids well beyond what the new world has reached.
Fresh characters or carry-over: decide first#
The technical part takes five minutes. The decision takes a conversation, and it is worth having before the restart rather than after somebody shows up in Ashlands armour on day one.
The usual options:
- Everyone makes a new character. The cleanest restart. It costs nothing on the server; each player simply creates a character in the menu. Old characters stay on their PCs for the old world.
- Carry over everything. Good when the reason for the reset is technical - a corrupt world, a seed nobody liked, a mod pack change - rather than a wish to replay. The group arrives strong and builds fast.
- Carry over skills, leave the gear. Players empty their inventories into a chest in the old world before the switch. Skills and recipes come along; the new world is still progressed from wood and flint. It relies entirely on trust.
- New world, new rules. A reset is a good moment to change world modifiers. If veterans want a challenge,
-preset hardor-modifier combat veryhardon the new world does more than asking people to start naked. World modifiers and presets lists them.
Archiving the old world properly#
Archive first, switch second. The old world is not in danger from the switch itself - changing the name leaves its files untouched - but a server folder is where files go to be deleted by accident months later, and its automatic backups will eventually be trimmed if anyone reuses the name.
A world on disk is more than two files. For a world called Midgard, collect all of these from worlds_local:
Midgard.dbMidgard.fwlMidgard.db.oldMidgard.fwl.oldMidgard_backup_auto-20261011093000.dbMidgard_backup_auto-20261011093000.fwlThe .db and .fwl without suffix are the world. The .old pair is the previous save, which is what you fall back on if the latest save turns out to be damaged. The backup_auto pairs are the rotation the server keeps under -backups. The exact time stamp format of those names has changed between versions; match them by the world name at the start.
- Stop the server cleanly and wait for
World savedand the process to exit. A world copied while running may be mid-write. - Take a panel backup if your host has one, and lock it if it can be locked, so rotation never removes it.
- Download the files above over SFTP or the file manager, and keep them somewhere that is not the server: your PC, a shared drive, object storage. Backups and world corruption explains why a backup on the same disk as the world is not a backup.
- Write down the seed. Select the world in the game's world list on any PC that has the files and the seed is shown. Put it in the archive's file name or a note beside it.
- Leave the files where they are, or move them into a subfolder such as
worlds_local/archive/. The server only loads the world named by-world, so the old files do no harm sitting there.
On a RE:NODE server, backups can be locked against rotation, downloaded from the panel, and are stored off the machine they protect. Note that deleting the server deletes its backups too, locked ones included - the downloaded copy in step 3 is the one that survives the server itself.
Switching to the new world#
With the archive done, the switch is one setting. Pick a new world name: short, letters and digits, no spaces, and different from the old one.
# Before./valheim_server.x86_64 -nographics -batchmode -name "Longship Crew" \ -port 2456 -world "Midgard" -password "herring-barrel-42" -crossplay# After: only the world name changes./valheim_server.x86_64 -nographics -batchmode -name "Longship Crew" \ -port 2456 -world "Midgard2" -password "herring-barrel-42" -crossplayOn a panel host, the world name is a field on the Startup tab; change it there. Then:
- Start the server and watch the log.
- Confirm that it generated a world under the new name rather than loading an old one.
- Join, check you are at the sacrificial stones and the map is blank.
- Tell the group. Players do not need to do anything on their side - the server name, address, password and port are unchanged.
If you want a particular seed for the new world rather than a random one, do not let the server generate it. Create the world locally with that seed, then upload the pair under the new name before step 1. The Valheim seeds guide covers finding a seed and getting it onto the server.
Reusing the same world name
Some groups want the new world to keep the old name, perhaps because scripts or backups refer to it. That works, with one extra step: the old files have to be out of worlds_local before the server starts, otherwise it loads them. Move or rename every file in the list above, including the .old and backup_auto pairs, then start. Leaving old automatic backups beside a new world of the same name is asking for somebody to restore the wrong one in a panic later.
A new name is safer, which is why it is the default advice.
Why not just point -savedir somewhere new
-savedir moves the whole save directory, and the three list files live in it. Starting with an empty save directory gives you a fresh world and also an empty adminlist.txt, an empty bannedlist.txt and an empty permittedlist.txt. Your admins lose their rights, banned players can come back, and an allow-list server becomes open to anyone with the password. If you do change -savedir, copy the three list files across first. The adminlist, bannedlist and permittedlist guide covers their format.
Going back, or running both#
One server runs one world at a time. To return to the old world, stop the server, set the world name back to Midgard, and start. Characters find their old map and bed waiting, because those were filed under the old world's ID all along. Everything they carried into the new world comes back with them, though, and whatever they left in the new world stays there - inventory belongs to the character, not to a world.
Switching back and forth is fine for a weekend; as a habit it makes item duplication trivial, since a character can fill up in one world and empty into chests in the other. If your group wants two worlds running permanently, the clean answer is two servers, each with its own name, port and save directory. Two instances on one machine need different -port values at least two apart, because each uses its port and the next one up.
When a mod pack changes with the reset#
Resets often come with a new mod list - a different overhaul, a new content pack. Characters carry over items, and items from a mod that is no longer installed are a known source of trouble: they vanish from inventories, or in the worst case the game fails to load the character. Before switching packs, players who want to keep their characters should store modded items in the old world first. Unmodded characters going into a modded world are fine; the reverse is where items disappear.
Make the server's mod list final before the first player connects to the new world, and give the group the exact profile to install - r2modman profiles for a group is the least painful way. Players connecting with mismatched sets get kicked, as covered in mod version mismatch kicks.
Enforcing a fresh start with server-side characters#
If carry-over has to be prevented rather than discouraged, the server has to own the characters. Vanilla Valheim cannot, but mods can. ServerCharacters (by Smoothbrain, on Thunderstore) is the usual choice: it stores character data on the server, so players use a character that only exists there and cannot bring one in from elsewhere. It has to be installed on the server and on every client, which rules out Xbox players, and it changes how backups work, because characters are now part of the server's files. Read the mod's own page for the current version and setup - it is updated with the game and the details move.
For most private groups this is unnecessary. A conversation and a chest in the old world do the job.
Troubleshooting#
The server loaded the old world. The new name matches an existing file, perhaps from an earlier test. Check the log for the name it loaded and look in worlds_local.
A player says their character is gone. Their character is on their PC. Ask them to check the character select screen; if they recently moved PCs or reinstalled, it may be in Steam Cloud rather than characters_local, or not backed up at all. The server cannot help, because it never had it.
Admins lost their rights after the reset. The save directory changed, so adminlist.txt is a new, empty file. Copy the old list files in.
The new world has the old world's difficulty. The -preset, -modifier and -setkey arguments are still on the start line, so they apply to whatever world loads. Change or remove them along with the world name if the new world should play differently.
FAQ#
Will resetting the world delete our characters?
No. Characters are stored on each player's machine and the server never holds them. A new world changes nothing about them except that their map and bed spawn start empty there.
Can I keep the same server name, password and IP?
Yes. Only -world changes. Players join exactly as before and the server list shows the same entry.
Do boss powers carry over?
The power selected at the time of the switch travels with the character. Boss progression for the world does not: the new world has no boss keys until someone kills the bosses there.
Can I wipe only buildings and keep the terrain?
Not with vanilla tools. Buildings and terrain changes are both in the .db. A new world on the same seed gives you the same untouched terrain with nothing built on it.
How do I stop people bringing late-game gear into the new world?
Ask them to bank it first, or require new characters. Enforcing it needs a server-side character mod, because the vanilla server accepts any character file.


