Every publish is checked, previewed and saved as a numbered version you can roll back to.
Publish Versions & Rollback
Every time you publish, Studio checks your content first, shows you exactly what changed since the version players are on, and saves what it sent as a numbered version. If a publish goes wrong, it stops and tells you where — and you can put the previous version back with one click.
Where to find it#
Server → Publish in the editor (the Server Control window). The panel shows the live version next to the title ("live: v12"), the Publish… button, the step list, and a Version history list underneath.
How to publish a version#
- Open Server → Publish and make sure your server is online.
- Press Publish…. Studio runs the preflight: a reference check (the same one as Project Health) and the content validators for loot, quest objectives, events, conversations and the other structured fields.
- Read the preview. It lists every table with rows added, changed and removed since the live version, followed by any errors and warnings.
- Fix any errors and press Publish… again. Errors cannot be skipped.
- If there are only warnings, tick Publish anyway — I've read the warnings.
- Press Publish vN. The steps run in order; the first one saves the version, the last one tells your server which version it now runs.
What the preflight checks#
| Check | Error when… | Otherwise |
|---|---|---|
| References — a record points at an item, ability, mob, quest… that no longer exists | the record was added or changed since the live version, or the thing it points at was deleted since then | a warning (already live) |
| Content fields — loot rows, quest objectives and rewards, map events, conversations, avatar configs, object passability… | the row was added or changed since the live version | a warning (already live) |
| Event calls — a map or common event calls a common event that is gone, or is bound to a deleted NPC | never — these do nothing at runtime | a warning |
| Database updates that failed on this project, quests gated above the level cap | never | a warning |
Problems that are already live never block you: the preflight stops you shipping new breakage, while old problems show as warnings until you fix them.
The steps#
| Step | What it does |
|---|---|
| Preflight & snapshot version | Runs the preflight again on the server (so nothing slips through), opens version N and saves a copy of every published table |
| Optimize media, Cook assets | Prepare your media — a few assets that cannot be optimised are a warning |
| Media manifest | Sends your media list first, so every definition that uses an image or sound finds it on the server. A few media rows that cannot be sent are a warning |
| Game definitions | Sends the definition tables, parents before the records that point at them (elements before abilities, factions before NPCs). If a table fails, the publish stops here and says which table and why — nothing after it is sent |
| Maps & rendering, Terrain chunks | Send maps and terrain. A failure in maps or terrain stops the publish |
| Apply on live server | The server reloads the world |
| Stamp live version | Marks version N as published and tells the server, which then reports it on its status page |
When a publish fails#
The step turns red, the message names what failed, and the version is recorded as failed. Your server may now hold part of the new content, so choose one:
- Retry publish — runs the check and the whole publish again (only what the server lacks is sent, so this is quick).
- Roll back to vN — restores the last published version and publishes it.
To make a failed publish leave the live world untouched instead, turn on Flip Publishing. Whatever reaches the server is checked again as it loads — see When the Server Finds Broken Content.
Rolling back#
Open Version history and press Roll back on a version (or use Roll back to vN after a failure).
- Studio shows how many rows would come back, change back or be removed. Nothing has changed yet.
- Press Roll back & publish. Studio first saves your current content as a backup version, then restores the chosen version into your project, then publishes it.
- The new publish is recorded as a rollback of the chosen version.
To undo a rollback, roll back to the backup version it created.
Fields in the version history#
| Field | Meaning |
|---|---|
| vN | The version number — one per publish attempt, rollback backups included |
| Status | published (reached the live server), failed (stopped part-way), backup (your content before a rollback), rollback (a publish that restored an older version), pending (running now) |
| Date · author | When it finished and who published it |
| Rows | How many rows the version holds across all published tables |
Gotchas#
- Only the last five versions can be rolled back to. Older versions stay in the history but their saved copy is removed to save space.
- What a version holds: definitions (items, mobs, abilities, quests, NPCs, events…), maps, map objects, tilesets, wall faces and world config. Terrain chunks and media files are not in a version — media is never deleted by a publish, and terrain is rebuilt from the maps.
- A rollback changes your project, not just the server. That is why it saves a backup first. If a player-owned record still points at something the rollback would remove, the rollback is refused and nothing changes.
- The first versioned publish has nothing to compare with. Every row shows as added and every problem is a warning; map events are validated from the next publish on.
- A server older than this feature still receives the publish; it just cannot report the version, and the last step shows a warning.
- Checking which version is live: your server's
/statuspage has acontentVersionfield (the version number, content hash and time; the author is shown only to callers with the admin key). - Server operators:
PUBLISH_PREFLIGHT=warnin the editor's environment turns preflight errors into warnings;PUBLISH_PREFLIGHT=offswitches the check off. Use it only to get an urgent fix out.
Publishing from Copilot#
Copilot can publish and roll back for you with three tools:
| Tool | What it does | Asks first? |
|---|---|---|
List Published Versions (publish-versions) | Lists your versions, which one is live, and which can still be rolled back to | No — read only |
Publish Content Version (publish-run) | With dry run, runs only the preflight and reports errors, warnings, what changed and whether the gate would let it through. Without it, publishes a new version | Dry run: no. A real publish: always, in every approval mode |
Roll Back to a Published Version (publish-rollback) | With dry run, shows what would change per table. Without it, backs up your current content, restores the version and publishes it (unless told not to publish) | Dry run: no. A real rollback: always, in every approval mode |
Ask for example "check whether my content is ready to publish" (a dry run) or "publish with the note Harvest update". Copilot never publishes past errors, and only passes warnings when you tell it to. With dry-run mode on in Copilot settings, every publish and rollback is a preview. A publish or rollback cannot be undone with /undo — roll back to the previous version (or to the rollback's backup version) instead. Copilot's transactional plans cannot include a real publish or rollback; each one gets its own approval card.
For AI tools and scripts#
The same operations are available at /api/ai/publish: GET lists versions; POST { "op": "preflight" } returns the report; POST { "op": "publish", "dryRun": true } shows what would ship and whether the gate allows it; POST { "op": "publish", "acknowledgeWarnings": true } publishes; POST { "op": "rollback", "version": 12, "dryRun": true } previews a rollback, and without dryRun restores and publishes it.