CI/CD and deployment automation
This guide covers the full pipeline from code push to running deployment: triggering builds automatically, deploying images to target instances, and choosing the right automation strategy for each environment.
Overview #
CI/CD for Heroic Cloud has two parts. Continuous Integration (CI) triggers Nakama builds automatically when code is pushed to your repository. Continuous Delivery (CD) deploys successful builds to target instances, either automatically or with manual approval.
CI/CD workflows apply to Nakama only. Satori doesn’t use the build pipeline. LiveOps changes go through the Satori console. See Satori deployments.
Prerequisites #
- A Nakama Builder connected to your GitHub, GitLab, or Bitbucket repository. See Builders.
- A service user with Trigger permission on the relevant builder.
- Access to your repository’s CI/CD settings (for example, GitHub Actions secrets).
Part 1: Continuous integration #
The goal is to trigger a Heroic Cloud build automatically every time code is pushed to your repository.
Step 1: Create a service user #
- Create a service user in Heroic Cloud (for example, named “GitHub Actions CI”).
- Copy the service user’s secret token. Store it securely as it’s only shown once.
- Assign Trigger permission on the relevant builder, and add the service user to the relevant builder. This is the only permission the service user needs. Follow the principle of least privilege.
See Access control for details on service user permissions.
Step 2: Store the token in your CI system #
For GitHub Actions:
- In your GitHub repository, navigate to Settings > Secrets and variables > Actions.
- Add the service user token as a repository secret (for example,
HEROIC_CLOUD_TOKEN).
For GitLab CI, add the token as a CI/CD variable in your project settings.
Step 3: Create the CI workflow #
Create a workflow file that calls the Heroic Cloud API on each push, authenticated with the service user token.
The flow:
- A developer pushes code to the repository.
- Your CI system triggers the workflow.
- The workflow calls the Heroic Cloud API to trigger a build.
- The builder compiles the code and produces a container image.
The following example triggers the Heroic Cloud builder and polls for the result. Add it to your repository at .github/workflows/heroic-cloud-build.yml, replacing the env values with your own.
| |
Key parameters:
| Parameter | Description | Example |
|---|---|---|
organization_name | Your Heroic Cloud organization slug. | my-studio |
builder_name | The name of the builder to trigger. | my-game-builder |
nakama_image | The Nakama on Heroic Cloud image version to build against. | heroiclabs/nakama-enterprise:3.24.0-r1-mc |
service_user_email | The service user email. Store as a GitHub secret. | ci-bot@my-studio.com |
service_user_secret | The service user secret token. Store as a GitHub secret. | mK9pLx2vNqRt5wYz |
retry_interval | Seconds to wait between polling attempts (default: 30). | 30 |
timeout_interval | Maximum seconds to wait before failing (default: 600). | 600 |
Store HEROIC_CLOUD_SERVICE_EMAIL and HEROIC_CLOUD_SERVICE_SECRET as encrypted secrets in your GitHub repository. Never commit credentials to your repository.
What happens if the build fails? #
A failed build doesn’t affect any running deployments. The failed image is never deployed anywhere. Your existing instances continue running the last successfully deployed image. Fix the issue in your code and push again.
Part 2: Continuous delivery #
Once builds trigger automatically, you need a strategy for getting those images onto your Nakama instances.
Auto-deploy #
Auto-deploy connects a builder to one or more Nakama instances. When a build completes successfully, the resulting image deploys to the specified targets automatically, with no manual intervention.
Configure auto-deploy from the builder settings menu to target one or more instances.
Auto-deploy limitations #
Auto-deploy is available for Nakama only. Satori doesn’t have auto-deploy.
Manual deployment #
Deploy any completed build manually from the builder page or from the Nakama deployment itself. Both methods use a rolling update with no downtime.
Recommended deployment strategy #
| Environment | Deploy method | Why |
|---|---|---|
| Development | Auto-deploy | Fast iteration. Every successful build deploys immediately. |
| QA | Auto-deploy | QA always has the latest build for functional testing. |
| Production | Manual only | Requires explicit human approval after QA validation. This is a deliberate gate. |
The key principle: automate everything up to production, then require a human decision for the final promotion. This gives you speed during development and safety for live traffic.
The complete flow #
With CI and CD fully configured:
- A developer pushes code to the repository.
- GitHub Actions (or GitLab CI) calls the Heroic Cloud API to trigger a build.
- The builder compiles the container image.
- Auto-deploy pushes the image to development and QA instances.
- The QA team validates the build on their instance.
- A release engineer manually deploys the validated image to production.
See also #
- Builders and repository setup for creating and configuring builders.
- Nakama deployments for deployment configuration.
- Access control for service user permissions.
