Give each Valheim instance its own save directory, launch configuration and non-overlapping ports. Start and verify the second instance independently before running both together. Two names in a panel do not establish that the underlying processes write different data.
This guide extends an existing working Linux dedicated server. You need control of its service or container configuration, persistent storage and firewall. If the first instance cannot be joined reliably, resolve that before cloning its setup; otherwise every failure has two possible causes.
Allocate the second instance before copying anything#
Record the first server's real executable directory, operating-system account, launcher, selected world, save root, logs and update schedule. Resolve relative paths against the service's working directory. A launch performed manually under your account can use different data from the same script started as a service.
Use a small allocation sheet. These names and paths are examples, not required directory conventions:
| Setting | Main instance | Second instance |
|---|---|---|
| Installation directory | /srv/valheim/main/server | /srv/valheim/workshop/server |
| Save root | /srv/valheim/main/saves | /srv/valheim/workshop/saves |
| World selection | MainWorld | WorkshopWorld |
| UDP base port | 2456 | 2466 |
| Base port plus one | 2457 | 2467 |
| Service or container name | valheim-main | valheim-workshop |
The gap between the example port pairs makes allocation easier to inspect; ten is not a Valheim requirement. Check all sockets required by your chosen backend and plugins, rather than assuming the base game is the only listener. Reserve separate management endpoints too if your wrapper adds them.
Separate installation directories are a practical choice when instances have different mods or maintenance windows. A shared installation couples their binaries and plugins: updating files for one can change the other while it is running. Two directories still share VPS resources and the operating system; they do not provide a second machine's fault isolation.
Create an independent data destination#
Create the second save root with permissions for its actual service account. For a new world, leave that root empty and select a new world name. For a copy of an existing world, stop its writer gracefully, preserve the complete save tree, and copy the required data into the second destination before starting it. Do not let either instance resolve to the same writable files through a symlink or shared volume.
Valheim 1.0 worlds can occupy folders containing multiple parts; old worlds can use a .db/.fwl pair. A copy rule matching only those two extensions is unsuitable as a universal backup. Preserve the complete stopped save root and retain an untouched recovery copy.
Review copied access lists. A second world for another group should not inherit the first group's administrators or permitted players accidentally. Distinct world names help humans identify instances, but separate writable directories are the important boundary.
For containers, inspect host-side volume sources. Two containers may both use /config internally, provided each maps to a different persistent directory on the host. Different container names alone do not make shared mounts independent.
Configure two launchers and two service controls#
Make a custom launcher for each instance from its working server script. Preserve the script's runtime environment and executable invocation; change the instance values rather than replacing it with an incomplete command copied from a forum.
Set -port, -world and -savedir from the allocation sheet. Use distinguishable server names, separate log destinations and strong joining passwords. Do not reuse the world name as a password. Keep the custom scripts outside an updater's replacement path, or maintain a protected source copy and compare supplied script changes after updates.
Create a separate service or container definition pointing to each launcher. Give it the correct account and working directory. Configure a graceful stop and sufficient time for saving; a service being marked stopped does not prove a forced termination saved the world.
In LinuxGSM, put differing settings in the matching instance configuration, not its shared common.cfg or generated _default.cfg. In another manager, confirm which fields belong to the instance and which are global.
Verify the connection route for each backend#
For Steam networking, allow each instance's required UDP pair through both the host and provider firewall. If the VPS sits behind NAT, map each pair to that host without overlap. Players using Valheim's Join IP connect to the base port; do not substitute a Steam browser query endpoint blindly.
Crossplay uses the PlayFab relay and has a different connection path. Iron Gate says it does not need router port forwarding and cannot be joined through a local or loopback address. Keep distinct configured ports even with crossplay. Its -instanceid option addresses the documented same-port/same-MAC identity case; it does not make two processes safely share host sockets or save files.
Use a current join code or public endpoint for each crossplay instance. If a client keeps reaching an old backend, remove the stale recent-server entry and add the intended destination again.
Prove independence while both servers run#
First start the second instance alone and inspect its world selection, data path and startup errors. Join it, inspect a known location or the intended new world, then stop it cleanly. Start both instances and repeat joins to each with their distinct destinations.
Make a harmless recognizable change in each world. Stop and restart only the second server; confirm the first remains connected and each world retains its own change. Repeat the save/restart check for the first. These checks establish more than a running process or a visible browser entry.
If either instance works alone but fails beside the other, inspect socket overlap, shared writable paths and combined memory/CPU pressure. If both destinations show the same world, compare effective arguments and mounts before copying more data. Stop the unwanted writer before attempting recovery.
Stagger updates and backup jobs, and label archives by instance as well as time. When organizing services on your own VPS, Nexardo provides an infrastructure management workflow; the allocation sheet and separate recovery copies remain useful alongside it.
