Running multiple Valheim worlds on one host or server

A Valheim server process loads exactly one world, so "several worlds on one host" means one of two things. Either you keep several worlds in the same save folder and switch between them by changing -world and restarting - cheap, simple, one world live at a time - or you run several server processes side by side, each with its own -world, its own -port at least two apart, and preferably its own -savedir, so they share nothing but the machine. The first suits a group that alternates between a main world and a creative or test world. The second suits a group that genuinely plays two worlds at once, and costs roughly twice the memory. Everything else - list files, backups, crossplay codes, mods - follows from which of the two you pick.

The basics of the server itself are in the Valheim dedicated server guide; this post is only about having more than one world.

Two models: switching or running in parallel#

A world that is not loaded is frozen. Nothing grows, nothing despawns, no raid happens and no time passes in it. That makes switching perfectly safe for worlds people visit occasionally - a building world, a seasonal world, the old world you archived - and wrong for two worlds that different people want to play on the same evening.

The memory column is the one people underestimate. Each Valheim server process holds its own copy of everything it needs; two processes do not share memory. A mature world on a mid-size group wants 3-4 GB, a fresh test world less, so two servers side by side want the sum. The general sizing is in how much RAM a Valheim server needs.

How worlds are stored, and why that makes switching easy#

All worlds a server can load live in the worlds_local folder under its save directory. On Linux the default is ~/.config/unity3d/IronGate/Valheim/, on Windows %USERPROFILE%\AppData\LocalLow\IronGate\Valheim\, and -savedir moves the whole tree somewhere else. The savedir and file locations guide has the full layout.

The -world argument names the world to load, and the name is a file name. Several worlds can sit in the same folder without interfering:

worlds_local/  Midgard.db        Midgard.fwl         <- the main world  Workshop.db       Workshop.fwl        <- a creative world  Season1.db        Season1.fwl         <- an archived world

That is the layout on builds before Valheim 1.0. Since 1.0, released in September 2026, a world is stored as a folder named after it inside worlds_local, rather than a .db and .fwl pair, and an older world is converted the first time a 1.0 server loads it. The principle is identical - one name, one world, many worlds side by side - but when you copy, archive or move a world, take the whole folder, not individual files from inside it. Look at what your own worlds_local holds before following any guide written for the other layout.

If -world names something that does not exist, the server creates a new world with that name and a random seed. That is how you make a second world on purpose, and also how a typo silently gives you an empty one.

Switching worlds on one server#

The simplest setup: one server, one port pair, several worlds, one live.

1. Stop the server cleanly so the current world saves. Wait for the save line in the log.
2. Change the world name - on your own machine, edit -world in the start script; on a panel host, the world field on the Startup tab.
3. Start the server and check the log for the world loading by the new name rather than generating.

# Main world./valheim_server.x86_64 -nographics -batchmode -name "Longship Crew" \    -port 2456 -world "Midgard" -password "herring-barrel-42" -crossplay# Switch to the creative world: change only -world and restart#   -world "Workshop"

World modifiers and world keys are stored per world, so a creative world with -setkey nobuildcost keeps that rule only if you pass it on the line that starts it. Put the modifiers in the start line for each world - if you switch back to the main world and leave nobuildcost on the line, the main world gets free building until you notice. Keeping a small text file with the full line for each world is the cheap fix.

What the worlds share in this model: the save directory, and therefore adminlist.txt, bannedlist.txt and permittedlist.txt. A ban applies to every world. That is usually what you want for one group; it is wrong if the second world is for different people.

The other shared thing is mods. One server install means one BepInEx folder, so every world runs the same mod set. A mod that adds content stores its data in the world, and a world opened without the mod can lose that content; do not switch a modded world onto an unmodded line, or the reverse, without a backup.

Running several servers side by side#

To have two worlds live at once you need two server processes. On your own Linux machine that means either two installs or one install started twice with different arguments. Each needs a distinct port pair and, for clean separation, its own save directory.

# Server one - the main world./valheim_server.x86_64 -nographics -batchmode -name "Longship Crew" \    -port 2456 -world "Midgard" -password "herring-barrel-42" \    -savedir /home/valheim/saves/main -crossplay# Server two - a separate world for a second group./valheim_server.x86_64 -nographics -batchmode -name "Raven Fjord" \    -port 2466 -world "Fjord" -password "salt-cod-and-tar" \    -savedir /home/valheim/saves/fjord -crossplay

The rules that make this work:

• Ports at least two apart. Each server uses its game port and the one above it. 2456 and 2457 as two game ports collide, because the second server's game port is the first server's query port. Spacing by ten (2456, 2466, 2476) is a habit that keeps firewall rules readable. Valheim ports 2456-2458 explained covers the detail.
• A save directory each. With separate -savedir paths, worlds, backups and list files are fully separate. Two servers sharing one save directory can work if the world names differ, but they share admin and ban lists, and their automatic backups sit in the same folder.
• Different names in the browser. Two public servers with the same -name are confusing at best. Make them clearly different.
• Never the same world twice. Two processes loading the same world name from the same folder will both save to it, and the last one to save wins. That is a reliable way to corrupt or lose a world.

The -instanceid argument exists for telling instances apart on one machine. Most setups never need it: different world names, different ports and their own save folders already keep two servers apart. The launch arguments reference has its place in the full list.

Running both as services is cleaner than two terminal windows. A systemd unit per server, each with its own ExecStart line, gives each one its own logs, restarts and stop signal. The important part of each unit is that it stops the server with SIGINT, which makes Valheim save before it exits.

