Gameye Now Supports GitHub Container Registry

If your game server already builds in GitHub, it can now run on Gameye without passing through Docker Hub. Gameye pulls private images straight from GitHub Container Registry (ghcr.io), and with one webhook in place, every build you push is registered and preloaded on Gameye’s nodes automatically.

GHCR support is live today on Gameye’s self-serve platform. Docker Hub works exactly as before, and you can use either registry.

---

Why GHCR

Most studios already keep their server code, their CI and their release tags in GitHub. Until now, getting a build onto Gameye meant pushing it to a second registry and keeping a second set of access rules in sync. With GHCR:

• Your image stays where it’s built. GitHub Actions publishes it with the repository’s built-in GITHUB_TOKEN. There’s no personal access token to create or rotate.
• The package stays private. Gameye reads it through its own GitHub account, gameyedocker, which you give Read access to that one package. You never share a token with Gameye, and access to the package doesn’t give Gameye your repository’s code.
• New builds arrive on their own. A GitHub webhook tells Gameye about each new tag. Gameye registers it and starts preloading it onto nodes, so it’s ready to start sessions without a manual step.

How it works

The GHCR getting-started guide walks through every step. In short:

1. Publish from GitHub Actions. Add the workflow from the guide to the repository that holds your Dockerfile. Each run builds a linux/amd64 image and gives it a unique tag, such as build-12-1-3f9c2ab.
2. Give Gameye Read access. In the package’s settings on GitHub, invite gameyedocker with the Read role.
3. Create the application. In the Admin Panel, set Image Registry to ghcr and Repository URL to your image, for example ghcr.io/studio-name/game-server.
4. Add the webhook. Point a GitHub webhook for Packages events at Gameye, following step 5 of the guide for the webhook URL and secret. From then on, each tag you push shows up on the Tags page as Preloading, then Ready.

Then start a session exactly as you do today, with POST /session, your application name as image, and the tag as version.

Three things to get right

The guide covers these in detail, but they cause most first-time problems:

• Use a new tag for every build. Gameye nodes cache images by tag, so pushing latest again doesn’t deliver a new build. The guide’s workflow creates a unique tag on every run.
• Match the owner to your Gameye organization. Gameye pulls a private image only when its GitHub owner matches your Gameye organization name. For organization studio-name, the image must be ghcr.io/studio-name/<package>.
• Untick inherited access first. If the package inherits access from its repository, GitHub hides the Invite teams or people button. Untick Inherit access from source repository in Package settings to grant gameyedocker Read access.

Get started

Follow the GHCR getting-started guide to run your first session from a private GHCR image. If you’re new to Gameye, start a Developer Trial, or talk to us about moving an existing pipeline over.