Concepts

The vocabulary the rest of the documentation uses — organisation, project, cell, channel, participant, token, node, spending ladder.

Organisation and project#

An organisation is a studio or team: members with roles, one invoice per month, API tokens for automation. A project is one game (or one community server). It owns an SDK key, a plan, a home region, a spending limit and its usage history. Everything a player touches is scoped to a project.

Cell#

A cell is one complete Aurix deployment: registry database, Redis, and media nodes in one or more regions. Projects are pinned to a cell at creation and keep its endpoint for life — that is the URL shown under Keys & SDK and the host your backend and clients talk to. Free and Indie projects share the EU pool; Cloud and BYOC projects get nodes of their own inside the same cell. The control plane manages cells over their admin API and never carries audio.

Channel#

A channel is where people hear each other. Types:

Channels can be created explicitly through the cell API or ad hoc from a token request: { "ad_hoc": { "name": "match-7", "channel_type": "positional" } } creates (or revives) a channel with a deterministic id and removes it when the last participant leaves. A player can be in several channels at once — a positional channel for proximity plus a team channel for the squad is the common layout — and the SDK decides where the microphone goes (transmitToChannel, push-to-talk per channel).

Participant, session, participant-minute#

A session is one connected client. A participant is a session inside a channel; one session in two channels counts as two participants for capacity purposes on shared plans. A participant-minute is one participant for one minute, the unit the usage page reports and the unit quotas on Free/Indie are expressed in.

Token and SDK key#

The SDK key (aurx_…) belongs to your backend. The only thing it should do with it is call POST /v1/tokens on the cell. A player token is a JWT (60 minutes) bound to your external_id; the client uses it to connect and to join the channels it was granted. Rotating the key invalidates future minting, not tokens already issued — they expire on their own. Player tokens

Region and endpoint#

Every project has a home region (where channels are created by default). The token response carries an endpoint: the node the player should connect to — preferred region if you pass one, otherwise nearest to location, otherwise least loaded. Cross-region channels are allowed; audio between regions goes over the cell's backbone.

A project can have several regions. Regions on one backbone share channels (players in both can be in the same positional channel); regions on separate backbones — another continent or an isolated deployment for data residency — are for regional shards. GET /v1/projects/{id}/discover and POST /v1/projects/{id}/tokens on the control plane pick the region for a player (hint, coordinates or country) and return the nearest node there, so a token server needs one secret and no backend addresses.

Node and capacity#

On Cloud and BYOC plans capacity is nodes: machines of a size (S / M / L) with a participant rating and an hourly price. Autoscale adds a node above 80 % load and removes the least-loaded one below 35 %, within your spending limit. Draining a node moves players off it without disconnecting anyone. Cloud nodes · Your own nodes

Metering and the spending ladder#

Usage is metered every five minutes into hourly rows; the running hour is updated live and becomes final when it ends. For paid plans a monthly spending limit with a forecast (spent + current rate × remaining hours) drives a four-step ladder — bitrate, server mix, home-region-only, refuse new joins — that degrades quality instead of disconnecting players. Spending limit

Transport#

Native SDKs (Unreal, Unity, C ABI) speak QUIC to the node directly. Browsers try WebTransport (HTTP/3 over QUIC), then WebRTC, then a WebSocket tunnel as the last resort. Godot uses the WebSocket/WebRTC path in 4.x. All of them carry the same Opus frames; the choice only affects latency under loss.

Life of a join#

1. Your backend asks the cell for a token with external_id, channels and grants; the cell picks a node (requested region → nearest by location → least loaded) and returns the token plus that node's endpoints.
2. The client connects to the node over the first transport that works (native QUIC; in browsers WebTransport → WebRTC → WebSocket) and presents the token. The node validates it locally — no round-trip to the control plane.
3. The node admits the session if the project's limits allow it (max_concurrent_sessions from the plan or node capacity, max_participants_per_channel), creates ad hoc channels on first join and starts forwarding or mixing.
4. Every 15 seconds the node heartbeats load and counters; every 5 minutes the control plane meters them into hourly rows and recomputes the forecast and the ladder step.
5. On disconnect the client reconnects with the same token while it is valid (after that with a fresh one from your backend); sessions survive node failure by reconnecting to another node.

Limits by plan#

Limits are applied by the cell at join time; nothing is enforced retroactively and nobody connected is disconnected when a limit is reached.