UE5 replication: why it works in standalone and not as a client
By the Cosindra team · Updated August 7, 2026
Unreal is server-authoritative, and almost every multiplayer bug a beginner hits comes from writing code that quietly assumes it is not. The symptom is famous: everything works in standalone, and the moment you play as a client, half of it stops.
This guide covers the direction replication actually flows, when to use each of the three RPC types, and how to test as a client so these problems surface on your machine instead of in someone else’s game.
Replication flows one way
The server owns the truth. Replicated variables travel server to client and nowhere else. A client that sets a replicated variable changes its local copy, feels correct for a moment, and gets overwritten by the next update from the server — silently, with no warning that anything was wrong.
So the shape of every multiplayer feature is the same: the client asks, the server decides and applies, the result replicates back. "Apply damage on the client" is not a shortcut, it is the bug.
Replicated versus RepNotify
A plain replicated variable arrives on clients with no ceremony — useful when something else already reads it every frame, like a value shown by a widget binding.
RepNotify additionally calls a generated OnRep function on clients when the value arrives, which is where the reaction belongs: redraw the health bar, play the hit sound, swap the material. The distinction matters because clients have no other reliable moment to notice a change; polling in Tick is the thing RepNotify exists to replace.
Three RPCs, three directions
Reliable versus unreliable is a separate axis and worth caring about. Reliable guarantees arrival and costs bandwidth; marking everything reliable is how a project ends up dropping connections under load. Cosmetic, frequently-repeated events — footsteps, impact effects — are the unreliable ones, because losing one does not matter.
| Type | Runs on | Called by | Use for |
|---|---|---|---|
| Server | The server | The owning client | Asking to do something — fire, interact, buy |
| Client | One owning client | The server | Telling one player something — you were hit |
| Multicast | Server + all clients | The server | Everyone must see it — explosion, sound |
The editor calls that set it up
These cover the wiring rather than the design. The decisions above — who has authority, which RPC direction, reliable or not — are still yours to make; these apply them.
| # | Tool | What it does |
|---|---|---|
| 1 | set_actor_replication | Enables replication on an actor and configures movement replication |
| 2 | add_replicated_property | Marks a Blueprint variable replicated, with its condition |
| 3 | setup_rpc | Configures an existing function as a Server, Client or Multicast RPC |
| 4 | create_game_session | Sets session settings such as max players |
| 5 | get_network_info | Reads net mode, server/client state and replicated actor count |
Test as a client, not standalone
Standalone play makes your machine the server, so every authority mistake works perfectly. This is why bugs appear only after someone else joins.
In the editor’s play settings, set the number of players above one and the net mode to play as client. You get a listen server and a real client, and code that assumed authority breaks immediately — on your machine, while you are looking at it. Doing this from the first multiplayer feature rather than the tenth saves an unpleasant week.
Put an AI copilot inside your editor
The free Cosindra desktop app connects to your UE 5.7/5.8 project — the assistant works in your open editor, and what you generate with the web tools applies straight into it. Windows & macOS.
Download CosindraFrequently asked questions
Why does my UE5 game work in standalone but break as a client?
Standalone makes your machine the server, so code that assumes authority always happens to be right. As a client that assumption fails: a client cannot meaningfully set a replicated variable — the change is local and the next server update overwrites it — and it cannot run gameplay logic the server has not sanctioned. Move the decision to the server via a Server RPC, apply it there, and let the result replicate back. Test with net mode set to play as client from the beginning, not at the end.
When should I use RepNotify instead of a plain replicated variable?
Use RepNotify when something has to happen the moment the value arrives on a client — redrawing a health bar, playing a hit reaction, swapping a material. It calls a generated OnRep function on clients when the new value lands. A plain replicated variable is enough when something else already reads it continuously, such as a UI binding. The alternative to RepNotify is polling in Tick, which is exactly what it exists to avoid.
Server RPC, Client RPC or Multicast — which one?
Direction decides. A Server RPC is a client asking the server to do something and is the entry point for nearly every player action. A Client RPC is the server telling one specific player something only they should know. A Multicast is the server telling everyone, for things all players must see such as an explosion. Also pick reliability deliberately: reliable guarantees delivery and costs bandwidth, so frequent cosmetic events are better sent unreliable.