[Service]User=valheimWorkingDirectory=/home/valheim/serverExecStart=/home/valheim/server/start_fjord.shKillSignal=SIGINTTimeoutStopSec=120Restart=on-failure

Firewall: open each UDP pair. With ufw that is ufw allow 2456:2457/udp and ufw allow 2466:2467/udp.

Crossplay with more than one server#

Crossplay works per server. Each process started with -crossplay registers its own session and gets its own six-digit join code, printed in its own log at startup:

Session "Raven Fjord" with join code 715204 and IP 203.0.113.10:2466 is active with 0 player(s)

Three things to know when there is more than one:

• Each code belongs to one server. Players on Xbox and the Microsoft Store version join with the code, so a group playing on the second server needs that server's code, not the first one's. Label them clearly wherever you post them.
• Codes change on every restart. Two servers restarting at different times means two codes changing at different times. Scheduling both restarts at the same hour keeps the announcement to one message.
• Steam players can still join by IP. On a crossplay server, 203.0.113.10:2466 still works for Steam players and is the most reliable way to pick the right server.

Crossplay also changes the IDs in the list files to platform-prefixed ones, such as Steam_76561198012345678 and Xbox_.... If one server runs crossplay and the other does not, their admin lists need different formats - another reason to give each its own save directory. Crossplay and Xbox players covers the ID formats and the relay.

Characters move between worlds, and so do their items#

The one consequence of multiple worlds that groups tend to discover late: characters are stored on each player's machine, not on the server, and work in every world. Whatever a character carries in one world arrives with them in another.

That is harmless for a main world and an archived one. It is not harmless when one of the worlds is a creative world with nobuildcost, or one where an admin uses devcommands, or a world with generous resource modifiers. A player can fill their inventory in the easy world and carry it into the hard one. Vanilla has no way to stop it.

The common answers:

• Separate characters per world. The group agrees to use a different character in the creative world. It relies on trust, but among friends it works.
• Treat inventories as dirty. Anyone who visits the creative world empties their inventory into a chest before leaving. Weaker, because the chest is in the creative world and nothing enforces it.
• Accept it. For a casual group the easy world is just a holiday, and carried items are not worth policing.

What is not shared between worlds is the map: exploration is stored per character per world, so each world has its own map for each player.

Backups, updates and mods with several worlds#

Backups. Valheim's automatic backups only cover the loaded world. A world that is switched out is not being backed up, and nothing has changed in it either, so that is fine - but take a copy before you switch a world in after a long break, especially across a game update. With servers in parallel, each process backs up its own world, into its own save directory. Off-machine backups should include every world you care about, not just the live one; Valheim server backups and world corruption has the restore procedure.

Updates. All servers on one install update together, and every world must then be loaded by the new version. Worlds that have not been loaded since an old patch are upgraded the first time they load. Major updates have, at times, changed how worlds are stored - the 1.0 change to a folder per world is the obvious case - so archived worlds deserve a copy before their first load on a new version. Updating the server and version mismatch covers patch timing.

Mods. Parallel servers can run different mod sets only if they are separate installs, each with its own BepInEx folder. One install started twice runs the same plugins for both. If one world is modded and the other vanilla, give each its own install directory.

Doing it on a panel host#

On a panel such as Pterodactyl, a server is one container running one process, so the two models look like this:

• Switching is the Startup tab: change the world name, restart. Every world in worlds_local stays on the server's disk, visible in the file manager, and you can upload or download them there.
• Parallel means a second server: its own container, its own memory limit, its own port allocations, its own console and its own backups.

On RE:NODE that maps directly. Every Valheim plan comes with two ports allocated, which is the game and query pair for one server, and the world name is a field on the Startup tab, so switching is an edit and a restart. Two worlds live at once means two servers, each sized for its own world - a small test world fits the 2 GB plan while the main world sits on a bigger one. Before switching a world, take a backup from the panel; backups are stored off the machine and restore with a button, but a restore brings back the whole server folder, every world in it included.

Troubleshooting#

The server started a fresh world instead of the one I switched to. The name on the line does not match the world in worlds_local, capitals included. The fresh world sits beside the old one; nothing was overwritten. Fix the name and restart.

The second server will not start, or neither shows in the list. A port clash. Check the game ports are at least two apart and that nothing else is bound to them.

A ban on one server applied to the other. They share a save directory and therefore bannedlist.txt. Give each its own -savedir.

The creative world's free building leaked into the main world. The -setkey nobuildcost stayed on the start line when you switched. Remove it, restart, and keep a separate line per world.

Players on Xbox cannot find the second server. They are using the first server's join code, or an old one from before the last restart. Read the current code from the second server's log.

FAQ#

Can one Valheim server process run two worlds at once?

No. A process loads one world. Two live worlds need two processes, each with its own port pair, and on a panel host that means two servers.

Do the worlds I am not running keep changing?

No. An unloaded world is frozen - no time passes, crops do not grow, no raids happen. It resumes exactly where it stopped the next time it is loaded.

Can two servers share the same world file?

They must not. Both would save to it and overwrite each other's changes. Copy the world under a new name if you want a duplicate to play separately.

Do players need different characters for different worlds?

Not technically - any character works in any world - but items carry over, so groups that run a creative or easy world often agree to use separate characters there.

Is a second server cheaper than a bigger one?

Not usually in memory terms, because each process needs its own. A second small server makes sense when the second world is small or occasional; for two busy worlds, budget for both.