Publish your game

The shape of a release#

Publishing is two halves that talk through the platform. The editor turns your project into a build and uploads it. The Creator Dashboard takes that build and puts it on a server. Neither side can do the other's job: the editor never deploys, and the dashboard never edits content.

Everything you upload is tied to your project's game ID, which the New Project wizard generates and the editor registers with the platform the first time you open the project while signed in. That is why a freshly created project already appears under Your games on the dashboard's Home page, tagged In development, before you have pushed anything.

Step 1: Push a build from the editor#

What a build contains#

Procedure#

1. Sign in (the Account button, top-right) and open the project.
2. Click Publish in the top bar. If your listing is already published the same button reads Update. A dialog titled Publish Game (or Update Game) opens.
3. Under Current Version the dialog shows Live: v... or No build deployed yet.
4. Under New Build, type a Build name, "a label for this build (shown in history and on the dashboard)". Leave it blank and the build is named Build <today's date>.
5. Leave Incremental (bundles) off unless you have read Builds and versions. It uploads only content that changed since the last publish, and needs a client of v1.7.0 or newer.
6. Click Create Build. The dialog walks through:

7. On success the status line reads "Build '<name>' sent in <time> — opening the dashboard to push the update", the build joins the Build History list in the dialog, and your browser opens the game's Update tab on the dashboard.

If the pack is larger than 1 GB the dialog says so: "that's the download every player takes."

After the upload#

The editor does two more things on its own once a build lands. It syncs your item catalog (items.json and icons) to the platform so the dashboard's shop tools can pick items by name, and it saves a copy of the project source to the cloud so the project can be downloaded on another machine (see Cloud project sync). Neither affects the build if it fails.

If the upload fails#

A red panel explains what broke and what the next click does:

Check the content before you push#

Create Build runs a content-validation pass over your server/ data before it exports anything. It checks that every bound script path resolves to a real file, that each combat script declares an NpcCombatScript whose class name matches its file name, that no two bound scripts share a base name (the server matches bindings by file name, so a collision is ambiguous), and that no binding points at an entity that has been deleted.

• Any error stops the publish with a Content validation failed dialog: "Publishing is blocked: N error(s), M warning(s). Fix the errors and try again," followed by the first twenty problems and a count of the rest. The dialog's status line reads "Publish blocked: N validation error(s)."
• Warnings only ask. A Publish with warnings? dialog lists them and offers Publish anyway or Cancel.

That gate is a cross-reference check, not a full audit. For a wider sweep before a build real players will receive, run the MCP validate_project tool (see AI-Accelerated Creation), which reports, without changing anything, entities that exist on only one side of the client/server export, map placements that reference deleted NPCs or objects, script bindings pointing at missing files, drop tables rolling for items that no longer exist, and leftover temp files. Deleted or repurposed items matter most: player saves store bare item IDs, so any entity deleted since the current live build takes effect on every existing save the moment the new build goes live.

Step 2: Launch from the dashboard#

Open /dashboard, choose your game, and click Launch Game. It appears on a game that is still in development and has no server yet. The launch wizard has six steps, shown as a progress rail: Build, Details, Content, Hosting, Schedule, Confirm. Your answers are saved as a draft as you go.

After you confirm, the page tracks provisioning live: Confirming payment, Provisioning server, Installing game server, Deploying build, Going live. When it finishes you see "<Your game> is Live!" with the server, tier and region, plus Open Production Dashboard and View Store Listing. The game moves to the Published group in the editor's project hub and players can find it in the client's Discover browser.

Step 3: Ship updates#

Every later build follows the same push, then a promotion on the Update tab of the game page:

1. Push the build from the editor as above. It appears on the right of the Update tab as Ready.
2. Under Destination, choose Live server (or Beta to run it for testers, see Test your game).
3. Click the build to select it.
4. Under Rollout type, choose Hotfix (a quick fix that becomes the next patch, for example v2.1, with an optional one-line note) or Reload completely (a new version, for example v3, with an optional update post: a title and release notes players see, or a saved draft).
5. Under Timing, choose Deploy now or Schedule with a date and time.
6. Click Push hotfix · v2.1, Push update · v3 or Schedule v3. The panel reports Stopping the server..., Deploying new build..., Starting back up...; "this can take up to a minute" and "players will get it on their next connect."

Selecting a build older than the one currently live shows a warning that pushing it rolls the game back. The History tab keeps every promoted build with the time it went out. Full detail, including rollback and superseded builds, is in Updates, patches and rollback.

Versions at a glance#

Where each thing lives afterwards#

Depth on all of these: Builds and versions, Launch and hosting, Billing and lifecycle, and the Creator Dashboard section.

With AI (MCP)#

An agent connected through the Vastopia MCP server can run the same pipeline without clicking: export_pck and build_server_package produce the artifacts, create_build, upload_build_artifacts and finalize_build push them, list_builds and get_live_status read what is there, and promote_build (type update with release notes, or patch with a note) deploys to production, which always requires explicit confirmation. rollback_build reverts. See AI-Accelerated Creation.