Deploy from GitHub Actions

The Gameye Deploy action adds Gameye to the workflow that builds your game-server image. After each push, it:

1. Registers the tag with your Gameye application.
2. Waits until Gameye has pulled the tag in one or more regions.
3. Smoke-tests it (optional): starts a session on the new tag, checks that it stays running, then stops it. If the server crashes or never comes up, the job fails and prints the server’s logs.

Each run also writes a summary on the workflow run page, and it can record the deploy in the repository’s Deployments list.

It works with any registry Gameye can pull from, including GHCR and Docker Hub.

Using the GHCR webhook?

The GHCR webhook also registers new tags, so you can keep it. The action adds the wait and the smoke test, and it registers tags through the API, so it doesn’t depend on GitHub sending a package webhook.

Before you start

You need:

• A Gameye application for your image. See 3. Set up the Admin Panel, or step 3 of the GHCR guide.
• Gameye able to pull the image. For a private GHCR package, follow step 2 of the GHCR guide. Otherwise the wait step times out.
• A Gameye API token, stored as a GitHub secret (see below).

1. Create an API token

In the Admin Panel, create a token with only the scopes the steps you use need:

Step	Scopes
Register the tag	application:write, regions:read
Wait for the tag	regions:read
Smoke test	session:start, session:read, session:stop, and logs:read to print logs

In your GitHub repository, open Settings → Secrets and variables → Actions → New repository secret. Name it GAMEYE_API_TOKEN and paste the token.

2. Add the action to your workflow

Add a step after the one that pushes your image. This example builds, pushes to GHCR and smoke-tests the new tag:

name: Deploy game server

on:
  push:
    branches: [main]

permissions:
  contents: read
  packages: write

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5

      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Choose the image name and tag
        id: image
        shell: bash
        run: |
          # Docker image names must be lowercase; GitHub owners may not be.
          echo "name=ghcr.io/${GITHUB_REPOSITORY_OWNER,,}/game-server" >> "$GITHUB_OUTPUT"
          echo "tag=sha-${GITHUB_SHA::7}" >> "$GITHUB_OUTPUT"

      - uses: docker/build-push-action@v6
        with:
          push: true
          platforms: linux/amd64
          tags: ${{ steps.image.outputs.name }}:${{ steps.image.outputs.tag }}

      - uses: gameye/deploy-action@v0
        with:
          api-token: ${{ secrets.GAMEYE_API_TOKEN }}
          application: my-game-server
          tag: ${{ steps.image.outputs.tag }}
          region: europe
          smoke-test: true

Set application to your Gameye application name, not the image reference. Enterprise customers add environment: production. The default is sandbox.

Wait for several regions

List the regions, comma- or newline-separated. The action waits until the tag is pulled in every one, and runs the smoke test in the first:

          region: europe, us-east

Show each deploy in the Deployments list

Set github-deployment to an environment name and give the job permission to write deployments:

permissions:
  contents: read
  packages: write
  deployments: write

      - uses: gameye/deploy-action@v0
        with:
          # ...the inputs above...
          github-deployment: gameye-sandbox

Each run then appears under Deployments on the repository’s main page, linked to its log and marked in progress, successful or failed. If the action can’t write the deployment, it logs a warning and the deploy carries on.

What a run looks like

Registered tag sha-3f9c2e1 on application my-game-server.
Waiting for my-game-server:sha-3f9c2e1 to be pulled in europe...
Tag sha-3f9c2e1 is available in europe.
Started smoke-test session 6b1d… on 203.0.113.10.
Session 6b1d… is running.
Session stayed running for the smoke-duration. Smoke test passed.
Stopped session 6b1d….

The run page’s summary shows how long each region took to pull the tag, the smoke-test result with the session’s host and ports, and, when it fails, the error and the server’s last 50 log lines.

Good to know

• Smoke tests are real sessions. They count against your quota like any other session. By default the session must stay running for 60 seconds (smoke-duration).
• Warm pools. A warm pool hands out an already running container and ignores the requested tag. Smoke-test in a region without a warm pool for the application. The action fails with a clear message if a warm pool served an older tag.
• Cleanup. The action stops the session when the test ends, and again if the job is cancelled. As a backstop, the session has a TTL: the startup and smoke durations plus five minutes.
• Arguments and environment. Pass program arguments with smoke-args (one per line) and environment variables with smoke-env (KEY=VALUE, one per line).

For every input and output, see the action’s README.