Skip to main content

Hathora Entities


An application is the top level namespace for the game server you are developing. For example, if you are developing two games, Uno and Poker, you would have two corresponding applications for them.

You would also create an application for different environments (i.e. staging, dev, prod) or for major rewrites of your game (e.g. PokerV2).

All the entities below are scoped to a particular application.


A build represents a game server artifact and its associated metadata: size of the artifact, when it was created, how long it ran for, etc. You can store multiple builds in our container registry, see limits here.

Builds are versioned, so the first build you create will be version 1, the next will be 2, and so on.


A deployment represents the configurations for an application's build at runtime: plan size, environment variables, rooms per process. Each deployment is tied to a specific build.

Deployments are versioned, so the first deployment you create will be version 1, the next will be version 2, and so on. Whenever you create a new room, it will use the build and configuration from the latest deployment. Pushing a new deployment doesn't affect existing rooms in progress and only applies to future rooms, thus providing simple no-downtime upgrades.


A process represents a runtime instance of your game server. In Docker terminology, a process is equivalent to a Docker container. A process includes:

  1. The deployment version it's on
  2. The host and port that it's bound to
  3. A starting, running, idle, or terminated status

Hathora Cloud provides logs, system metrics (i.e. CPU/memory/bandwidth), and active connections for a process. Processes idle for > 5 minutes are automatically shut down to minimize your compute costs.


A room represents a single match/game session. The roomsPerProcess deployment configuration governs how many rooms can be scheduled on the same process. When roomsPerProcess = 1, rooms are 1:1 with a process.

Games that support concurrent matches on the same game server instance (e.g. you're using something like Socket.IO) can set roomsPerProcess to be > 1. Hathora will schedule multiple rooms on the same process. Rooms scheduled on the same process will share the same host and port so your server must handle distinguishing network packets between rooms.