> For the complete documentation index, see [llms.txt](https://kinematicsoup.gitbook.io/reactor/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kinematicsoup.gitbook.io/reactor/architecture/architecture-backend.md).

# The Backend

## Summary

How KinematicSoup's online service supports games that use KinematicSoup hosting: storing published server images, launching and tracking rooms, and helping clients find public rooms. It is part of the [Reactor Technical Overview](/reactor/architecture.md).

## What the Backend Is

The backend is KinematicSoup's online service. It is required only for games that use KinematicSoup to host Reactor servers. A game can instead run against a local server or a server you host yourself, and in those cases the backend plays no part. When you do use KinematicSoup hosting, the backend stores your published server images, launches and tracks rooms, and helps clients find public rooms.

## Publishing and Images

When you publish from the Unity editor, Reactor builds a **server image**: a versioned bundle of configuration settings, server scripts, and the assets a server needs for its physics simulation. Reactor uploads the image to the KinematicSoup image storage servers. An image is the bundle a room is launched from.

## Launching and Orchestration

From an image, the backend launches **rooms** in the region you choose and tracks each one through its lifecycle of starting, running, and stopping. It records where a room is reachable and holds the metadata a client needs to find it. Only **public** rooms have their information readily available to clients. A room is made public through server scripts, or through options set when it starts.

The backend also manages **clusters**. A cluster lets rooms that run the same image in the same geographic area communicate with each other and share state through the cluster data store. See [Basic Orchestration Using the Cluster](/reactor/tutorials/cluster_room_management.md).

## Discovery

Before a client can connect, it has to find a room. The GetRooms API returns the **public** rooms for a game, each with its connection details, **public data**, and **public tags**, the small pre-connection summary a room chooses to expose. A game uses this to build a server browser or a room list before joining.

Public rooms are not the only path. **Private** rooms also exist and can accept connections when their room information, typically a `ksRoomInfo`, has been shared with a client by other means. See [Publicly-Visible Data for Rooms](/reactor/tutorials/public_data.md).

## Where to Go Next

* [The Runtime Server](/reactor/architecture/architecture-server.md): what a launched room runs.
* [The Client](/reactor/architecture/architecture-client.md): how a client uses discovery to connect.
* [Publicly-Visible Data for Rooms](/reactor/tutorials/public_data.md): publish the data players see before joining.