Publish and test a game

Publishing is available

Publishing creates an immutable web release that anyone with its unlisted link can play without an Airogel account. Only account administrators can publish, republish, or unpublish a project.

From the Projects dashboard, choose Publish… for a draft or Manage for a published project. The project page contains the Publishing section and its current readiness status.

Publish a game

1. Run every playable scene and resolve any problems listed in the Publishing section.
2. Select Publish game.
3. Follow the persisted progress through Project data, Assets, Runtime bundle, and Go live. The page updates automatically; reloading it does not lose the current status.
4. Open the generated URL or use Copy link.

A public URL has this form:

https://<project-slug>-<16-character-key>.airogeledit.org

What a release contains

A release snapshots the project’s active scenes, objects, scene settings, scripts, materials, shaders, and referenced assets. Editor changes made afterward do not modify the live release. The project page warns when the editor contains unpublished changes.

Republish builds a new version and atomically makes it live at the same URL. The hostname stays stable even if the project title changes. If a republish fails, the previous successful release remains live. Recent versions and their statuses appear under Release history. A failed version is removed from it after 30 days and a replaced one after 90, but the live version and the most recent replaced versions are always kept.

Readiness checks

Publishing is blocked until the project has an active initial scene, an active camera in that scene, supported objects and assets, and valid references to materials, scripts, shaders, and assets. A build already in progress also blocks another publish.

Warnings do not block publishing. They are listed under Before you share and call attention to a missing project preview, an asset over 50 MB that may load slowly, a convertible asset that has not been optimized, or delivered assets over 60 MB that may be unreliable on phones.

The initial publishing limits are:

• 100 active scenes and 5,000 scene objects.
• 250 scripts and 250 shaders.
• 100 MB per source asset and 500 MB of source assets in total.
• 20 MB for the runtime bundle.

How many games an account can keep live at once depends on its plan: 1 on Free, 10 on Creator and 50 on Studio. At the limit, the Publishing section names it and, where a plan allows more, links to the plans. Unpublish another project to free a slot, or upgrade.

An MCP client can do all of this too: projects_publish_check returns the same errors and warnings with a hint for each, projects_publish starts a build, and projects_publication_status follows it until it is live. Publishing over MCP needs the publishing:write scope and, as in the editor, an account administrator. projects_unpublish takes a game down, with the same scope. The in-editor AI assistant can run the same check, but only you can publish. See the MCP tool guide.

Publishing multiplayer games

Multiplayer configuration is part of the immutable runtime bundle. Enable and configure multiplayer before publishing, set Player slot (multiplayer.playerSlot) on every player-controlled character or vehicle, or spawn each player's from a spawn template, and republish whenever settings, slot assignments, script roles, authority actions, weapon templates, entity templates, or presentation events change. Existing rooms remain pinned to the release and limits with which they were created. How many players a room holds and how long it can run also depend on your plan; see Build and test a multiplayer game. A plan change applies from the next room, without republishing.

A multiplayer game is played in rooms run by a room server, and publication checks that the game can run there. As well as the action schema, the paired combat templates, their weapon-to-projectile references, entity asset and material references, and the presentation event schema, it refuses:

• a player slot on anything but a character or vehicle, a slot that is not a whole number within the room's capacity, or two objects in one scene on the same slot;
• a game with no player slots, no character or vehicle spawn template, and no authority actions, since nothing a player does could reach it, and a game that declares authority actions but has no scene script in any scene to receive them;
• a scripted object that is not slotted, not a camera, and not a GUI element but has no Script runs on setting (multiplayer.scriptRole) of "authority" or "presentation";
• more than 32 replicated objects placed in a scene — authority scripts plus objects with Replicate on — a vehicle with more than 10 wheels, and a "presentation" object that is dynamic, a trigger, a character, a vehicle, cloth, a ragdoll, or a constraint;
• a presentation script that changes the game, a character's or vehicle's control script that reads the clock or branches on a result only the room server knows, and a call to scene.loadScene or scene.restart from any script but the scene script;
• two settings that contradict each other, such as a player's character declared "presentation"; a weapon on anything but a character or vehicle, or one the combat library does not define; Replicate on an object the room server cannot move; and a spawn template that shares its name, has a player slot, has a script below its root, or is or contains something a room cannot copy.

Each refusal names the scene, object, and script, and what to change. Warnings — a slotted object with no script, a slot nobody is bound to, a camera that does not follow a slotted object, a weapon nothing carries, a setting nothing reads where it is, a replicated object that can never move, a scene script loading a scene that does not exist — do not block publishing. For a multiplayer game the section also lists, collapsed under How scripts run in a multiplayer room, where each script will run and why.

Multiplayer participants must sign in even though solo players can open an unlisted public game without an account. Preview can simulate slots, but only the published URL exercises private rooms, one-time credentials, the room server, and reconnect. If a room's server is lost during play, the room ends. See Build and test a multiplayer game for the complete authoring and test checklist.

Public runtime behavior

The player loads release-scoped JSON and copied release assets instead of mutable editor records. Runtime-created Lua objects remain temporary and disappear when the game or scene ends. Test the published URL on the desktop and mobile devices you intend to support; editor Preview is not a substitute for testing the delivered release.

Analytics

Select Analytics beside a live link to review plays, unique players, load success, crashes, restarts, bundle load-time distribution, recent failures, and most-visited scenes over 7, 14, 30, or 90 days. For a multiplayer game, Script errors lists the errors its room servers caught in authority scripts, with the object, callback and message; any account member can open it.

Unpublish

Unpublish immediately makes the public page and runtime bundle unavailable, and new release-asset requests stop resolving. A signed R2 asset URL issued before unpublishing can remain usable for up to five minutes. Release history and the generated hostname are retained. Publishing the project again reuses the same hostname.