Unreal Engine 5 Multiplayer
Unreal Engine 5 multiplayer server
How UE5 handles multiplayer — dedicated vs listen servers, the Online Subsystem, actor replication, server travel, and how your hosting layer fits into the picture.
Updated July 6, 2026
TL;DR
- Dedicated server = authoritative, no player host — use for competitive, ranked, or anti-cheat-sensitive games. Listen server = host-is-a-player, simpler operationally, host has a latency edge.
- Replication is the core model — properties and RPCs flow from the server to clients. Every replicated Actor adds to your server's CPU budget. Bare metal gives predictable headroom.
- Online Subsystem (OSS) is optional — it's UE's platform abstraction for sessions, presence, and voice. You can bypass it entirely and call an external session API from your backend.
- Hosting is separate from architecture — your server binary runs the same regardless of where it's hosted. Gameye runs it as a Linux container, no UE plugin required.
Adding multiplayer to a UE5 game means making a series of architectural decisions before you write a line of replication code: dedicated or listen server, which Online Subsystem (if any), how sessions are created and found, and how players travel between maps. These choices determine your server's CPU profile, your anti-cheat surface, and how much operational complexity you take on.
This guide covers the UE5 engine-level multiplayer model. For packaging your server binary into a container and deploying it, see the UE5 dedicated server Docker guide. For full hosting and ops details, see Unreal Engine dedicated server hosting.
Dedicated server vs listen server: which should you use?
UE5 supports two server topologies. The choice affects authority, latency fairness, and operational cost.
- Server process has no player attached — pure authority
- No host advantage: all clients have equal latency to the server
- Session survives individual player disconnects
- Required for server-side anti-cheat
- Higher operational cost — you provision and run the server
Use for: competitive shooters, ranked modes, games with real-money stakes, any title where fairness and session persistence matter.
- One player's machine also runs the server process
- Host has a latency advantage (zero round-trip to themselves)
- Session ends when the host disconnects
- Client-side authority — harder to prevent cheating
- Zero server cost — no infrastructure to run
Use for: cooperative games, casual modes, LAN play, early prototyping before you invest in server infrastructure.
Most studios shipping a competitive or live-service game use dedicated servers. The operational cost is predictable, the anti-cheat surface is smaller, and players expect fair latency. Listen servers are a shortcut for early builds and co-op titles where the host advantage is acceptable.
How UE5 multiplayer works: the core model
UE5's multiplayer model is built on three concepts: authority, replication, and RPCs.
The server has authority over all gameplay state. Clients send input to the server; the server simulates the world and replicates results back. An Actor is authoritative on the machine that owns it — typically the server for most gameplay objects, the owning client for player input validation.
Actors marked bReplicates=true synchronise properties from the server to relevant clients at the Actor's net update rate. Only changed properties are sent. The server calculates relevancy per Actor per client — distant or occluded Actors may not replicate to a given client at all, reducing bandwidth.
Remote Procedure Calls execute functions across the network. UFUNCTION(Server) runs on the server when called from a client. UFUNCTION(Client) runs on a specific client when called from the server. UFUNCTION(NetMulticast) runs on the server and all clients. RPCs are the mechanism for events that don't fit the property-replication model.
The NetDriver manages the actual UDP connection between server and clients. It handles packet sequencing, reliability layers, and connection state. UE5 uses a custom UDP protocol (not raw UDP). The NetDriver runs entirely server-side — your game logic interacts with it through the Replication Graph and the Actor channel system, not directly.
Key classes in the dedicated server context
The Online Subsystem: when you need it and when you don't
The Online Subsystem (OSS) is UE's platform abstraction layer. It sits between your game code and platform services — Steam, Epic Online Services (EOS), Xbox Live, PlayStation Network — and exposes a common interface for sessions, presence, friends, voice, and entitlements.
- Players need to browse and join sessions via the platform (Steam server browser, EOS session discovery)
- You need platform-native friends lists, invites, or presence
- You're shipping on console and need first-party compliance
- You want UE's built-in session lifecycle (CreateSession, FindSessions, JoinSession) to drive matchmaking
- You have a custom matchmaker that handles session discovery externally
- Players never browse servers — they're matched silently by an external system
- Your backend calls a session allocation API (like Gameye) and delivers the IP:port directly to clients
- You want to avoid the OSS configuration complexity for a simpler backend architecture
Studios using Gameye typically skip OSS for session allocation. The matchmaker calls the Gameye Session API, receives the server IP and port, and delivers those to players via your own notification channel. UE5's ClientTravel handles the actual connection. No OSS session lifecycle is involved in the server allocation step.
You can still use OSS for platform presence and friends — those functions are independent of how you allocate servers. EOS in particular is commonly used alongside Gameye: EOS handles auth and friends, Gameye handles server allocation.
Session lifecycle: from match found to server running
How a player gets from "match found" to connected to a UE5 dedicated server depends on whether you're using OSS sessions or a custom backend.
- Players queue in your matchmaker. Match found.
- Matchmaker calls Gameye Session API —
POST /sessionwith image, location, launch args. - Gameye starts the containerized UE5 dedicated server (~0.5s). Returns IP + port.
- Matchmaker sends IP + port to each player's client via your notification system (websocket, polling, etc).
- Client calls
UGameplayStatics::OpenLevel(this, IP:Port)or equivalent — UE5'sClientTravelunder the hood. - Server's
GameMode::PreLoginandPostLoginhandle the incoming connection. Session is live. - Match ends. Server calls
FPlatformMisc::RequestExit. Gameye detects exit, reclaims container.
Server travel: moving players between maps
UE5 provides two server travel mechanisms for transitioning connected players from one map to another within the same server process.
The server loads the new map, all clients disconnect, then reconnect. Simple and reliable. Results in a loading screen and a brief disconnection period. Default behaviour.
GetWorld()->ServerTravel("/Game/Maps/Arena?listen");
Clients stay connected during the map transition via a transition map. Requires bUseSeamlessTravel=true in GameMode and a configured transition map. Preserves PlayerState across the transition. More complex to implement correctly.
GameMode->bUseSeamlessTravel = true;
An alternative pattern: rather than using server travel, start a fresh session on a new server for each match. This gives a clean server state per match and works well with session-per-match orchestrators like Gameye. The tradeoff is a brief reconnect for players, but you avoid state leaking between matches.
Where Gameye fits: hosting your UE5 dedicated server
Once your UE5 dedicated server architecture is defined, you need infrastructure to run it. Gameye handles this without requiring any engine-side changes.
Gameye orchestrates the container process, not the engine. Your dedicated server binary runs unmodified — the same binary you test locally, packaged as a Docker image.
0.5s average from API call to running server. Containers are pre-pulled on every node — no cold-pull delay when your matchmaker requests a session.
UE5 replication is single-threaded and CPU-bound. Gameye runs on AMD Ryzen and EPYC bare metal — predictable clock speeds, no noisy-neighbour virtualisation overhead.
Bandwidth is included in Gameye's capacity pricing. UE5's UDP replication traffic is constant during a session — egress charges on AWS EC2 or self-managed cloud add up fast at scale.
For packaging your UE5 server binary into a Docker container and pushing it to Gameye, see the full guide: How to containerize and deploy a UE5 dedicated server →
For the full hosting and ops picture: Unreal Engine dedicated server hosting on Gameye →
Frequently asked questions
Should I use a dedicated server or a listen server in Unreal Engine 5?
Use a dedicated server for competitive, ranked, or anti-cheat-sensitive games — the server has no player running on it, so all authority lives server-side. Use a listen server for cooperative or casual games where one player hosts: it's simpler operationally but gives the host a latency advantage and means the session ends if the host disconnects. Most studios shipping to PC or console at any scale use dedicated servers.
What is the UE5 Online Subsystem and do I need it?
The Online Subsystem (OSS) is UE's abstraction layer for platform services: session discovery, presence, friends lists, voice, and achievements. It supports Steam, Epic Online Services (EOS), Xbox Live, PlayStation Network, and others via platform-specific implementations. You need it if you want matchmaking, session browsing, or cross-platform play built into the engine. If you're implementing a custom matchmaker that calls an external session API directly, you can bypass OSS entirely and call Gameye's REST API from your backend rather than from within the engine.
What is UE5 actor replication and how does it affect server performance?
Actor replication is how UE5 synchronises game state from the server to clients. Actors with bReplicates=true send property changes to relevant clients at the server's net update frequency. Every replicated actor adds to the server's replication budget. CPU-intensive games with many replicated actors need a dedicated server with headroom — typically bare metal rather than shared-core cloud. Gameye runs dedicated servers on AMD Ryzen and EPYC bare metal, which provides the predictable single-threaded performance that replication workloads need.
What is server travel in Unreal Engine 5?
Server travel (ServerTravel) is how UE5 moves all connected clients from one map to another within the same server process — used for lobby-to-match transitions. Seamless travel (bUseSeamlessTravel=true) keeps players connected during the map load. With Gameye, a common alternative is to run a new session per match on a fresh server rather than using in-process travel — this gives clean server state per match.
Do I need to modify my UE5 server to run on Gameye?
No engine modifications are required. Gameye orchestrates your server as a Linux container. Your UE5 dedicated server binary runs unmodified — no Gameye plugin, no server-side SDK, no changes to your replication or session code. The only integration point is your matchmaker or backend, which calls the Gameye Session API to start and stop sessions.
How does a UE5 dedicated server handle incoming player connections?
A UE5 dedicated server listens on a UDP port (default 7777). Clients connect by calling ClientTravel to the server's IP:port. The server's GameMode handles login (PreLogin, PostLogin) and spawns a PlayerController for each client. PlayerState is replicated to all clients. Gameye returns the server IP and port to your matchmaker at session start; the matchmaker delivers them to players so their clients can connect.
Get started
Run your first UE5 multiplayer session.
Sign up, push your server image, and have a dedicated server running in minutes. No sales call required.
Further reading
- How to containerize and deploy a UE5 dedicated server (Docker guide)
- Unreal Engine dedicated server hosting on Gameye — ops and infrastructure
- Unreal Engine multiplayer backend — what services your game needs
- How Gameye game server orchestration works
- Matchmaker integrations — Pragma, Nakama, FlexMatch, and custom
- Gameye pricing — bandwidth included, no egress fees