Iron Gate Studio's official dedicated server documentation offers a closer look at the infrastructure decisions behind one of Steam's most-played survival games. The guide is written for operators, not engineers. But read carefully, it reveals deliberate architectural choices (i.e., two server configurations, a hard player cap, and a community-first hosting philosophy) that any multiplayer developer can learn from.

Indirectly, Valheim's approach shows what happens when a small studio makes infrastructure decisions that scale far beyond what their team could have managed alone.

Two Server Configurations, One Game

Most games ship one networking backend and live with its limitations. Iron Gate shipped two, and the distinction matters for anyone trying to play across platforms.

The Steam backend connects players directly over Valve's networking layer. It is clean, low-overhead, and requires no intermediaries. It also only works for Steam users on PC. A group of friends who are all on Steam, all on the same platform, can run a direct server with no extra setup. But the moment someone on Xbox or PC Game Pass wants to join, that path closes.

The crossplay backend changes the equation. By routing traffic through Microsoft Azure PlayFab Party relay servers, it opens the game to Xbox and PC Game Pass players alongside Steam users. Dedicated servers running in crossplay mode do not require port forwarding, and the relay handles external connectivity automatically. For operators running a persistent world accessible to friends across platforms, a dedicated server with crossplay enabled is the only path.

The choice is made at launch time with a single flag: -crossplay. Include it and you get crossplay. Omit it and you get Steam-only direct connections. Iron Gate documented both configurations openly on their official support page, including the trade-offs of each.

Azure's Relay

PlayFab Party is Microsoft's relay network for game multiplayer. When a Valheim server runs in crossplay mode, it connects to one of Azure's regional relay nodes rather than accepting player connections directly. Players connect to that relay, not the server itself. The relay handles routing between them.

Iron Gate's documentation is candid about what this costs. The Valheim wiki notes that crossplay players are more likely to experience lag, timeouts, and disconnects compared to the direct Steam backend. The relay adds a network hop, and its location is chosen automatically by the server based on proximity to one of around 17 Azure regions. Operators have no input on which relay their players land on. A server in one region can end up routing traffic through a relay that sits far from part of its player group, with no recourse.

This is a trade-off common to relay-based architectures. Relays simplify connectivity and eliminate setup friction, but traffic always takes a longer path than a direct connection would. For studios weighing the same decision, one alternative is replacing a general-purpose relay with a small dedicated server instance deployed close to the player group. A sub-0.25 vCPU game server at an edge location provides server authority without the extra relay hop. Platforms like Edgegap's orchestration network make fractional deployments viable across 615+ global locations, giving studios a way to combine the accessibility of relay-style setups with the latency profile of a direct connection.

Crossplay or Mods: Pick One

The dual server configuration comes with one consequence operators need to plan around: crossplay and mods cannot run simultaneously.

The widely-used mod loader BepInEx hooks into Valheim's Steam networking layer. Enabling crossplay replaces that layer entirely with the PlayFab stack, and when that happens, BepInEx does not load. No mods run. The two networking stacks do not share a common abstraction layer, so there is no hybrid option.

The decision maps cleanly to who is in your player group. A group on Steam can run a modded server on the Steam backend, with direct connections and full mod support. A group that includes Xbox or Game Pass players needs crossplay enabled, and with it, a vanilla server. Operators who know this upfront can plan their server configuration, their mod list, and their player group accordingly. It is a practical constraint, not a failure of design.

The 10-Player Cap

Valheim's object synchronization system uses a structure called a ZDO (Zone Data Object). Every entity in the world — players, creatures, building pieces, tamed animals — is represented as a ZDO. When a ZDO changes state, the full object is re-sent rather than just the changed fields. Simpler to implement and more mod-friendly, but bandwidth-heavy. As player count grows, so does the volume of active ZDOs in a given area, and the total state data per tick scales with it.

Community analysis of the game's networking assembly, documented in detail on James A. Chambers' blog, found hard-coded send and receive rate limits in the ZDO manager. Mods can lift those limits, but community testing found that even with networking mods, performance degrades noticeably approaching 5-6 simultaneous players. The 10-player ceiling is the visible surface of a deeper bandwidth budget. Large player-built structures and tamed animal populations add pressure to that budget independently of player count, which Iron Gate's own documentation acknowledges.

A Free Binary, A Thriving Ecosystem

One of Iron Gate's most consequential infrastructure decisions wasn't technical. It was economic.

The dedicated server binary is free and available to anyone through Steam Tools, with no game purchase required. Iron Gate publishes the full setup guide on their official site, including Docker instructions, launch parameters, admin commands, and backup configuration. They handed operators everything they needed and stepped back.

The effect is that Iron Gate offloaded server costs and operations entirely to the community and to commercial hosting providers. Companies like G-Portal, BisectHosting, and Nitrado now host thousands of Valheim servers, handle DDoS protection, provide control panels, and run customer support — none of which Iron Gate pays for. What might have been a cost center became a distributed hosting supply chain funded by players willing to pay roughly $10-15 per month rather than run their own hardware.

For studios thinking about community servers, this model is worth examining. The free binary strategy works because it creates a market that serves players without requiring the developer to operate it. Studios that want more direct involvement, including the ability to offer server rental from within the game itself with provisioning handled automatically and revenue flowing back to the studio, can explore orchestration platforms built for exactly that. The infrastructure exists. Whether it fits a given studio's business model is a separate question, but the option is real and increasingly accessible.

Portable Worlds

One design detail that reinforces the community-hosted model sits quietly in Iron Gate's setup guide: Valheim's world state is stored in two local files. A .db file contains all world progress, and a .fwl file contains the seed. Both travel with the operator.

There is no cloud lock-in. A group that self-hosts can migrate to a rented server by copying two files. A group renting from one provider can switch to another by downloading a backup and re-uploading it. Iron Gate's documentation treats this as routine, walking through it matter-of-factly.

For players, it means genuine ownership of their world. For developers, it is a reminder that persistence architecture shapes player trust. Worlds that can be held, moved, and backed up are worlds players invest in long-term. Locking world state to a proprietary service might simplify development, but it creates exactly the kind of dependency players notice when things go wrong.

---

[Editor’s note] Unlike other entries in this series, this article draws from Iron Gate Studio's official dedicated server documentation and the Valheim community Wiki rather than a developer conference talk or postmortem. The architectural insights are real and verifiable, are extrapoled from our knowledge rather than directly stated by Iron Gate.

All rights in the original content are owned by their respective owners.