CLI

`gm` is the command-line tool for Gamemanage. You use it from your terminal, a CI pipeline, or any script that needs to talk to the panel without opening the web UI. Anything you can do by hand in the panel (list servers, stream logs, restart, deploy) you can drive from `gm`. This page describes the tool; it is on the roadmap and not yet shipped.

Install

Install with npm if you already have Node on the machine:

npm install -g @gamemanage/cli

Or use the curl script, which drops a single static binary onto the host with no Node dependency:

curl -fsSL https://get.gamemanage.net | sh

Confirm it is on your PATH:

gm --version

Authentication

`gm` authenticates with a token, not your panel key. The panel key (`gm_live_xxxx`) is what your server agent uses to report in; it is not for the CLI. For interactive use on your own machine, run:

gm login

This opens the panel in your browser, you approve the session, and the token is written to a local config file. For CI or any non-interactive shell, skip `gm login` and pass the token through the environment instead:

export GM_TOKEN="..."
gm servers

Commands

List every server on your account, with its id and current status:

gm servers

Stream the console for one server. Without `--follow` it prints recent lines and exits; with `--follow` it stays attached and tails new output, which is what you want when watching a deploy or a crash:

gm logs <id> --follow

Restart a server. This is the same restart you would trigger from the panel, so the agent brings the process back up and reconnects:

gm restart <id>

Push your local changes up and apply them:

gm deploy

Using it in CI

The point of `gm` is to fold server management into a pipeline you already run. A typical job sets the token from secrets, deploys, then watches the logs so the job fails if the server does not come back clean.

1. 1Add your token to the CI provider's secret store as `GM_TOKEN`.
2. 2Install `gm` in the job, either with `npm install -g @gamemanage/cli` or the curl script.
3. 3Run `gm deploy` to push and apply your changes.
4. 4Run `gm restart <id>` if your change needs a restart to take effect.
5. 5Run `gm logs <id> --follow` to confirm the server reports back in cleanly before the job exits.

Note that log retention depends on your plan: Starter keeps 24 hours, Pro keeps 90 days. If you rely on `gm logs <id>` to inspect a past deploy rather than a live one, the window you can look back through is set by that limit.