Skip to main content
An update creates a new release. Players keep the current release until a reviewer approves and publishes the new one.

​
Before you start

  • The game folder your previous deploy was linked from. In a fresh checkout, link the folder to the game first.
  • A signed-in CLI, or a creator token with access to that game.

​
Ship an update

1

Deploy a new private preview

The published game keeps serving the old release.
2

Play it in your private preview

Confirm that the preview’s release ID is the one you mean to submit. opengame status --watch shows its checks and review state.
3

Submit that release for review

This sends the release to review. While OpenGame’s submissions go to a jam, it is also a jam entry, and you give that jam’s answers; enter a jam covers the form and certification.
4

Wait for approval

When a reviewer approves and publishes the release, it replaces the live one.
If you deploy while an earlier deploy is still being checked, the newer one becomes the preview and the older one is kept as history. A release in review stays in review when you deploy another.

​
Keep edits made on the website

The game’s title, description, cover and the other product fields can be edited on opengame.io as well as in opengame.json. A reviewer can also correct a game’s kind, for example from game to mod, and opengame pull brings that into opengame.json like any other edit. The server keeps a revision number for them, and .opengame/project.json records the revision of your last deploy or pull.
  • Keep the website’s values. A plain opengame deploy does this. When the website is newer, the deploy still succeeds and lists the fields it kept.
  • Bring them into opengame.json. Run opengame pull. It keeps your build and SDK settings and, when anything changed, backs up the old file to .opengame/manifest-before-pull.json. A cover lands in opengame-assets/; commit it. Pull only after any deploy from this folder has finished.
  • Replace them with yours. Run opengame deploy --metadata=local.
The CLI prints a line whenever a deploy keeps the website’s values over yours, or replaces them with yours. .opengame/ is git-ignored, so a fresh clone is not linked, and deploying it unlinked creates a second game. Clone the repository, then find the game’s ID with opengame games and link the folder to it:

​
Deploy from CI

1

Make a deploy-only token pinned to the game

The browser shows the token once.
2

Set the job's variables

Store the token as a CI secret and expose it to the job as OPENGAME_TOKEN. Set OPENGAME_API_URL to the internal origin.
3

Link and deploy from the game folder

Link each fresh checkout before deploying:
Use the game ID you pinned the token to. A game-restricted token cannot create a different game from an unlinked checkout.
A deploy-only token cannot submit. Submitting needs the submit scope, and certifying always happens in a person’s browser. A token made in settings does not expire, so revoke it in settings when you are done. Only a token from opengame login lapses, after 90 days without a request. opengame token revoke --id <id> opens that page.

​
Know what is kept

When a release’s bytes are deleted, its record stays as history with its check results.

​
Fix a problem

The game was edited on opengame.io after your last deploy or pull. Run opengame pull to bring those values into opengame.json, or deploy with --metadata=local to replace them with yours.
The error is deploy_in_progress. This folder has an unfinished deploy. Run opengame status, let that deploy finish, then pull.
The folder was deployed unlinked, which linked it to a new game. Run opengame link --game <id> --replace with the original game’s ID before the next deploy.
A deploy-only token cannot submit. Give the job a token with the submit scope, or submit from your own signed-in CLI. Either way, a person certifies in a browser.

​
Where next

Enter a jam

Submit a release, pick a track and certify it.

Read the CLI reference

Look up every flag for deploy, pull, link and token.