Launch checklist

Twelve items, in the order they depend on each other. Each one names the page or the command that does it. Work down the list once, and the surprises left are the interesting kind.

1. Deploy, and confirm the version

npx irtio login
npx irtio deploy

deploy prints the new version number and the URL clients connect to. Any step that refuses prints why and exits non-zero, so a deploy that scrolled past is not a deploy that landed. Confirm it with npx irtio rooms or the dashboard’s Deployments page. See deploying a room.

2. Register your production origin

Your project id ships in your client bundle. The allowed-origins list is what stops another site pointing its own client at your project, and an empty list accepts only localhost. Everything else is refused with E_ORIGIN.

Add your origin on the dashboard’s API keys page. Add * when the game is served from somewhere you cannot predict, such as an itch.io page or an embed, because partial wildcards are not supported. Changes take effect within about 30 seconds and need no redeploy. A site published with irtio deploy --static registers its own origin. See deploying a room.

3. Decide how players are identified

Key-only is the default and needs nothing. With it, ctx.playerId is the client id and survives a reload only as long as the resume token, so a returning player is a new player as far as room.kv is concerned.

Decide before launch, not after, because switching later strands whatever you stored under the old ids. If you have accounts, saved progress, purchases or a ban list, mint a signing secret and join with a token:

npx irtio keys jwt-secret --project p_0dd0cafe00000004

See authentication.

4. Close the write surface

Anything a player could win by lying about is serverOwned and changes through an RPC. Every collection that stays client-owned has a validate that rejects the impossible and clamps the merely out of bounds. Without one, anything that fits the declared types is accepted. See anti-cheat.

5. Prove it with a cheating bot

npx irtio dev
npx irtio simulate --bots 5 --cheat-bot 0 --corrections-max 25

Read the adversarial section, not the exit code. HOLE bot 0 cheated and drew 0 corrections means the room accepted every illegal write it was sent. The honest bots should draw zero corrections; any they do draw is a validator refusing legal play.

6. Load-run at the count you expect

npx irtio simulate --bots 30 --seconds 60 --profile

The default maxClients of 64 is not a measurement. Find the largest bot count where tick-health stays ok and per-client bytes stay inside your budget, then set maxClients a little below it. Warm a deployed project with a throwaway run first, or the real one fails on E_STARTING. See room capacity.

7. Set the room’s own numbers deliberately

Setting	Default	Why it matters at launch
`maxClients`	64	The next join past it is refused with `E_ROOM_FULL`
`idleMs`	30000	Quiet time before a room hibernates. An idle room costs close to nothing
`tickRate`	20	Every tick is bytes for every client
`maxAwake`	none	Enforced, not advisory. Room N+1 of a type is refused by name
`memoryMb`	derived	The worker heap ceiling. A room past it is killed and restarted
`retention`	forever	Without it, every match room’s state is kept forever

maxAwake and memoryMb also decide how big a server your project gets, and a running server cannot be resized, so a change takes effect at your project’s next start. See room types and limits and metering.

8. Set caps, and know what happens at one

Every project has a cap on each billed meter. Without a card the cap is a hard wall: new joins, new rooms and new writes are refused, nothing is deleted, and nothing already running is killed. With a card it is an alert and the project keeps being served. An owner-set ceiling always walls, because setting one is asking to be stopped.

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

An alert fires at 80% of a cap and again at the wall, at most once each per meter per billing period, and it is emailed to the address on the org. Check that address before launch rather than after. Allowances and rates are on the pricing page. See limits and metering.

9. Have a rollback plan

Two tools, and they are not interchangeable.

npx irtio rollback <version> re-promotes an older version, creates no new version number, and restores rooms that migrated past it to their pre-migration state, discarding what they wrote since. This is the tool for a bad --strategy migrate deploy.
Deploying old code again moves forward like any other deploy, and is itself a fresh schema diff, so going back can be a breaking change that needs its own migration.

The default drain strategy is the safe one: new rooms start on the new version and running rooms finish on their old one. Decide now which you would reach for, and read the client-side gotcha in the CLI reference before you need it. See deploying a room.

10. Ship the moderation you will need

Moderation is room code, not a button on a page. The room API gives you room.kick(clientId, reason), room.close(reason) and room.setRole(clientId, role), and they only exist in your game if you wrote and deployed them. An RPC gated on ctx.role is the usual shape.

Decide who can call it and how you reach them at 2am. See the room file API.

11. Check logs and metrics before you need them

npx irtio logs --follow
npx irtio status

Run both once against the deployed project so you know they work and you know what normal looks like. Log lines are kept for 7 days, and the last 500 per room are buffered inside your project’s server. The dashboard’s Logs page narrows by room server-side, and its Metrics page carries the same series irtio status prints. See logs.

12. Publish the client, room first

Deploy the room before the client bundle that matches it. A client built against a new schema cannot join a room still serving the old version, so shipping the client first only moves the disconnect earlier. See schema changes and migrations.

The first hour

Watch	Where	What bad looks like
`rss`	`irtio status`, dashboard Metrics	Rising without falling back. Per-room state is not bounded, and the worker is heading for its heap limit
Room worker restarts	`irtio logs`	Any at all. Three inside a minute closes the room
`egressBytes`	`irtio status`, dashboard Metrics	Climbing toward your allowance. At the wall, sockets close with code 4290 and nothing else uses that code
Handler errors	`irtio logs`	Throws inside `tick`. Three consecutive throwing ticks stop the room, which restarts from its last snapshot
`sockets` and `roomsByState.*`	`irtio status`	Rooms stuck in `starting`, or a socket count that does not fall when players leave
Room list last-seen	`npx irtio rooms`	A frozen timestamp on a room you expect to be busy
Usage against the cap	`npx irtio usage`	Anything near a meter’s allowance on day one

Two behaviours to expect rather than diagnose. A cap refuses new work and never cuts off a player who is already connected, so the meters keep moving for a while after a wall goes up. And a wall takes about 95 seconds to apply for room hours and data out, because the check is not made on the join path.