Branch Management: The Release Pipeline Your Game Server Infrastructure Is Missing

Most studios don’t have a bad release because they shipped with bugs. They have a bad release because they don’t have an effective release system in place.

The code passed, QA signed off, and then the wrong release got pushed. This is a very real problem; one that almost every live-service studio has to solve at some point.

With GameFabric’s Branch Management features, we give you full control over your branching strategy and release pipeline. Here we’ll explain exactly what that looks like.

Branch Management is our built-in release pipeline for game server images. The concept is simple: you create Branches that mirror the stages of your development workflow, then organize game server versions inside them. Most teams start with a Development branch and a Production branch, while studios with a distinct QA gate can easily add a third pipeline.

When your new build passes your testing, you promote the validated image from one branch to the next. Armadas, our session-based server fleets, and ArmadaSets reference images by both branch and tag, so live deployments only ever pull from the branches a studio has explicitly designated as production-ready. Meaning a dev build can’t reach players by accident because the infrastructure invokes a “you shall not pass” protocol. There is no configuration flag to misconfigure, no script to forget to run. The wrong build is structurally excluded.

This is the difference between release safety as a process and release safety as a guarantee.

One of the features studios appreciate most, especially if they’ve ever had to manage a live crisis without it, is immutable tags. Once you push an image tag to GameFabric, you can’t overwrite it. Pushing the same image:tag combination again fails at the registry level.

This completely eliminates an entire category of production incidents. When a tag is mutable, saying "we deployed v2.3.1" becomes ambiguous the moment someone pushes a new image to that tag. Incident post-mortems turn into archaeology. With immutable tags, that ambiguity disappears. A given image:tag always refers to exactly the same content, which means a given deployment is reproducible, auditable, and safe to roll back to. Combined with our platform-wide audit logs, studios have a precise, tamper-proof record of exactly which build ran in production and when.

For studios that have been through a serious live incident, this is not a nice-to-have. It is the thing you wish you had when you were trying to figure out what was actually running at 4 in the morning.

A busy CI/CD pipeline produces a lot of images and dev branches especially accumulate artifacts very fast. The registry itself is built into GameFabric at no additional cost, so clutter won’t show up on your bill, but it can slow your team down. Without automatic cleanup, your registry gets messy quickly, and it gets harder for anyone to find the image they’re actually looking for. 

Each branch carries configurable Image Retention Policies. The defaults are sensible out of the box: Production branches retain 30 days and 10 tags; Development and custom branches retain 14 days and 10 tags. When you need more precision, you can define multiple policies per branch, filtered by image name regex and tag pattern, so you can keep the last 10 release candidates while pruning nightly builds on a tighter cycle. We never delete images that are currently in use, regardless of what a policy would otherwise specify.

The result is that registry hygiene becomes automatic rather than a background engineering chore someone is perpetually behind on.

The most operationally important aspect of Branch Management is that promotion is a deliberate action. There is no automatic escalation from dev to production. A validated image moves to the next stage because an engineer made a conscious decision to promote it, and that decision is recorded.

This matters for two reasons: 

First, it creates a natural forcing function for QA. If QA hasn’t signed off on a build, it doesn’t move. The pipeline enforces the process rather than relying on everyone following it correctly.

Second, when something does go wrong in production, the promotion history gives you a precise starting point. You know exactly when a specific image entered prod, and you know exactly who promoted it.

If you have multiple teams shipping in parallel, branches also give each team its own space, so your backend team’s work-in-progress builds don’t clutter the view for QA validating a release candidate from the gameplay team.

Branch Management is fully accessible via the GameFabric API and Terraform. Studios running automated CI/CD pipelines can script image promotion directly into their release workflow, so the pipeline gates promotion rather than relying on manual steps. If you manage your infrastructure declaratively, you can reference branches in your Terraform config, and Armadas will pull from the correct branch as a function of how they are defined, not how they were last manually configured.

This is the release governance model that DevOps-forward studios build themselves when they outgrow basic container registries. The difference is that here, it ships with the platform.

Building a structured release pipeline for game servers is not hard engineering. But it is weeks of engineering. Someone has to design the branch model, wire up the promotion logic, add the audit trail, configure the cleanup jobs, maintain it as the team grows, and document it so the next engineer knows what they’re inheriting.

That is weeks of work that doesn’t make a single game better. It’s platform engineering, and it’s work that GameFabric has already done. Studios that choose to run on GameFabric get a production-grade release pipeline as part of the platform, configured in minutes, extensible via API, and available from day one.

Want to see how Branch Management fits into your release workflow? Explore our documentation or book a demo to walk through your studio's pipeline with our team.