Listen Server vs Dedicated Server vs Managed Hosting (2026)
Listen vs dedicated is a topology choice; managed hosting is an operations one. Compare authority, NAT/relay, persistence, cost and scaling separately.
The important correction: listen server vs dedicated server describes where the authoritative game process runs. Self-hosted vs managed hosting describes who operates that process. “Hosted authoritative” is not a third networking topology. A managed provider can host a dedicated server; a player-hosted listen server can use a relay; either topology can talk to a separate persistent backend.
That distinction clears up most of the confusion in “listen server vs dedicated server vs hosted” comparisons.
- Listen server: one player's game process is also the server. That host is authoritative for the session.
- Dedicated server: the authoritative server process runs without a local player.
- Managed hosting/orchestration: somebody else operates, allocates, monitors or scales your dedicated-server processes. It does not change what “dedicated” means.
Two decisions, not three server types
| Decision axis | Option A | Option B |
|---|---|---|
| Who runs the authoritative simulation? | Player machine: listen server | Separate process: dedicated server |
| Who operates the compute? | You/community: home machine, VPS, bare metal, cloud account | Managed hosting/orchestrator/provider |
You can therefore have a self-operated dedicated server, a managed dedicated server, or a listen server carried through a relay service. Mixing topology and operations into one three-column ladder creates false tradeoffs.
Listen server: authoritative, but the host is also a player
Epic's current Unreal documentation describes a listen server as a client that hosts the game and acts as the server. The hosting client is the authoritative host. That matters because “listen server” does not mean “non-authoritative.”
The real tradeoffs are:
- Trust: the host has privileged access to the authoritative process and can modify their machine. That is a poor fit when the host must not be trusted.
- Host advantage: the hosting player participates directly in the true game state while remote players experience network latency.
- Availability: if the host process disappears, the session needs host migration/recovery or it ends. Persistent player/world data can still live in an external backend.
- Connectivity: direct peer connectivity can be awkward behind NAT/firewalls. A relay can give every player a public rendezvous point without converting the game into a dedicated-server topology.
- Resource contention: the host machine is rendering the game and running authoritative simulation/networking at the same time.
Unity Relay is a useful concrete example: Unity explicitly positions Relay for the listen-server pattern. The relay moves packets and hides player addresses; the player host remains the game authority.
Host migration is difficult, not “dead”
A listen server does not have to terminate permanently when its host disappears. You can migrate authority to another client if your networking stack and game architecture support it.
The difficult parts are not a magical “change host” flag. You need a trustworthy handoff of:
- current session state and deterministic/authoritative state ownership;
- connection/session identifiers;
- which candidate becomes the new host;
- what happens when the old host and new host temporarily disagree;
- reconnection and timeout behavior; and
- anti-cheat/trust consequences of moving authority to another player's machine.
For some co-op games, ending/recreating the session is a perfectly reasonable product decision. For others, migration is worth the engineering cost. There is no universal rule.
Dedicated server: authority without a playing host
A dedicated server removes the local-player role from the authoritative process. That typically improves fairness and operational control, but it does not automatically make the game cheat-proof.
Your server still has to validate the decisions that matter. A dedicated process that blindly accepts a client saying “I earned 10,000 gold” is still client-authoritative for that reward.
Dedicated servers are a strong fit when:
- no participating player should own the authoritative process;
- sessions need a stable public endpoint independent of one player's connection;
- competitive fairness matters;
- you need server-side secrets/integrations unavailable to clients; or
- you want predictable server performance independent of a player's PC.
A dedicated server does not have to be “always on”
This is another common category error. A dedicated server can be:
- persistent: one long-lived world/shard that stays up for hours, days or months;
- pooled: ready processes wait for allocations and are reused; or
- ephemeral: allocated for one match/session and then returned to the pool or destroyed.
Agones, for example, models a dedicated GameServer moving from Ready to Allocated and then back to Ready or Shutdown. Allocation and lifecycle are separate from whether the server is “dedicated.”
Managed hosting: operations, not netcode
A managed hosting/orchestration provider can take responsibility for some combination of:
- compute provisioning;
- image/build deployment;
- server allocation;
- health checks and process restart;
- regional capacity/autoscaling;
- public endpoints and network plumbing;
- logs/metrics; and
- patching/host operations.
It does not automatically provide your replication model, game-state synchronization, authoritative gameplay rules, persistence, reconnect semantics or matchmaking. Those are separate product/architecture decisions unless the provider explicitly sells them too.
NAT and port forwarding: depends on where you host
| Topology / deployment | Typical connectivity issue |
|---|---|
| Listen server with direct peer connections | NAT/firewall traversal can require port forwarding, hole punching or a relay |
| Listen server through Relay | Relay provides reachable endpoints; players do not connect directly |
| Dedicated server on a home connection | You may still need router/firewall configuration |
| Dedicated server on cloud/hosting infrastructure | Provider/cloud firewall and port policy replace home-router port forwarding |
“Dedicated server = port forwarding required” is therefore not a topology rule. It is a consequence of where you chose to run it.
Persistence is independent of server topology
A listen server can save durable world/player state to a backend. A dedicated server can keep everything only in memory and lose it on restart. Persistence belongs to the data architecture, not the listen/dedicated label.
For durable games, decide separately:
- what state is authoritative during the live session;
- what state must survive the process;
- who is allowed to commit rewards/progression;
- how writes are made idempotent/retry-safe; and
- how a restarted/reallocated server reconstructs state.
Cost comparison: model the actual operating shape
There is no universal “listen = free, dedicated = VPS, managed = expensive” ladder.
- A listen-server game may pay for relay bandwidth/backend services.
- A community dedicated server may be free because a player donates hardware, or expensive because one underutilized VPS runs 24/7.
- A managed dedicated fleet may cost less at bursty scale if it removes idle capacity, or more if provider markup/egress dominates.
- A persistent world with steady load may favor reserved/bare-metal capacity over per-session orchestration.
Measure server CPU/RAM per session, player-hours, egress, concurrency shape, idle/warm capacity and operational labor. Then compare providers with the same workload.
Where Crux actually fits
Crux's core BaaS is topology-independent: listen servers, dedicated servers and clients can all use it for persistent player data/configuration within the route's credential/trust rules.
Crux Runtime is different. It is currently a capacity-gated closed alpha with a narrow Godot 4 / Linux x86-64 / EU / ephemeral 2-16-player contract. It can execute an admitted dedicated game-server build, but it does not supply your netcode, replication/state synchronization or game rules, and it is not a general Unity/Unreal/global fleet replacement.
Which should you choose?
| Your constraint | Start with |
|---|---|
| Trusted friends, low infrastructure budget, host advantage acceptable | Listen server, often with relay connectivity |
| No player should own authority; competitive/fairness requirements | Dedicated server |
| Persistent community world with stable load | Dedicated server on persistent/reserved/community hosting |
| Many short sessions with bursty/regional demand | Dedicated servers + allocator/orchestrator |
| You want dedicated topology but do not want to operate the fleet | Managed dedicated hosting/orchestration |
First choose where authority belongs. Then choose how the process should be operated. Then choose persistence, matchmaking and networking services around that decision.
Related guides
Sources
Technical, pricing, and product claims were checked against these primary sources on the verification date above.