Rooms
Limits
Sizes, rates, timeouts and spending caps that rooms, connections and projects work within.
These limits are provisional and may change before launch. Going over a connection limit closes the connection with the close code listed below.
Rooms
| Limit | Value |
|---|---|
| Room state | 32 MB; a room whose room state grows past it stops |
| Tick rate | 1 to 120 ticks per second; default 20 |
| Private state of a player who left | kept 24 hours by default; a room’s privateRetention sets it |
| Room ID | 1 to 64 characters of A-Z, a-z, 0-9, _, - |
| Connections per room | 64 for standard, 256 for large, 1,024 for extra-large; a room’s maxPlayers caps it lower |
| Hibernate after the last connection leaves | 30 seconds |
| VM stops after its last room hibernates | 5 minutes |
| Wake timeout before held connections are closed | 10 seconds |
| Room state written to object storage | every 30 seconds when changed, and on hibernate |
Replays and clips
| Limit | Value |
|---|---|
| A replay’s records | 64 MB, then recording stops |
| A replay’s length | 2 hours, then recording stops |
| One tick’s records | 4 MB, or recording stops |
| Recordings a room starts | one every 10 seconds |
| A clip | 1 to 60 seconds |
| Clips | one every 10 seconds, 20 per replay |
| Replays and clips a room keeps | its newest 20 replays and 100 clips |
| Replay retention | rooms.replayRetention, 1 hour to 30 days; default 7 days |
| Replay and clip IDs | 1 to 64 characters of A-Z, a-z, 0-9, _, - |
Player data, collections and leaderboards
| Limit | Value |
|---|---|
| A value | 64 KB of JSON or bytes |
| A player’s data | 256 keys and 1 MB |
| Keys and entry IDs | 1 to 64 characters of A-Z, a-z, 0-9, _, ., :, - |
An entry’s meta |
1 KB, flat strings, numbers and booleans |
| A collection | 1,000,000 entries; maxOwn per player from clients, default 100 |
| Collections | 32 per project |
A list or top page |
100 entries, 20 by default |
| Leaderboard periods kept | the current one and the three before it |
| Calls | 200 a second and 64 at once per room; 10 a second per client address and per player; 2,000 a second per project |
Guests minted with POST /v1/guest |
10 a minute per client address, with those connecting mints |
| A request | 128 KB |
| Deadline | 5 seconds, then E_UNAVAILABLE |
| Guests’ player data | deleted 90 days after it was last written |
Reads and writes are metered and free within these limits. See Player data, collections and leaderboards.
Messages and connections
| Limit | Value |
|---|---|
| Message size | 64 KB |
| Messages per connection | 120 per second |
| Connections per player per room | 1; a new one closes the old one |
| WebTransport connect before falling back to WebSocket | 3 seconds |
A state update for one tick can span several messages, so a client entering a large view isn’t bound by the message size.
Outbound calls from rooms
| Limit | Value |
|---|---|
| Protocols and ports | fetch to https:// on port 443 only, by host name |
| Addresses | public only; names resolving to private, loopback or link-local addresses are refused |
| Connections open at once | 64 per VM |
| Bandwidth | 10 MB a second per VM, both directions together |
| Idle connection | closed after 5 minutes |
See Calling your backend.
State sync
| Limit | Value |
|---|---|
A bytes field |
48 KB |
A string field |
16 KB of UTF-8 |
A json field |
16 KB serialized |
| An entity, encoded with every field | 61,376 bytes (60 KB minus 64) |
| Prediction inputs held ahead of the room | 32 ticks |
How far a view tick, and room.rewind, reach back |
250 ms (MAX_REWIND_MS), plus two ticks kept |
| Lag compensation history | 8 MB per room (MAX_HISTORY); 8 bytes per field per kept tick per entity, plus 128 bytes |
| Interest keys a connection subscribes to | 4,096 |
| Entities a connection sees, presence entries included | 16,384 |
| Presence entries in a room | 1,024 |
| A presence name | 64 characters |
| A presence status | 1 KB serialized |
Going over a state sync cap is an error in the room’s log; the extra keys or entities are left out.
Player tokens
| Limit | Value |
|---|---|
Lifetime (exp after iat) |
at most 24 hours |
Player ID (sub) |
1 to 128 bytes, not starting with guest: |
meta |
JSON, up to 1 KB |
Join codes
6 characters of A-H, J-N, P-Z and 2-9, so codes have no I, O,
0 or 1.
Project settings with limits
| Setting | Default | Meaning |
|---|---|---|
limits.maxActiveRooms |
100 | Rooms active at once |
limits.maxRoomHoursPerDay |
200 | Room-hours per day |
limits.maxRooms |
1000 | Rooms that exist at once, hibernated or not |
limits.maxSleepingConnections |
10,000 | Connections the project’s sleeping rooms hold in a region; past it, a room that sleeps closes its connections with 4011 |
voice.maxSpeakers |
64 | Speakers each listener hears, 1 to 64, a ceiling on each room’s own; see Proximity voice |
rooms.retention |
"7d" |
How long a hibernated room is kept: "none", "<n>h", "<n>d" up to 365 days, or "forever" |
The limits are spending caps, set only in the dashboard, never from
irt.config.ts. A project over maxActiveRooms or maxRoomHoursPerDay
can’t wake more rooms, and clients get close code 4009. At 80% of either,
IRT sends a usage alert first. A project at
maxRooms can’t create more until rooms expire or are deleted. A project
can have 10,000 active bans.
Credit
Usage is paid from your account’s prepaid credit, which you top up by
card on the dashboard’s Billing page. Below a low-balance threshold the
dashboard shows a banner and each project with a webhook gets a
billing.low_balance event. When the balance reaches zero your projects
keep running for 24 hours. After that they can’t wake rooms, their
players are disconnected with close code 4009, the server API answers
429 limit, and running rooms hibernate. Topping up undoes this at
once. Running out never deletes a room.
Close codes
| Code | Meaning | Client SDK |
|---|---|---|
| 4000 | Protocol version not supported | Fails; the site needs a newer SDK |
| 4001 | Token invalid or expired | Fails |
| 4002 | Room not found, and players.createRooms is off |
Fails |
| 4003 | Room full: at its size’s connection limit or its maxPlayers |
Fails |
| 4004 | Schema differs from the room’s build | Fails; rebuild and redeploy the client and room together, or reload the site |
| 4005 | Rate or size limit exceeded | Reconnects after backoff |
| 4006 | Kicked by the room, or its onJoin threw |
Fails |
| 4007 | Room stopped | Fails |
| 4008 | Room moved or restarted | Reconnects at once |
| 4009 | Project over its spending limit, or out of credit | Fails |
| 4010 | Wake timed out | Reconnects after backoff |
| 4011 | The room hibernated by its own request, or went to sleep past limits.maxSleepingConnections |
Fails; the game can offer to rejoin |
| 4012 | The same player connected again elsewhere | Fails |
| 4013 | The player is banned from the project | Fails |
Any other close reconnects with backoff. See Errors and close codes for what causes each and what to do.