Nebula progress update: September 24, 2026

Upgrade without surprising players

A gateway, the process that accepts player connections, now accepts clients built for the current wire protocol and the one before it. A client outside that window gets a refusal that names the versions the server supports, instead of a silent disconnect. It does not retry by itself, so your game can tell the player to update.

Your game can also set its own content version with NebulaConfig.GameContentVersion. The gateway refuses a client whose content does not match, with a separate reason code. The upgrade guide describes how to drain and replace one gateway or worker at a time while players keep their sessions.

Recover after an orchestrator restart

The orchestrator is the process that assigns containers, the box-shaped areas of the world, to workers. If it came back without its stored state, workers kept simulating containers that the rest of the mesh no longer knew about. Workers now register again and claim the containers they still simulate. In our test, a replacement orchestrator with an empty database had every container assigned again in 2.6 seconds.

A new restore drill backs up a database, wipes it, restores it, and checks the result through Nebula's own storage code, so you can rehearse a restore before you need one.

Create worlds on demand

A scope is a separate simulated world, such as a dungeon run, a match, or a player's home. Any process that can reach the control plane can now ask for a scope by key with ActivateScope. Asking twice for the same key returns the same world, so a matchmaker and a travel menu can both ask without coordinating.

A scope that holds nothing for ScopeIdleRetireSeconds (5 minutes by default) is retired: Nebula saves its persistent entities, confirms the saves, and releases its containers. The next request brings it back with what was saved.

A scope can also be a whole procedural world. Each scope gets its own chunk grid, and each world keeps its own floating origin, so one worker can hold an arena and a distant continent without losing precision in either.

Know what happened to a cross-worker call

An AuthorityRpc is a remote procedure call (RPC) to the worker that simulates an entity. Nebula now applies each call at most once, follows the entity through up to three handovers, and rejects a call that is too far out of date. AuthorityRpcWithReply tells the caller the outcome: accepted, rejected with a reason, or timed out.

Every entity also has one EntityLocation: its scope, its container, and its pose in that container. It reads the same on every process and in storage.

Keep related entities on one worker

Cohesion hints let your game say that a set of entities must be simulated by one worker and move between workers together, such as the parts of a vehicle. You can also stop Nebula from rebalancing a container for a limited time, for example during a boss fight.

Nebula also checks your project for joints between entities in different containers. Physics cannot hold such a joint together across two workers, so Nebula > Validate Project and the worker now warn about it.

Nest containers and give them their own physics

Containers now form a tree. A container can sit inside another, such as an engine room inside a ship, and can either be simulated by its parent's worker or be assigned to a worker of its own. A container placed 10,000 km from the origin lands within a centimeter.

A container can also have a physics frame: a physics scene of its own in which the container stands still. Players and objects inside a flying ship simulate in the ship's coordinates, with the ship's floor as down, at any speed. A planet can be a frame too, so its rotation does not disturb what stands on it.

The dashboard shows the tree, which containers inherit their worker, and which ones have a frame.

Fly a crewed ship into another world

A ship with players aboard can now fly from one scope into another, for example from a planet's world into space. The crew stays seated, and their clients follow the ship without reconnecting. Players left behind never learn where the ship went.

Carry cargo in a moving ship

Loose crates in a ship's frame need no new component. A stack stays in order through takeoff, turns, cruise at 1 km/s, and landing, then falls asleep, and it keeps its state through a handover of the ship to another worker. Moving ramps, lifts, and doors carry what rests on them.

• FrameInertia makes a crate slide when the ship accelerates, brakes, or turns. Scale sets how much of the motion it feels.
• FrameAttachment holds an entity at a pose in a container, such as a crate strapped to a cargo grid or a turret on a deck. The attachment survives handovers, restores, and late joins.
• CargoPolicy.Stow puts a ship away with its persistent cargo aboard. The cargo comes back when the ship is restored.

Check Nebula's guarantees

The conformance suite is a set of deterministic tests for what Nebula promises across workers: handovers, calls, locations, scopes, physics frames, and sessions. It now covers 26 scenarios and runs real workers in one Editor process.

Fix persistence, sessions, and ships

These releases also fix problems found while testing large worlds:

• A worker that missed heartbeats but kept running could leave two live copies of its persistent entities. Nebula now keeps at most one.
• A worker given hundreds of containers at once, or a game that filled the thread pool, could get a worker declared dead. Both are fixed.
• A disconnected player's pawn that changed worker was never removed. The reconnect countdown now travels with the pawn.
• Chunks around a pilot stayed near the origin wherever the ship flew, and a teleport into a ship landed tens of meters off. Both now use the ship's position correctly.
• A player in the middle of a jump lost that motion at a container boundary. Predicted state now travels with the handover.
• Two ships with overlapping interiors could end up inside each other and stop the worker. Nebula never places an entity inside a container it carries.