mugon.net docs
CLI

Commands

What each mugon command does.

Run mugon --help for the list of commands, or mugon <command> --help for one command.

mugon init

Creates a new project in the current directory. It asks for a project name and a template (bevy, typescript or minimal; minimal also asks for the distribution and source folders) and writes a mugon.toml with a starter project.

The project name becomes the project ID: it is lowercased, spaces become dashes and other characters are dropped. It has to match the name of the game you created on mugon.net.

init refuses to run in a folder that already contains a mugon.toml.

mugon login

Stores the API key of a game so that other commands can talk to the platform.

mugon login
mugon login --project-id my-game --api-key $MUGON_API_KEY
FlagDescription
--project-idThe project ID (the game name). Read from mugon.toml if you run the command inside a project.
--api-keyThe API key. Skips the prompt, which is what you want in CI.

Without the flags the command prompts for what is missing. It checks the key against the platform before storing it, so a wrong key or a game that doesn't exist is reported right away. Keys are stored per project in ~/.mugon/config.toml.

mugon logout

Removes the stored key of a project.

mugon logout [--project-id <id>]

Without --project-id the command asks which project to log out of.

mugon dev

Runs your game locally the way the platform runs it. It starts, on the first free ports from 3000 upwards:

  • the platform page (what mugon.net shows around your game) on port 3000, the address it prints,
  • your game from the distribution folder, in a sandboxed frame with a strict content security policy like the platform's,
  • a local relay that stands in for the platform's network, so host and client can talk to each other.

In the page, choose Start as host in one browser tab and Start as client in another. The page shows the same loading overlay, file proxy and cache as production.

mugon dev runs the build command from mugon.toml (the dev scope if there is one) and again whenever a file under watch-paths changes. Reload the game tabs after a rebuild.

mugon publish

Builds the game and publishes it as a new version.

mugon publish
  1. Runs the build command (the default scope, or the dev scope if there is no default one).
  2. Checks the build output, see below.
  3. Creates the version on the platform and uploads the files in batches.
  4. Finishes the version, after which the platform validates and activates it.

If the upload fails halfway, the half-created version is deleted again.

The checks before uploading:

  • the distribution folder has an index.html at its root,
  • an @mugon/sdk is bundled in it,
  • its major version matches js-sdk-version in mugon.toml (a mismatch is an error, a different minor or patch version is a warning),
  • the first <script> of index.html contains the SDK (otherwise you get a warning, because large files then silently lose caching).

The SDK major of each version is recorded by the platform, see SDK versions.

Requirements: a mugon.toml in the current directory, and either a stored API key for the project (mugon login) or the MUGON_PROJECT_API_KEY environment variable.

mugon run

Runs a command that is defined in mugon.toml.

mugon run <command> [--scope <scope>]
Argument / flagDescription
commandThe name of a [[command]] entry, for example install.
--scopeThe scope to run it in. Defaults to default.

The entry is also matched against the operating system you are on, see project config.

On this page