Progress update
Nebula progress update: September 18, 2026
This week's work lets developers deploy to Nebula Cloud from the command line, serve one world through several gateways, keep each player to one connection, inspect the world in 3D, and confirm that a save has reached storage.
Deploy to Nebula Cloud
Nebula Cloud is the hosted service for Nebula. Run nebula deploy --target cloud to upload a build and roll it out without a cloud provider account or SSH access. Each upload becomes a release that you can roll back to later.
New commands cover the rest of a deployment's life: nebula cloud login, nebula deployments, nebula status --cloud, nebula logs --cloud --follow, nebula scale, nebula rollback, and nebula destroy. If a deploy is interrupted after its upload, the next deploy reuses the uploaded build instead of sending it again. The local dashboard now also shares Nebula Cloud's visual style.
Serve one world through several gateways
A gateway is the process that accepts player connections and routes game traffic. One world can now be served by any number of gateways behind a load balancer. Session IDs are unique across every gateway, and each player receives a signed session token. A client that loses its link reconnects on its own through any gateway. It keeps its character if it returns within the reclaim period, which is 30 seconds by default.
Each gateway reports its load, including clients, traffic, CPU, and memory, on the dashboard. You can drain a gateway before maintenance. Its players reconnect through another gateway and keep their sessions. Nebula does not provide the load balancer for your own servers; Nebula Cloud deployments include one.
To test gateways under load, run nebula-loadgen. It connects synthetic clients, keeps them sending input, and reports lost sessions, reconnects, and round-trip time (RTT). The orchestrator also collects recent log lines from every process at /api/logs, so you can read a failed worker's last output after its machine is gone.
Load test a gateway fleet
Keep one connection per player
Before this change, a player who connected twice, for example from a restarted client or a second device, received a second character. Both characters then wrote to the same saved record.
Gateways now admit one connection per player identity across all gateways. The new connection takes over the existing session and character. The earlier client receives a message that it can show to the player. If the previous gateway cannot confirm that it released the player, the new join is refused. Games that want one identity to control several characters, such as a set of test bots, can turn the rule off with NebulaConfig.SingleSessionPerPlayer.
Inspect the world in 3D
The dashboard's world map now draws containers, world cells, and entities in 3D. A container is a box-shaped area of the world assigned to a worker, so its height now reads as clearly as its footprint. You can orbit, pan, and zoom, and press F to zoom to a selected entity and follow it.
The map stays responsive in large worlds. Items away from the cursor fade as you zoom in, crowds show a limited number of markers, and overlapping labels are hidden. In testing, drawing 10,000 entities dropped from 253 ms to 30 ms per frame.
Inspect the world mapBuild large procedural worlds
New opt-in tools help games that create containers at run time instead of placing them in a scene. RuntimeGrid divides space into cells and gives each cell a stable ID and exact bounds. RuntimeGridAllocator requests the containers in a ring around a point, such as a player. RuntimeGrid.ShiftOriginTo moves the floating origin without disturbing character controllers. The floating origin is the point that keeps coordinates near zero in a very large world.
Two more APIs help with saved data. BeginSpawnPlayer lets a game finish loading a player's data before their character enters the world. NebulaWorker.RequestEntity finds the worker that currently simulates a saved entity and sends it a request for that entity.
Read the RuntimeGrid reference
Confirm that a save reached storage
IPersistenceStore.WhenWritten calls back once every earlier save and delete has reached storage. Use it before an action that depends on those saves, such as telling a player that a trade is complete.
Previously, the orchestrator confirmed a worker's save as soon as the save was in memory, so a crash in the next second could lose a confirmed record. It now confirms a save only after writing it to the file or database. The local store groups nearby requests into one background write, so the extra safety does not stall the game.
Read the WhenWritten referenceFix physics and deployment issues
- A
NetworkRigidbodythat gains authority now starts from its current position instead of snapping back to an older one. - A position sent by a client-controlled entity just before it crosses into another container is now applied in the correct container's coordinates.
- A gateway registers again if a restarted orchestrator no longer lists it.
- Deployments no longer include a leftover web client build. Host web builds with your game and point them at the gateway.
- Player builds now compile every script assembly from scratch, which prevents a worker from running outdated game code.
Five releases shipped
Releases 0.1.0-alpha.23 through 0.1.0-alpha.27 cover the work in this update. The wire protocol is now version 16, so rebuild clients, gateways, and workers together when upgrading. Custom control planes must implement IGatewaySessionControlPlane while one connection per player is turned on.
- 0.1.0-alpha.23 Multiple gateways, reconnection, and Nebula Cloud deploys
- 0.1.0-alpha.24 A dashboard that matches Nebula Cloud
- 0.1.0-alpha.25 A 3D world map in the dashboard
- 0.1.0-alpha.26 One connection per player across gateways
- 0.1.0-alpha.27 Confirmed saves and procedural world tools