Limits and metering

Service limits, resource budgets, and usage metering. See pricing for plan allowances.

Room settings

See Room configuration for the complete option table, defaults, and units. This page lists service limits and what happens when they are reached. Plan allowances are on pricing.

Schema limits

defineSchema throws on a schema past one of these, so it fails at build time and never reaches a server. The complete list, including string, list and id bounds, is in schema limits.

Where a room runs

Your project gets its own server, sized from the size class your room types declare. A bigger class gets you a bigger server. Declaring nothing gets you Standard.

Every project starts on one server and gets another when its rooms need one. The room budget below applies to each server on its own, so a project on three servers has three servers’ worth of budget rather than one budget divided three ways.

Room budget

One server holds a fixed number of awake rooms. irtio sets the number, per size class:

A room counts against the budget while it is awake. Asleep rooms cost nothing, so a project with thousands of rooms and twenty awake ones fits on one server.

A project with room types in more than one class shares one budget. Each awake room takes a slot of its own class: five awake Standard rooms use a quarter of the budget, one awake Extra large room uses a third. The server is sized for the largest class the project declares.

When a project fills a server’s budget, irtio adds a server and the next new room starts there. See when a project gets another server.

Players per room

maxClients defaults to 64. Measure your game’s capacity with load tests, then set a count that stays within your tick-time and bandwidth budgets.

Relay rooms

Relay rooms provide messaging and, with a deployed schema, shared state. See relay rooms for setup and ownership policies.

Changing a deployed relay schema resets the room’s stored state and reconnects clients against the new schema. Deploying the same schema preserves state.

Ports a client connects to

Room traffic goes through the regional router, so a player’s network only needs outbound 443. The game servers accept room connections from the router alone. What protects a room is the join credential your project issues.

Memory

Declare a room class to set its memory ceiling: Standard 64 MB, Large 256 MB, or Extra large 1 GB. Server sizing changes take effect on a restart. Keep collections bounded and measure memory during load tests.

The ceiling covers everything the room holds, not only its JavaScript objects. Typed arrays, Buffers, and WebAssembly memory count against it the same way, so a room that keeps decoded assets, audio buffers, or a WebAssembly heap can reach its ceiling while its object graph stays small.

If a room exceeds its ceiling, it restarts from its saved state and the log line names what it was holding and how much of that was off the JavaScript heap. Three restarts in a minute close the room.

When the server itself nears its memory limit, it refuses new rooms with E_TENANT_WAKING, which clients retry, and puts rooms with no players in them to sleep early. Rooms with players keep running. If there is no such room left to sleep, the server restarts its largest room from that room’s saved state, and changes since that room’s last snapshot are lost.

Connection limits

Enforced by the server, per connection or per project. Exceeding one closes the socket or refuses the frame rather than degrading quietly.

Slow clients

When a socket’s outbound buffer exceeds its budget, irtio closes it with code 1008 and reason E_SLOW_CONSUMER.

The budget is per socket. While a join or resync WELCOME is still leaving the server, the budget is raised by that welcome’s own size and returns to normal once it is sent, so a large state snapshot does not by itself cost a player the connection. There is no throttling. Reconnect to receive a fresh snapshot in a room with state. These limits also apply to platform connections forwarding player traffic through relay rooms and are not configurable per project. Refused bytes are not billed as egress.

Platform error text

A message irtio writes for one of its own errors is at most 96 bytes of UTF-8, so a str(96) field can always carry one. That covers every code in the error catalogue and every refusal a room API rejects with, including the replay walls. A message that would run longer is cut on a character boundary and ends with a single …, so it is always valid UTF-8 and you can tell a cut message from a short one.

The bound is on irtio’s text, not yours. Your own data still has to fit the field you declared for it, and @irtio/schema throws on a value that does not rather than trimming it. See schema limits.

The rows marked “per server” are abuse limits, not per-project budgets. They stop one server being flooded, and a project on more than one server has each of them enforcing its own copy. See limits per server.

Storage limits

Going over a KV limit rejects the write with a named error code rather than truncating the value. See saves and restores and the error catalogue.

Public API limits

Quick match, player identity and leaderboard reads are open endpoints. A stranger holding your project key can call them, because that is what makes them work from a browser with no login. So they are rate limited on two dimensions at once, per calling address and per project.

