Deployments and the Runtime

SpatialOS concepts: Deployments and the Runtime

Tip: Before you read this page, you should read What is SpatialOS?, World, entities, components, and Workers and load balancing.


SpatialOS hosts the server element of your multiplayer game. You set up the server hosting via SpatialOS deployments.

In production, you always use cloud hosting, but during development you can test your game with both cloud hosting and local hosting (where your development machine emulates cloud hosting).

As you learned in Workers and load balancing, you decide how many server-worker instances your world needs, and how to organise them across the world. In a deployment, SpatialOS starts those server-worker instances for you, running them on machines in the cloud (and orchestrating this for you - you don’t need to interact with the machines directly).

SpatialOS also mediates client-worker connections.

Deployment runs

A deployment run is an instance (running or stopped) of a deployment. Each deployment run of a cloud deployment is assigned an int64 number as a unique identifier, which is called the Run ID. (Local deployment runs don't have Run IDs.)

You might find the Run ID useful in situations when the deployment name is not enough to uniquely identify a specific run of deployment.

The Runtime

The SpatialOS Runtime manages your game world. There is one Runtime instance for every game deployment. It is made up of the following parts:

  • Entity database: Holds the canonical store of all SpatialOS entity data.
  • Bridge: Handles server-worker and client-worker instance connections and manages their read access.
  • Load balancer: Coordinates each worker instance’s write access to the entity database.

Each server-worker and client-worker connection is assigned a unique bridge that communicates with other parts of the Runtime on the worker instance's behalf. The bridge makes sure the worker instance only receives updates about the part of the game world that it is allowed to receive updates about.

Your worker instances don't communicate with the entity database directly. Instead, when a worker instance wants to make a change to an entity, it sends that request to its bridge. The bridge then forwards the request to the entity database on the worker instance's behalf.

2019-05-21 Page added with editorial review

Updated 7 months ago

Deployments and the Runtime

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.