Valheim Dedicated Server Guide: Host, Rent, or Use Crossplay?

Choose the lightest hosting model that solves the problem

Start with the schedule, not the hardware. Valheim can create a private peer-to-peer session from the game, and that is enough when the group always plays together under the same host. It has the fewest moving parts: the host launches the world, friends join, and the session closes when the host leaves. A dedicated server adds value only when players need to enter the same world at different times or the group wants a machine whose main job is keeping that world available.

Self-hosting fits a group with a spare computer or always-on machine, stable network access, and at least one person willing to own updates and recovery. Renting fits a group that values a persistent world but does not want to expose a home network, keep hardware running, or depend on one member being available. Rental is an operating choice, not proof of better play. Compare control-panel access, world export, backup download, server location, support, and cancellation before comparing headline slot counts.

Do not migrate because someone assumes the word “dedicated” removes every lag source. Community questions repeatedly report groups discovering that a separate machine did not solve their crowded-base or mixed-network problems. Treat hosting as a persistence and ownership decision first. If the current session works when the host is online, run one controlled comparison before paying for a long plan or rebuilding the world elsewhere.

• Hosted session: same host, same schedule, minimum administration.
• Self-hosted server: persistent access, maximum control, named operator required.
• Rented server: persistent access without home hardware, recurring cost and provider dependence.

Pick Steam or crossplay before opening the world

The official dedicated-server guide describes two connection backends. The Steam backend is for Steam users and normally requires the chosen UDP port range to be reachable through the router and firewall; the default server port uses 2456 and the next port. The crossplay backend is enabled with the official crossplay launch option and uses a relay, so the operator does not need ordinary port forwarding for outside access.

Choose crossplay when Xbox or Microsoft Store players must join the current public game, or when the group deliberately wants the relay path. Xbox consoles can join a crossplay-enabled dedicated server but cannot run the dedicated server application themselves. Choose the Steam backend when every player uses Steam and the operator is comfortable maintaining direct network access. Do not copy a future-platform setup article into the current server: announced 1.0 platforms are preview facts until those clients publicly release and the connection flow is reviewed.

Test the chosen backend with the exact mix of stores and devices the group will use. Confirm that a second player can join from outside the host network, reconnect after a restart, and find the server through the intended method. Record the backend and join instructions in the group note so a later operator does not remove the crossplay option or change router rules without knowing why they exist.

Create a reversible first launch

Install the official Valheim Dedicated Server tool and copy its launch script before editing it. Iron Gate warns that the original script can be reset by a Steam update, so the group should keep its named copy and a separate text record of the launch arguments. Set a server name, world name, strong password, visibility choice, and backend intentionally. Never publish the password in a screenshot, shared guide, public issue, or command history that other people can read.

For an existing world, stop the old host cleanly and make a copy before moving files. Preserve the original until the dedicated server has loaded the expected map, structures, boss state, and world modifiers. A migration is not complete because the server appears in a list. Join at a known base, inspect portals and storage, sleep or wait through a save cycle, leave, restart the service, and join again before inviting the full group.

Keep the first launch narrow. Use the current public build, no new mods, and the same world settings the group already understands. Server-side modifier flags can change combat, resources, raids, portals, death penalties, or map behavior; adding them during a hosting migration makes it difficult to separate a server mistake from a deliberate rules change. Move first, verify, then discuss one modifier change at a time.

Launch with a backup and shutdown routine

Name a primary operator and a backup operator before the world becomes important. Both should know where the live save directory is, where a dated copy is stored, how to read the server log, how to update the application, and how to stop it cleanly. A persistent world without a recovery owner is merely an always-available single point of failure.

Use the server’s documented save and backup controls as a baseline, but keep an independent copy outside the active save directory before updates, migrations, mod changes, or major world-setting changes. Test restoration with a disposable copy instead of waiting for a real loss to discover that the backup path was wrong. The useful question is not “Do we have backups?” but “Which file can the second operator restore, and when was that exact process last tested?”

Agree on shutdown etiquette. Announce planned restarts, wait for players to leave dangerous areas, allow the world to save, and stop the process through the documented method rather than killing power to the machine. After an update, verify the public game version, connect with an ordinary player account, and check one known location before declaring the server open.

Set group rules before persistence creates conflict

A server that stays online changes social progression. One player can explore, defeat a boss, consume shared metal, move portals, or advance raid conditions while everyone else is away. Decide whether bosses require a quorum, which materials are communal, whether map discoveries should be shared in advance, and how far solo exploration may go. Persistence works best when it protects flexible schedules without turning the shared world into several incompatible campaigns.

Use the progression checklist as a lightweight shared record. Mark the current biome gate, next group boss, infrastructure goal, and supplies that may be spent freely. Pair it with a short operator note containing the backend, world name, modifier baseline, last backup date, and restart contact. That gives returning members the context to join safely without exposing passwords or private network details.

Keep mods out of the first decision unless the group already runs a controlled mod pack. Mods add client compatibility, update timing, and recovery questions that are separate from choosing hosted, self-hosted, or rented infrastructure. Establish a stable vanilla server and tested restore path first; if the group later adds mods, copy the world, document the exact versions, and treat the change as its own reversible project.