Valheim dedicated server vs in-game hosting, when to switch

Valheim's "host a game in-game" feature is convenient. It's also the source of a lot of group frustration after about three weeks. This article explains when in-game hosting is the right choice, when to migrate to a dedicated server, and how to do it without losing your world.

What in-game hosting actually is

When a player hosts in-game, the world runs on their machine. Their PC handles all the simulation. Their internet pipes carry everyone else's traffic. The world only exists while they are online.

This is fine when:

• You have one dependable host whose schedule sets the play calendar.
• The group plays together synchronously.
• The host has a reasonable PC and connection.
• No one feels chained to the host being available.

It stops being fine when:

• The host has to leave town for a weekend and the world goes with them.
• Other players want to log in to do quick tasks (planting, building, harvesting) during off-hours.
• The host's connection has hiccups that affect everyone.
• The host's PC is doing other heavy stuff (gaming, streaming, work) during play.

The "tied to the host" problem

This is the most common reason groups migrate. The host realizes they've become a scheduling bottleneck. Their PC is "the world." Their availability is the group's availability.

For a casual 4-friend group playing together, this is mild. For a 6+ player group with mixed schedules, it gets old fast.

When to migrate

Signals it's time:

• Players asking "can we play even if Steve isn't on?"
• Disagreement about whose machine should host.
• The host's PC is starting to lag with everyone connected.
• You want the world to persist 24/7.

If any of these have come up twice, migrate.

How a dedicated server differs

A dedicated server is:

• Always running (you can shut it down, but typically it stays up).
• Decoupled from any player's PC.
• Persistent across player logins.
• Hosted on paid hosting or a dedicated home machine.

Players still need to own Valheim. They connect to the dedicated server like they would any other server.

Getting the world out of in-game and into dedicated

Step-by-step. Assumes you're moving an existing world.

1. Find the world files

On the in-game host's PC, Valheim stores worlds in:

• Windows: %USERPROFILE%\AppData\LocalLow\IronGate\Valheim\worlds_local\
• Linux: ~/.config/unity3d/IronGate/Valheim/worlds_local/
• macOS: ~/Library/Application Support/unity.IronGate.Valheim/worlds_local/

Each world has up to four files:

WorldName.db
WorldName.db.old
WorldName.fwl
WorldName.fwl.old

The .db is the world state. The .fwl is metadata (seed, etc.). The .old files are previous saves; bring them along as backups.

2. Set up the dedicated server

If using paid hosting: most hosts have a one-click Valheim install. After provisioning, you'll have an empty server with a default world.

If self-hosting: download Valheim's dedicated server tools from Steam (in your Steam library, "Tools" section). Install on the target machine. Configure as needed.

The dedicated server's save directory is worlds_local/ on a current install (older installs may still use worlds/; check what's actually there before uploading).

3. Upload the world files

Stop the dedicated server first. Then upload WorldName.db and WorldName.fwl (plus .old variants if you have them) to the server's worlds_local/ directory.

4. Configure the server to use this world

Edit the start script or config:

./valheim_server.x86_64 -nographics -batchmode -name "MyServer" -port 2456 -world "WorldName" -password "yourpassword"

The -world argument must match the filename (without extension).

-password is mandatory for any Valheim dedicated server and must be at least 5 characters; the process will refuse to start otherwise. Pick something memorable but not trivial.

5. Start the server and test

Boot. Watch the log. The server should report loading your world.

From a client, add the server (Steam servers list, or "join by IP" if needed). Connect. Confirm you spawn at your previous location with your usual inventory.

6. Tell the rest of the group

Once it works for you, share the new connection info with the group. Set a cutover time. After cutover, the in-game host can stop hosting.

7. Archive the original world files

Don't delete the original files from the host's PC. Keep them for at least a month as a fallback. If anything goes wrong on the dedicated server in the first weeks, you can re-restore.

What you gain and what you lose

Gain	Lose
24/7 uptime	A few dollars/month or some power+wear
Anyone can log in at any time	"The host is the de facto leader" dynamic
Host no longer single point of failure	Simpler "just open Valheim and host" model
Host's PC freed up
Host's internet hiccups don't drop everyone

A note on world progress and items

The .db file is the whole world: terrain, all built structures, all dropped items, all mob NBT, all dungeons cleared or not. Bringing it over preserves everything.

What is NOT in the world file:

• Player characters. Each player's character (inventory, skills, appearance) is stored on their own PC. The character lives client-side. When you connect to any server, your character data goes with you.

This means: bringing the world over to a new server preserves the world. Players bring their characters as-is. Nothing is lost.

Common mistakes

Forgetting the .fwl file. A .db without its matching .fwl is unusable. Take both.

Starting the dedicated server before uploading the world. It'll generate a new world with the same name and overwrite your upload. Always upload with the server stopped.

Mismatched Valheim versions. The dedicated server tools and the players' games must be the same major version. If you've migrated and players are on a different version, expect connection failures. Update everyone.

Not setting a password. Public Valheim servers without passwords get spammed and griefed. Always set one.

When NOT to migrate

If your group is genuinely happy with in-game hosting, don't move just because you "should." The simpler setup has its appeal. Migrate only when there's a real reason.

Conclusion

In-game hosting is great for tight groups with one reliable host. Dedicated hosting is better when you outgrow that pattern. The migration is straightforward (one .db and one .fwl file). The hard part is timing the cutover socially and committing to the new model. Once you've done it, you'll usually never go back.