Skip to main content

Hathora Entities

Application​

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.

Build​

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. A build can be used across multiple applications.

Deployment​

A deployment is used to map a build to an application and represents the configurations for the build at runtime: plan size, environment variables, rooms per process, etc.

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.

Process​

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.

Room​

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.

Fleet​

A fleet represents the compute resources available across all 14 Hathora regions, uniquely identified by a fleetId. Each team currently manages a single fleet.

For every region within a fleet, you can monitor both provisioned capacity (vCPUs on bare metal and cloud) and utilized capacity, which tracks the number of vCPUs actively used by your game servers and Hathora’s overhead for node operations.