What survives losing a host

A match survives its host dying. This page is about which machine owns an entity and which owns it next, the second meaning of "replication"; Who Sees What, and Which Machine Runs It tells the two meanings apart.

Room state is not copied between hosts

An entity has exactly one owner at a time, and no second machine keeps a live copy ready to take over.

Two copies accepting the same shot would have to agree on the order the two shots landed in. Agreeing on an order thirty times a second between machines is consensus, and consensus adds latency where a game can't tolerate it. A single owner does not have that problem, and every mechanism below exists to make a single owner survivable.

What is replicated is presence: which actor is on which node. That is a small, slow-changing fact, so routing can know it everywhere without paying for agreement on anything that moves.

Declared state is held outside the host

Declared state is not private to the process holding it. It is snapshotted on a declared interval, so a replacement can resume from the last snapshot when the previous host stops answering, and the player re-enters through the ordinary rooms grace window.

Two things follow, and one warning:

The replacement has the state whole, but as of the snapshot. What a failover costs is the play between the last snapshot and the loss, and the interval is what fixes that worst case.
Tick continuity is not carried across a change of authority. A move the platform performs preserves the participant's tick state; a replacement of the authority does not promise it. Rooms is where both are declared, along with what happens when the grace window passes.

Engine-only state is not recovered

Anything you kept only in engine actors goes with the process. It was never declared, so nothing outside that host ever had it.

A deploy is the same path, without the loss

Draining a host — stop placing new rooms there, let the sessions in flight finish or hand over, then let it go — is the failover path run on purpose and with notice. So deploying without killing live sessions needs no second mechanism.

The room's host learns of it the same way it learns anything: the platform gives advance notice that a room is to be closed or handed over for a reason on its own side.

What happens once the window passes is declared, and there is no default. A room type whose authority lives outside the platform names one of three outcomes for losing it — wait out a declared window, close the room, or admit a replacement authority. The declaration can't leave it unsaid.

Which machine is not part of your surface

You never name a node. Whoever creates a room does not choose where it runs, and no operation takes a host as an argument : placement is the platform's, so it can move a room without your code depending on where it was.

If you host rooms yourself — a dedicated server or a master client — the same is true with one addition: you are told to wind down, and finishing or handing over your sessions inside the grace window is yours. Rooms is where a host registers for that binding, and Authority is why the host holds only the rights it was granted.