Updates, Patches and Rollback

What promoting a build does#

Once a game is live, every change players receive goes through the same step: you pick a Ready build on the Creator Dashboard and push it to the live server. The platform assigns the new version label, archives the build that was live, swaps the server over to the new content, and tells connected players that a new version is available.

You do this from the game page's Update tab. The left-hand Push a build card holds the rollout choices; the right-hand Builds list is where you pick the build. Nothing here needs the editor: pushing builds from the editor is covered in Push a Build from the Editor, and the first deployment of a game goes through the Launch wizard instead (see Launch and Hosting).

Hotfix or full update#

The Rollout type control offers two ways to release the same build. They differ in the version label they produce and in whether you can attach a public post.

Each button previews the label it would produce (for example Quick fix · v3.1 and New version · v4), and the push button repeats it: Push hotfix · v3.1 or Push update · v4. The numbering rules themselves are described in Builds and Versions.

An update post is optional. If you tick Add an update post you must either fill in both Title and Release notes or pick a Saved draft from the dropdown; a half-written post is rejected rather than silently dropped. Save as draft (don't push yet) stores the text as an unlisted post you can attach to a later push. Release notes are capped at 20,000 characters.

Push a build to the live server#

1. Open your game on the dashboard and select the Update tab.
2. In the Builds list on the right, click a build marked Ready (or an older one marked with its version label; see Rolling back). It appears under Selected build on the left.
3. Leave Destination on Live server.
4. Choose a Rollout type: Hotfix or Reload completely.
5. Leave Timing on Deploy now, or pick Schedule (see below).
6. For a full update, optionally tick Add an update post and write or select the post. For a hotfix, optionally fill in Note (optional).
7. Click Push hotfix · vX.Y or Push update · vX.

While the deploy runs the card shows a spinner and progress text (Preparing update…, Stopping the server…, Deploying new build…, Starting back up…) with the hint "This can take up to a minute — the server restarts onto the new build." When it finishes, the card reads Update is live in production. with "Players will get it on their next connect." Click Done to return to the form.

Above the tabs, a deploy progress banner tracks the platform's deploy job through Queued, Preparing, Provisioning, Deploying, Verifying, Finalizing and Done. When the job ends the banner stays, showing the outcome — Deploying update — complete for a successful update — until the next deploy replaces it.

What happens on the server during a push:

• The previously live build is marked Archived; the pushed build becomes Live and records its version label and promotion time.
• On dedicated hosting the platform first tries a hot reload of the running server, which needs no restart. If that is not possible it falls back to a cold restart; if players are connected at that moment they are warned in game that the server is restarting for an update in 30 seconds, and the restart waits out those 30 seconds. Free community hosting always restarts the container onto the new build.
• Any beta server and any test server running for the game are stopped, and a build that was on beta returns to Ready.
• Connected clients receive an in-game notice that the new version (or patch) is live and that they should finish their session and reconnect.
• The History tab's Server Activity timeline records an Update deployed or Hotfix entry.

If the deploy fails#

If the new build cannot be verified (for example your server scripts crash on start), the progress banner switches to Restoring previous version… and the platform reverts to the build that was live before; the banner then reads Your game crashed with the error and the note "This deploy was rolled back because your game code crashed on start. Fix the error above and push again." The database is rolled back too: the failed build returns to Ready, the previous build is live again, the version bump is undone and any update post created for the failed push is removed.

Infrastructure errors are retried automatically (the banner shows attempt 2/3). After the final attempt the job fails and the message includes the last error and an excerpt of the server log.

If you try to push while another deploy is still running, the request is refused with "A deploy is already in progress for this game." Wait for the banner to finish, then push again.

Schedule a deployment#

Use Timing → Schedule to deploy at a specific moment, for example to line a release up with an announcement.

1. Configure the push as above, then click Schedule under Timing.
2. Pick a Date and Time. The form shows the resolved local time ("Scheduled for Fri, Mar 27, 8:00 PM"); the push button becomes Schedule vX.
3. Click it. The card confirms Deployment scheduled.

From then on the game page shows a cyan Update v4 scheduled (or Patch v3.1 scheduled) banner with the build name and number, the date, and a live countdown. Click its Cancel button to drop the schedule; nothing is deployed and the build stays Ready. The deploy progress banner also lists it as, for example, "Scheduled deploy scheduled for Fri, Mar 27, 8:00 PM".

Rules the platform applies to schedules:

• The time must be in the future. The version label shown on the banner is the one the deploy will get; it is assigned when the deploy actually runs.
• The platform checks for due schedules every minute, so the deploy can begin up to a minute after the time you set.
• About a minute before the deploy, connected players are told in game that the server is restarting for an update (or patch) in about 30 seconds. If that warning was missed, it is sent inline just before the restart.
• The scheduled build must still be Ready (or on Beta) when the time comes. If it has been deleted or deployed some other way in the meantime, the schedule is cleared without deploying anything.

Roll back to an earlier version#

A rollback re-deploys the content of a build that was live before. It does not create a new version label: the old build's label (say v3) shows as live again, and the game's current version reverts to it.

There are two ways to roll back:

From the History tab. Open History, find the version under Version History (entries marked Archived are eligible), and click Rollback to this version. A dialog titled Rollback to this build explains that it "will replace the current live version with the content from this previously promoted build"; confirm with Rollback. The timeline records a Rolled back entry, and in-game players are told the server rolled back to that version.

From the Update tab. Archived builds are also selectable in the Builds list. Selecting one shows a warning: "This is an outdated build. Pushing it will roll your live game back to this older version — are you sure?" Pushing it runs as a normal hotfix or update and therefore does produce a new version label (for example the v2 build comes back as v4.1). Use the History tab when you want to keep the original label.

A rollback uses the same hot-reload-then-cold-restart path as a push, including the 30-second in-game warning before a cold restart. If the rollback's deploy fails, the build returns to Archived and the error is shown; nothing is left claiming to be live.

Only builds with a status of Live or Archived can be rolled back to. A Ready build that has never been live is pushed, not rolled back.

Superseded deploys and builds#

Two different things on the dashboard use the word superseded:

• A superseded deploy job. A rollback or a Take Offline request may interrupt a deploy that is still in flight, because both exist to stop a bad situation quickly. The interrupted job ends with the banner heading Superseded by a newer deploy; the build it was deploying is not live. An ordinary push never interrupts a running job; it is refused with the "deploy already in progress" message instead.
• The superseded build status. This belongs to the platform's two-phase (stage, then promote) deploy, where the previously live build is marked superseded rather than archived when the staged build takes over. The dashboard exposes no stage or promote actions today, so you will not normally see it; treat it like Archived.

Builds that are live, on beta, or still uploading cannot be deleted. Ready and Archived builds can; see Builds and Versions for Recently Deleted and restore.

Engine updates#

Your game server runs on the platform's server engine, separate from your build. When a new engine release is published, a banner appears at the top of the game page for dashboard members: Engine update available, tagged Critical, Recommended or Optional, showing the engine version currently running, the target version and the estimate "~2 min downtime". A Release notes disclosure shows what changed.

• Update now starts the update. It is available to members whose role includes server shutdown rights (owners and developers; see Members, Roles and Staff).
• Snooze 24h hides the banner for a day in your browser. It is not offered for Critical releases.

While the update runs the banner shows Engine update in progress with the step it is on: Queued — waiting for next cron tick, Draining — refusing new connections, Stopping — broadcasting shutdown to remaining players, Pulling new image, Starting new container, and finally Update complete — engine is healthy. Draining waits for players to leave, for up to five minutes, before the server's own 30-second shutdown countdown begins. If the update fails, the banner reads Engine update failed with the error and offers Retry update.

The banner is only shown for games on dedicated hosting whose server is reporting telemetry. It does not appear for free community hosting.

Reference#

Update tab controls#

Server Activity entries related to deploys#

With AI (MCP)#

promote_build deploys a finalized build live with type:"update" (requires update_title and update_body) or type:"patch" (requires patch_note), timing:"now" or "scheduled", and needs confirm:true to actually go live; dryRun:true previews the request. rollback_build takes the build to roll back to and also requires confirm:true. Both return before the deploy finishes, so follow up with get_deploy_status (stage, attempt, error, terminal flag) or wait_for_deploy (blocks up to 300 seconds by default, polling every 5). list_builds finds build IDs and get_live_status reports what is deployed right now.