Guide
Game dedicated servers explained
Harbor Arena launched casual 4v4 with a listen server: whoever hosted the lobby also ran the simulation. It worked for friends on the same coast, but ranked play exposed the cracks. The host had zero input delay while everyone else ate their RTT twice. When the host's Wi-Fi dropped, the match died. Players filed “host advantage” tickets faster than the support team could close them. Season 2 moved ranked matches to dedicated servers — headless instances in Virginia, Frankfurt, and Singapore provisioned on demand. Dispute volume fell 70%, average perceived input lag dropped 35 ms for non-host players, and the esports bracket could finally enforce consistent tick rate. A dedicated game server is a machine (physical or virtual) that runs only the authoritative simulation — no rendering, no local player advantage. This guide covers dedicated vs listen-server vs peer-to-peer topologies, headless builds and tick-rate budgeting, cloud and managed hosting options, regional deployment, match lifecycle orchestration, integration with matchmaking and anti-cheat, a Harbor Arena worked example, a hosting decision table, common pitfalls, and a production checklist.
What a dedicated server actually does
In a server-authoritative multiplayer game, one process owns the truth: player positions, projectile hits, objective state, loot rolls. Clients send inputs; the server advances simulation; clients render interpolated snapshots. A dedicated server is that authoritative process running on infrastructure you control, separate from any player's gaming PC or console.
Dedicated servers are almost always headless: they compile
without graphics, audio, or UI subsystems. Unity and Unreal both support
dedicated-server targets; custom engines typically ship a -server
binary with stubbed rendering. Headless builds reduce memory footprint, boot
time, and attack surface — there is no GPU driver to crash and no player
sitting at the keyboard to alt-tab out mid-match.
The dedicated server is not the same thing as netcode. Netcode is how clients and servers synchronize state (prediction, rollback, lag compensation). Dedicated hosting is where the authoritative simulation runs. You need both for fair competitive play at scale.
Dedicated vs listen-server vs peer-to-peer
Three multiplayer topologies dominate modern games. Each trades cost, fairness, and complexity differently.
Dedicated server (best for competitive fairness)
A neutral machine simulates the match. Every player has similar network distance to authority. No one gets free zero-latency movement. Cheating is harder because clients cannot directly mutate authoritative state. Cost: you pay for compute 24/7 or spin instances per match.
Listen server (host plays on the same machine)
One player's client doubles as the server. Cheap to ship — no hosting bill — but the host sees the world one RTT earlier than everyone else. If the host quits or their connection degrades, the match ends. Common in co-op and early-access titles; rarely acceptable for ranked PvP.
Peer-to-peer (lockstep or host migration)
Players exchange inputs directly without a persistent authority. Works for low-player-count fighters with rollback (GGPO) or turn-based games. Becomes fragile at scale: NAT traversal failures, desync on physics-heavy worlds, and no central place to run server-side validation. Some titles use P2P for casual and dedicated for ranked.
Tick rate, CPU budget, and simulation cost
The server advances the world in discrete ticks per second (often 20, 30, 64, or 128). Higher tick rate means finer time resolution for hit registration and movement — but linearly more CPU per player slot. A 64-tick 10-player shooter might consume one full modern CPU core; doubling to 128-tick doubles simulation cost without doubling player satisfaction.
Budget before you provision:
- Fixed timestep loop — decouple simulation from variable frame rate; never let a slow tick cascade into spiral-of-death lag.
- Interest management — only replicate entities each client cares about; a BR with 100 players cannot broadcast full world state every tick.
- Physics granularity — server-side ragdolls and destruction multiply cost; simplify or offload cosmetic physics to clients.
- Profiling on headless builds — desktop FPS is meaningless; measure microseconds per tick under worst-case player counts.
Publish your target tick rate and treat it as a service-level commitment for ranked modes. Dropping from 64 to 30 tick mid-season without announcement destroys trust faster than a balance patch.
Hosting models: where dedicated servers live
Self-managed cloud VMs
Rent bare VMs (AWS EC2, GCP Compute, Hetzner, OVH) and run your server binary under systemd, Kubernetes, or Agones. Maximum control: custom networking, autoscaling policies, and cost optimization via spot/preemptible instances. You own patching, DDoS mitigation, and orchestration.
Managed game server hosting (GSH)
Platforms like Hathora, Edgegap, or PlayFab Multiplayer Servers abstract fleet management: upload a container or build artifact, define regions and scaling rules, call an API to start a match. Higher per-hour cost, lower engineering overhead. Good for small teams shipping their first online mode.
On-premise and esports LAN
Tournament LANs sometimes run local dedicated hardware for sub-1 ms server-side latency. Not relevant for consumer live ops, but the same headless binary usually powers both cloud and LAN — keep configs portable.
Regardless of provider, run servers in regions close to players. A 150 ms RTT cap for ranked play implies picking datacenters within ~75 ms geographic reach of your player clusters. Cross-region matchmaking without regional servers guarantees unhappy players.
Match lifecycle: provision, warmup, run, teardown
A live game does not keep 10,000 servers running idle. Typical flow:
- Matchmaking forms a lobby and selects region + game mode.
- Allocation requests a server instance (API call to GSH or internal orchestrator). Cold starts matter: container pull + boot can take 15–60 s if not pre-warmed.
- Registration clients receive IP/port or relay token; authenticate with a session ticket bound to the match ID.
- Warmup players load assets while the server pre-simulates or holds in a ready room; start when all clients ack or timeout.
- Run authoritative simulation until win condition or disconnect threshold.
- Teardown upload stats, replay buffers, anti-cheat telemetry; kill the process; release compute.
Idempotent allocation is critical: if a client retries join after a timeout, they must land on the same match, not spawn a duplicate server. Store match state in a durable queue (Redis, DynamoDB) keyed by match ID.
Security, anti-cheat, and observability
Dedicated servers are your trust anchor. Server-side validation of movement speed, fire rate, and inventory changes catches naive client tampering before it affects other players. Pair simulation checks with kernel-level or behavioral anti-cheat on clients, but never rely on client-only enforcement for economy or ranked integrity.
Instrument every instance:
- Tick duration histogram (p50, p95, p99) — alert when p99 exceeds budget.
- Per-player bandwidth and packet loss.
- Allocation-to-first-player-joined latency.
- Crash dumps with build version and match ID.
Structured logs shipped to your observability stack (see observability guide for patterns) let you correlate a spike in “laggy server” reports with a bad deploy or undersized instance type.
Worked example: Harbor Arena ranked refactor
Harbor Arena's Season 2 ranked pipeline:
- Topology split: casual quick-play stayed on listen servers; ranked and tournament brackets required dedicated.
- Headless Unreal build stripped rendering; 64-tick simulation with lag-compensated hitscan (see netcode guide).
- Three regions: us-east-1, eu-central-1, ap-southeast-1; matchmaking pinned players to lowest-ping region with 120 ms hard cap.
- Container fleet: one match per c6i.large-equivalent instance; orchestrator kept two warm containers per region to hide cold-start latency.
- Session tickets: JWT signed by backend, validated on server connect; prevented mid-match random joins.
- Results: host-advantage tickets down 70%; esports observers could spectate via delayed broadcast feed without joining the sim process.
The refactor took six engineer-weeks — mostly orchestration and matchmaking integration, not netcode rewrites. The listen-server code path remained for offline bot matches and LAN parties.
Hosting topology decision table
| Topology | Best for | Fairness | Hosting cost | Ops complexity |
|---|---|---|---|---|
| Dedicated cloud | Ranked PvP, BR, esports | High | Medium–high | Medium |
| Listen server | Co-op, small-party casual | Low (host advantage) | None | Low |
| P2P + rollback | 1v1 fighters, turn-based | Medium (symmetric) | None | Medium (NAT) |
| Managed GSH | Indie first online ship | High | High per hour | Low |
| Hybrid (casual P2P / ranked dedicated) | Games scaling from beta to live | Mode-dependent | Variable | Medium |
Common pitfalls
- Shipping ranked on listen servers. Players will measure host advantage with frame counters and leave.
- Ignoring cold-start latency. A 45-second “waiting for server” spinner kills conversion; pre-warm pools per region.
- Single global region. EU players on a US-only fleet will not stick around for ranked.
- Oversized tick rate without CPU headroom. 128-tick sounds marketing-friendly until the server falls behind and stutters every match.
- No session authentication. Open IPs get scanned; griefers join private matches.
- Running GPU workloads on dedicated sim. Headless means headless; never require a GPU on the instance.
- Forgetting teardown on crash. Zombie instances leak money; use TTLs and health checks.
- Desync between client and server builds. Version-gate on connect; reject mismatched protocol hashes.
Production checklist
- Ship a headless server binary in CI alongside client builds; version them together.
- Profile max tick duration at target player count + worst-case map on server hardware class.
- Deploy at least two regions before launching ranked PvP.
- Pre-warm server pools in each region during peak hours.
- Sign session tickets; validate on connect; bind to match ID.
- Log tick p99, allocation latency, and per-match outcome to observability stack.
- Automate teardown with guaranteed cleanup on crash or match end.
- Document tick rate and region list in player-facing patch notes.
- Load-test orchestrator with 2x expected concurrent match starts.
- Keep listen-server or offline path for LAN and bot training without cloud dependency.
Key takeaways
- Dedicated servers remove host advantage. For any ranked PvP, they are table stakes.
- Headless builds cut cost and boot time. Strip rendering; measure server-side tick budget.
- Region beats raw tick rate. 64-tick at 40 ms RTT beats 128-tick at 150 ms.
- Orchestration is half the work. Provision, authenticate, warm, teardown — reliably.
- Hybrid topologies are fine. Casual can stay cheap; competitive earns the hosting bill.
Related reading
- Game netcode and multiplayer networking explained — prediction, rollback, lag compensation, and tick synchronization
- Game matchmaking explained — skill buckets, queues, and pairing players with the right server region
- Game anti-cheat explained — server validation, client integrity, and ranked trust
- Game spectator mode and esports design explained — broadcast feeds and tournament production on dedicated infrastructure