The address limit stops one machine flooding. The project limit stops a botnet making one customer everyone else’s problem. The address allowance is drawn from first, so a single flooding client runs out before it can spend the allowance everyone else is sharing. An IPv6 address is counted by its /64, the block one home connection is given.

The project allowance is only spent by requests about a project that exists. On the identity exchange it is only spent by a valid identity, so a flood of junk credentials cannot use up the allowance your real players need. Link code redemption is the exception by design: every guess against your project counts, because that count is what keeps a short code safe to type.

Audience credential minting is limited per IP and per room. See audience rooms.

Leaderboard limits

Scores are integers by decision, not by omission. See leaderboards.

Quick-match limits

Skill rating limits

A rating is written only by room.ratings.report from your own room code. There is no client-originated path and no CLI submit, for the same reason there is none for leaderboards.

Client-side prediction

Configure maxPredictedBodies and maxProxyBodies in the client’s physics options. Monitor stats.absent and stats.lastResimMicros. See prediction.

Room log limits

Lines over the per-minute budget are dropped, not queued, and nothing in irtio logs marks the gap. If verbose lines go missing while you debug, log less or log a summary instead of a whole object. See logs.

Retention

Room state is kept forever by default. A room type can opt into having its rooms removed a set time after they last went to sleep by declaring retention: '10m' (see room types). The window is a floor: the sweep runs every 15 minutes, so a room is deleted on the first sweep after its window lapses.

Usage and metrics

The dashboard and irtio usage show room hours, voice participant-minutes, storage, and data out. See pricing for rates and allowances.

Operational metrics include sockets, roomsByState.*, ingressBytes, egressBytes, and rss. Use them to monitor connections, room lifecycle, traffic, and memory. Hibernated rooms do not accrue room hours.

Usage caps

Each billed meter has a cap, and what happens at the cap depends on whether the account has a card on file.

Set a ceiling per project and per meter with PATCH /v1/projects/<id>/caps, and clear one by setting it to null. GET /v1/projects/<id>/caps shows where a project stands.

The voice wall refuses new calls, not calls already running. A participant who joined before the wall keeps talking until they leave.

Nothing already playing is cut off

A cap refuses new work, never work in flight:

• A player connected before the cap tripped keeps playing until they leave. Their session is not closed, their room is not stopped, and their writes keep being accepted.
• A room that already exists keeps running, and other players can still join it. Only a new room is refused by the room-hours cap.
• A storage cap refuses writes. Reads keep serving and deletes keep working, which is how a project gets back under the line.
• Nothing is ever deleted by a cap.

The cost of that grace is that data out keeps accruing under sessions that were already open. In practice session churn bounds it, and the overage is preferred to disconnecting somebody mid-game.

Enforcement timing

Usage caps update asynchronously. Room-hour enforcement can lag by about 95 seconds; storage enforcement can lag by about 17 minutes. A server temporarily unable to refresh caps keeps its last received state. Use headroom when choosing a ceiling.

Data-out enforcement

At the data-out allowance, sockets close with code 4290 and rooms hibernate with saved state. The dashboard warns at 80% and at the limit. Allowances reset with the billing period; see pricing.

Enforcement works in budget chunks, so usage can exceed the allowance by up to roughly 5 GB before forwarding stops. A separate sustained-rate limit drops messages if a project exceeds it for more than ten seconds, with a room log warning.

Replays

A room type that sets replay keeps recent state in memory so room.replay.clip(seconds) can save it. Nothing is stored until a clip is taken. With replay: { record: true } the room stores the whole match instead, in the background, as the oldest seconds fall out of memory. See replays.

room.replay.excerpt() reads the same in-memory footage back into the room as plain frames. It is experimental, it stores nothing, and its limits are counted separately from clips, so a killcam that reads footage does not use up the room’s clips. Excerpt output is not filtered by interest management: it carries what the recorder recorded (public collections unless replay.view or replay.omniscient says otherwise), and the room decides who may see it.

Set ttl in the room config to change how long clips and recordings from that room type are kept. The lifetime is fixed when the clip is saved, so changing ttl does not re-time clips you already saved.

A link can keep working for up to a minute after the clip expires, so the '1m' floor is honest to about a minute.

A clip or a recording counts as stored bytes while it is kept, and as bandwidth each time it is watched.

Clips and recordings are stored and served compressed. The recording cap counts compressed stored bytes; replay() handles decoding.

Related

• The dashboard
• Pricing