GameFabric Game Server Setup: 13 Steps After Hathora Exit [2026]

Two of the best-known names in dedicated game server hosting disappeared within six weeks of each other in 2026. Unity shut down direct support for Multiplay Game Server Hosting on March 31, and Hathora Cloud followed on May 5 after its team was absorbed into Fireworks AI. Thousands of multiplayer titles running on either platform needed somewhere to land, and the company that absorbed most of that traffic is GameFabric, the orchestration platform built by Nitrado, the German game-hosting firm best known for Minecraft and Rust rental servers.

GameFabric is not a rebrand of Nitrado’s old rental-server panel. It is a Kubernetes-based, Agones-powered orchestration layer that blends Nitrado’s bare-metal network with elastic cloud capacity, exposed through a single API, a single dashboard, and a single fleet model. This tutorial walks through the entire process of standing up a dedicated game server on GameFabric from a cold start: containerizing a build, wiring in the Agones SDK lifecycle calls, configuring environments and regions, deploying an Armada, and allocating a server through the API so a matchmaker can hand a player a working session. It is written for developers who were running on Hathora or Unity Multiplay and need a working replacement, and for anyone evaluating dedicated game server hosting from scratch in late 2026.

Why Hathora and Unity Multiplay Both Shut Down in 2026

The timing of the two shutdowns was close enough that it rattled the entire multiplayer backend market. Unity ended direct operation of Multiplay Game Server Hosting on March 31, 2026, and licensed the underlying software to Rocket Science Group so existing titles could keep running without an immediate forced migration. Unity’s other multiplayer services, including Matchmaker, Relay, Lobby, and Vivox voice chat, were not affected by the change (per Unity’s own support documentation); only the dedicated-server hosting layer itself was discontinued as a directly operated Unity product.

Hathora’s exit came five weeks later and was more abrupt. Hathora announced on March 4, 2026 that it would discontinue its game-company hosting service, freeze the platform, and fully shut it down within 90 days. The company’s engineering talent moved toward AI infrastructure work under an acquisition by Fireworks AI, and on March 5 Nitrado and Hathora jointly announced a migration partnership: Hathora customers would get a tailored migration plan and direct support from GameFabric’s infrastructure team. The platform itself went dark on May 5, 2026.

GameFabric’s own migration page frames the deal plainly, stating that Hathora selected GameFabric as the transition partner for its existing customers. For studios that had built their matchmaking and session logic around Hathora’s API, that gave them a named destination instead of a scramble across a dozen smaller providers. The same pattern played out for Unity Multiplay customers a few months later, when GameFabric published a migration guide aimed specifically at teams coming off Unity’s hosting layer.

2026 Timeline: How the Migration Wave Unfolded

The sequence of events matters if you are trying to understand why GameFabric suddenly became a default answer to “where do I host dedicated game servers now.” The table below lays out the public record as documented across Nitrado’s, GameFabric’s, Unity’s, and Hathora’s own announcements and release notes.

Date	Event
March 4, 2026	Hathora announces it will discontinue its game-company hosting service and freeze the platform within 90 days.
March 4-5, 2026	Nitrado and Hathora jointly announce a migration partnership routing Hathora customers to GameFabric, with direct support from GameFabric’s infrastructure engineers.
March 31, 2026	Unity ends direct operation of Multiplay Game Server Hosting, licensing the software to Rocket Science Group for continuity of existing titles.
May 5, 2026	Hathora’s game-hosting platform goes fully offline after the 90-day freeze period.
August 15, 2026	GameFabric refreshes its core documentation and API usage examples, including the Branch/push-image/launch-Vessel onboarding flow.
September 17, 2026	GameFabric updates its environment and region setup documentation with the current workflow this tutorial follows.
Late September-October 2026	GameFabric publishes a dedicated Unity Multiplay migration guide and refreshes its homepage positioning around combined bare-metal and cloud capacity.

What stands out in that timeline is how little lead time studios actually had. Ninety days separated Hathora’s announcement from its full shutdown, and Unity’s transition to Rocket Science Group happened in roughly the same window. Any team that waited to start a migration until the shutdown date itself was already behind, which is part of why GameFabric’s documentation updates cluster so heavily in the August-through-October period — the platform was actively being hardened in response to real migration traffic, not released once and left alone.

What GameFabric Actually Is

GameFabric describes itself as an API-first platform for deploying, allocating, scaling, and monitoring multiplayer dedicated servers. Under the hood it runs on Agones, the open-source Kubernetes extension for game server lifecycle management originally built by Google and Ubisoft. That matters for a tutorial because it means GameFabric does not invent its own proprietary SDK for server lifecycle signaling. A game server binary built for GameFabric needs to call the same readiness, allocation, and shutdown functions it would call on any other Agones-based platform, including Oracle’s OKE-hosted Agones clusters or a self-managed Agones install on raw Kubernetes.

The part that differentiates GameFabric from a plain Agones cluster is the infrastructure underneath it. GameFabric can run game server workloads on Nitrado-owned bare-metal hardware, on elastic cloud capacity provisioned on demand, or on a mix of both inside the same fleet, switching priority between capacity types using what the platform calls Region Types. According to GameFabric’s own homepage copy, cloud capacity is billed per second with no reserved-capacity minimums, while bare-metal capacity is positioned for studios that know their sustained concurrency and want predictable monthly costs instead of elastic per-second billing.

GameFabric’s documentation describes the onboarding experience as deliberately short: create a Branch, push a container image, and launch what the platform calls a Vessel — its term for a running game server instance. GameFabric Cloud specifically allows developers to provision and deprovision cloud locations directly from the GameFabric UI without needing a separate cloud provider account or subscription, which removes a step that platforms like raw Agones-on-EKS or Agones-on-OKE normally require.

Network Footprint: Why Bare Metal Still Matters for Latency

Independent comparison coverage from Gameye, a competing dedicated-server host, describes GameFabric as running on Nitrado’s own network across more than 67 locations — a vertically integrated footprint built from the same physical hosting infrastructure Nitrado has used for consumer Minecraft, Rust, and ARK rental servers for over a decade. That history is worth understanding because it explains GameFabric’s core pitch: most cloud-only platforms provision virtual machines inside a handful of hyperscaler regions, while Nitrado’s bare-metal network reaches into secondary cities and markets that AWS, Azure, or GCP do not operate dedicated regions in.

For a competitive shooter or battle royale title where sub-30ms latency is the difference between a server region feeling “local” and feeling unplayable, that extra geographic reach can matter more than raw compute price. It is also the reason GameFabric’s Region Type system defaults studios toward prioritizing bare metal first and falling back to cloud capacity second, rather than the other way around — the bare-metal tier is where the platform’s actual latency advantage lives, and the cloud tier exists mainly to absorb demand spikes the fixed bare-metal footprint cannot.

Prerequisites

Before starting the setup, make sure the following are in place. Version numbers below reflect what was current and documented as of October 2026.

A GameFabric account with an active Environment created in the dashboard at gamefabric.com (self-serve signup; bare-metal capacity commitments go through a sales conversation).
Docker Engine 27.x or newer installed locally, for building and pushing the game server container image.
A container registry GameFabric can pull from — Docker Hub, GitHub Container Registry, or a private registry with credentials you can hand to a GameFabric Service Account.
A dedicated server build for your engine. Linux builds are the primary supported target; Unity headless Linux server builds and Unreal Engine Linux dedicated server builds both work once containerized.
The Agones SDK for your server’s language (Go, C++, C#, Node.js, or Rust bindings are all officially maintained by the Agones project) integrated into your server binary.
curl or an HTTP client capable of making authenticated REST calls, for working with the GameFabric API directly.
Optionally, Terraform 1.9 or newer if you want to manage GameFabric fleet configuration as code rather than through the UI — GameFabric publishes an official Terraform provider for this purpose.
Basic familiarity with Kubernetes concepts (pods, readiness probes, graceful termination) will make the Agones lifecycle integration much faster, since GameFabric’s allocation model mirrors Kubernetes pod lifecycle semantics closely.

Step 1: Create a GameFabric Environment

An Environment is the top-level administrative boundary in GameFabric. Everything else — regions, service accounts, container images, and deployments — lives inside one. Most studios create at least two: a staging Environment for testing new builds and a production Environment that matchmaking actually points at.

Log into the GameFabric dashboard, select Create Environment, and give it a name that reflects its purpose (for example, “staging” or “prod-na-eu”). GameFabric’s documentation groups the next steps as: create and manage Service Accounts, build and push a container image, then deploy your game servers. Each Environment maintains its own set of Service Accounts and credentials, which keeps staging credentials from accidentally leaking into a production deployment pipeline.

Step 2: Create a Region and Set Region Type Priority

Regions in GameFabric are created inside an Environment and determine where your game servers physically run. The documented flow is: open the Regions section of the Environment, select Create Region, provide an internal name and a display name, then select Next.

From there, you create one or more Region Types and assign each a priority — lower priorities are considered first when GameFabric allocates capacity. This is the mechanism that lets a studio say “prefer our dedicated bare-metal hardware in Frankfurt, and only fall back to elastic cloud capacity if bare metal is saturated.” You select the physical or logical locations that belong to each Region Type, and you can optionally attach environment variables that get passed into every game server launched in that location — useful for region-specific configuration like default tick rate or regional matchmaking pool IDs.

Get the Region Type priority order wrong and you can end up routing players to cloud capacity with different latency and cost characteristics than you intended, so test each capacity type independently before relying on automatic fallback in production.

Step 3: Containerize Your Dedicated Server Build

GameFabric accepts a single containerized Linux game server image and takes care of the rest: provisioning, scaling, health checking, allocation, and teardown, according to GameFabric’s own migration guidance for studios leaving Unity Multiplay. That means your first real engineering task is turning your dedicated server executable into a Docker image, if it is not one already.

FROM debian:bookworm-slim

RUN apt-get update && apt-get install -y 
    ca-certificates libstdc++6 libc6 
    && rm -rf /var/lib/apt/lists/*

WORKDIR /game
COPY ./build/LinuxServer /game/LinuxServer
COPY ./build/GameData /game/GameData

ENV GAMEFABRIC_PORT=7777
EXPOSE 7777/udp

ENTRYPOINT ["/game/LinuxServer"]
CMD ["-batchmode", "-nographics", "-port=7777"]

Build and push the image to a registry GameFabric can reach:

docker build -t registry.example.com/mygame/server:1.0.4 .
docker push registry.example.com/mygame/server:1.0.4

Keep the image lean. A bloated image with unused engine editor assets baked in slows down scale-up time, which defeats the point of elastic capacity — if a new game server instance takes 90 seconds to pull and start because the image is 4 GB larger than it needs to be, your matchmaker queue backs up during a concurrency spike exactly when you need fast scaling the most.

Step 4: Integrate the Agones SDK Lifecycle Calls

This is the step most teams migrating from Hathora or Unity Multiplay underestimate. Both of those platforms abstracted away lifecycle signaling to varying degrees; GameFabric, running on Agones underneath, expects your server binary to explicitly call the Agones SDK’s readiness, allocation, and shutdown functions. GameFabric’s own migration documentation puts it directly: containerize your server binary if you have not already, then integrate the Agones SDK to manage server lifecycle — calling the ready function when the server can accept players, handling the allocated state, and calling shutdown when the session ends.

Here is a minimal Go example showing the three calls that matter most:

package main

import (
    "log"
    "time"

    sdk "agones.dev/agones/sdks/go"
)

func main() {
    s, err := sdk.NewSDK()
    if err != nil {
        log.Fatalf("could not connect to agones sdk: %v", err)
    }

    // Keep the local sidecar aware the process is alive
    go func() {
        tick := time.Tick(2 * time.Second)
        for range tick {
            if err := s.Health(); err != nil {
                log.Printf("health ping failed: %v", err)
            }
        }
    }()

    // startGameServer() is your own init code —
    // bind the socket, load the map, etc.
    startGameServer()

    // Tell GameFabric this instance can accept players
    if err := s.Ready(); err != nil {
        log.Fatalf("could not mark ready: %v", err)
    }

    waitForMatchEnd()

    // Tell GameFabric the session is over and the
    // instance should be recycled or torn down
    if err := s.Shutdown(); err != nil {
        log.Printf("shutdown call failed: %v", err)
    }
}

A process that never calls Ready() will sit in a pending state and never receive player traffic. A process that calls Ready() before it has actually finished booting — before the map is loaded and the socket is bound — will get marked available and then fail the moment a player connects. Both failure modes are the single most common source of “working test deploy, broken production fleet” bug reports in Agones-based platforms generally, not just GameFabric specifically.

Step 5: Create Service Accounts and Authenticate

Service Accounts are how your CI pipeline, your backend matchmaking service, and your local CLI sessions authenticate against the GameFabric API. Create one per Environment, scoped to the minimum permissions it needs — a CI deployment account that pushes new builds should not have the same permissions as a backend account that only needs to call the Allocator endpoint.

Once a Service Account exists, GameFabric issues credentials you plug into either the dashboard’s API token field or an environment variable your deployment scripts read. Store these the way you would store any production secret: in a secrets manager, never committed to the repository that holds your Dockerfile.

Step 6: Configure the Deployment and Push the Build

With the Environment, Region, and Service Account in place, point GameFabric at your pushed container image and define the deployment configuration: the image tag, the port the server listens on, resource requests (CPU and memory per instance), and any environment variables the binary expects at startup.

GameFabric exposes this through both its dashboard UI and its REST API. The documented API pattern for interacting with core resources follows a consistent URL shape:

curl -X GET 
  "https://${GAMEFABRIC_URL}/api/core/v1/environments/${ENV}/regions" 
  -H "Authorization: Bearer ${GAMEFABRIC_TOKEN}" 
  -H "Content-Type: application/json"

Swap the path for deployments once the environment and region exist, and you have a scriptable way to push new configurations from a CI pipeline rather than clicking through the dashboard every release.

Step 7: Create an Armada and Set Fleet Buffer Size

An Armada is GameFabric’s term for a managed group of game server instances within a specific region — roughly analogous to an Agones Fleet, but with GameFabric’s region-type and capacity-priority logic layered on top. Inside the Armada configuration you set how many warm, idle instances to keep running as a buffer (so a new match does not have to wait for a cold container pull and boot), and the maximum number of concurrent instances the Armada is allowed to scale to.

A buffer that is too small means players queue during spikes while new instances cold-start. A buffer that is too large means you are paying for idle capacity around the clock. Start with a buffer sized to roughly 10-15% of your typical peak concurrent match count, then tune it after watching a week of real allocation latency data in the dashboard.

Step 8: Call the Allocator API From Your Matchmaker

Deploying fleets and allocating a server to an actual match are two separate concerns in GameFabric’s architecture. Once your Armada has warm capacity available, your backend matchmaking service calls GameFabric’s Allocator /allocate endpoint to request a game server for a formed match. GameFabric’s own GameLift-integration documentation specifies this exact requirement: the backend service is required to call the GameFabric Allocator /allocate endpoint to request a game server.

curl -X POST 
  "https://${GAMEFABRIC_URL}/api/allocator/v1/environments/${ENV}/allocate" 
  -H "Authorization: Bearer ${GAMEFABRIC_TOKEN}" 
  -H "Content-Type: application/json" 
  -d '{
    "armada": "ranked-na-east",
    "region": "na-east",
    "metadata": {
      "matchId": "m-884213"
    }
  }'

The response hands back the connection details — IP address and port — that your matchmaker forwards to the matched players so their clients can connect directly to the allocated instance. Note that GameFabric’s comparison documentation flags the Allocator service as something that may need to be ordered separately from basic fleet deployment on some plans, so confirm it is active on your account before building your matchmaker integration around it.

Step 9: Test a Stream End-to-End From the Dashboard

Before wiring up a real matchmaker, manually trigger an allocation from the GameFabric dashboard or a direct curl call and connect a game client to the returned address. Confirm the server actually accepts the connection, the map loads correctly, and gameplay functions as expected at the chosen Region Type’s latency profile. This step catches container networking mistakes — wrong port exposed, UDP vs TCP mismatch, firewall rules blocking the allocated port range — before they show up as player-facing connection failures.

Step 10: Configure Terraform for Repeatable Deployments (Optional)

GameFabric’s migration guidance for Unity Multiplay customers specifically recommends an infrastructure-as-code approach: connect via the API or Terraform provider to configure your fleet. If your studio already manages cloud infrastructure with Terraform, this keeps GameFabric Armadas, Regions, and Service Account permissions version-controlled alongside the rest of your stack instead of living only in a dashboard that someone could change by hand during an incident.

terraform {
  required_providers {
    gamefabric = {
      source  = "gamefabric/gamefabric"
    }
  }
}

provider "gamefabric" {
  token       = var.gamefabric_token
  environment = "prod-na-eu"
}

resource "gamefabric_armada" "ranked_na_east" {
  name           = "ranked-na-east"
  region         = "na-east"
  image          = "registry.example.com/mygame/server:1.0.4"
  buffer_size    = 12
  max_instances  = 200
}

Run terraform plan against a staging Environment first. Fleet-level resource definitions in Agones-based platforms can trigger a rolling replacement of every running instance if a field like the container image digest changes unexpectedly, which is disruptive if it happens against production during peak hours.

Step 11: Set Up Monitoring and Alerting

GameFabric’s dashboard includes built-in monitoring and profiling for allocation latency, instance health, and capacity utilization across regions. Set alert thresholds before launch, not after an incident. At minimum, alert on: Armada buffer dropping below a safe floor, allocation request failures above a small percentage, and any Region Type falling back to a secondary capacity class more often than expected, which usually signals the primary capacity pool is undersized.

Pipe these alerts into whatever on-call system your team already uses rather than relying solely on checking the GameFabric dashboard manually, since dedicated server outages during a weekend launch window are exactly the scenario this tutorial’s prerequisites assume you are trying to avoid.

Step 12: Run a Parallel Cutover From Your Old Platform

If you are migrating off Hathora or Unity Multiplay rather than starting fresh, do not flip all traffic to GameFabric in one deployment. Run both fleets in parallel, splitting a small percentage of new matches to GameFabric first — 5% is a reasonable starting point — while watching allocation latency, connection success rate, and session stability against your old platform’s baseline. Increase the split gradually over one to two weeks rather than cutting over all at once.

This also gives you time to recreate anything platform-specific that did not have a documented one-to-one mapping: custom health check timing, region-specific environment variables, or allocation metadata your matchmaker previously attached in Hathora- or Unity-specific formats.

Step 13: Decommission the Old Platform and Lock In Pricing

Once GameFabric is carrying full production traffic reliably, formally decommission the old fleet — remove matchmaker routing to it, revoke its API credentials, and archive its configuration rather than deleting it outright in case you need to reference old settings during a dispute or audit. If your studio negotiated a bare-metal capacity commitment with Nitrado for predictable sustained-concurrency pricing, confirm the contract terms and renewal date are documented somewhere your finance team can find them, separate from the engineering runbook.

GameFabric vs. Alternatives: Where It Fits

GameFabric is not the only destination for studios displaced by the 2026 shakeout, and it is not automatically the right fit for every team. The table below compares it against the two most common alternatives developers evaluate alongside it.

Platform	Infrastructure model	Lifecycle integration	Pricing model	Best fit
GameFabric (Nitrado)	Bare metal + elastic cloud, combined	Agones SDK required	Per-second cloud; quote-based bare metal	Studios wanting predictable bare-metal cost with cloud burst capacity
Gameye	Partner cloud + edge network	No platform-specific SDK required; runs existing container as-is	Usage-based, published per-vCPU-hour rates	Teams wanting to avoid any lifecycle code changes during migration
Amazon GameLift Servers	AWS EC2 instances, Spot or On-Demand	GameLift Server SDK required	Per-instance-hour, billed to the second	Studios already deep in the AWS ecosystem
Self-managed Agones on Kubernetes	Your own cluster, any cloud	Agones SDK required	Underlying cloud compute cost only	Teams with existing Kubernetes operations expertise

The practical distinction worth noting: Gameye markets itself specifically against the Agones-integration requirement, telling prospective migrants that their existing Docker image runs on Gameye as-is with no Gameye-specific SDK to add to the binary. GameFabric’s Agones foundation is a trade-off, not a flaw — it buys you compatibility with the broader Kubernetes game-server ecosystem, but it does mean budgeting real engineering time for lifecycle integration work if your previous platform abstracted that away.

Pricing: What’s Public and What Isn’t

GameFabric’s official marketing copy commits to two specific claims: cloud-tier capacity is billed per second, and there are no reserved-capacity minimums on cloud tiers. Beyond that, GameFabric does not publish a numerical rate card for CPU, memory, storage, or egress on its public pages as of October 2026 — bare-metal capacity in particular is quote-based through a sales conversation, which third-party comparison sites have independently confirmed when evaluating the platform.

Cost component	Cloud tier	Bare-metal tier
Billing granularity	Per second	Quote-based, typically monthly
Minimum commitment	None advertised	Negotiated per contract
Allocator service	May require separate activation	May require separate activation
Cost predictability	Variable with traffic	Fixed for sustained concurrency
Public rate card	Not published	Not published

Budget accordingly: request a cost estimate against your actual projected peak and average concurrency before committing engineering time to a full migration, and ask explicitly whether the Allocator API is included in your quote or billed as an add-on, since that distinction affects whether your matchmaker integration in Step 8 above works out of the box or needs an additional line item approved first.

Common Pitfalls When Deploying to GameFabric

These are the mistakes that come up most often among teams migrating a production fleet, based on the lifecycle and architecture patterns common to Agones-based platforms generally.

Calling Ready() too early. Marking a server ready before the map and all game-critical assets are actually loaded causes the first connecting player to hit a broken or incomplete session.
Skipping the Health() ping loop. Without periodic health signals, the Agones sidecar can mark a perfectly healthy instance as unresponsive and recycle it mid-match.
Oversized container images. Images bloated with unused editor tooling or debug symbols slow down cold-start time precisely when fast scaling matters most, during a concurrency spike.
Hardcoding configuration into the image instead of environment variables. This breaks the Region Type environment-variable injection feature and forces a full image rebuild for every regional configuration change.
Misconfigured Region Type priority. An incorrect priority order can silently route all traffic to the more expensive cloud fallback tier while bare-metal capacity sits idle.
Assuming the Allocator API is bundled by default. Some plans require it to be ordered separately; building a matchmaker integration before confirming this leads to a late-stage integration blocker.
Undersized Armada buffers. A buffer set too low for actual peak traffic produces player-facing queue times during launch windows or marketing-driven spikes.
Cutting over all traffic at once during migration. Skipping the parallel-run period in Step 12 removes your ability to compare GameFabric’s real-world allocation latency against your old platform before full commitment.
Not testing UDP port exposure in the container. Many dedicated server engines default to UDP for gameplay traffic; forgetting to expose and document this correctly in the Dockerfile causes silent connection failures that look like a platform bug but are a container misconfiguration.

Troubleshooting Guide

The issues below cover the most common failure patterns reported when standing up a new Agones-based dedicated server fleet, applied to the specific architecture GameFabric uses.

Server stuck in pending, never receives traffic. Check that your binary actually calls the SDK’s ready function and that the call succeeds without error — log the return value, do not assume it worked silently.
Instance marked unhealthy and recycled mid-session. Confirm the health ping loop is running on a tight enough interval (two seconds is a safe default) and that it is not blocked by a slow main thread.
Allocation request returns an error from the Allocator endpoint. Verify the Allocator service is active on your plan and that your Service Account token has the correct scope to call it.
Players can’t connect to the allocated IP and port. Check firewall and security group rules for the exact port range GameFabric allocates in your Region, and confirm your Dockerfile exposes the matching protocol (UDP vs. TCP).
New instances take too long to become available during a spike. Reduce container image size, increase the Armada buffer size, and check whether your chosen Region Type’s cloud fallback has a slower provisioning path than its primary bare-metal tier.
Terraform plan shows unexpected full fleet replacement. Compare the previous state’s image tag and digest against the new configuration; a digest change on a tag that looks unchanged is a common trigger for unwanted rolling replacement.
Region-specific environment variables aren’t reaching the container. Confirm the variables were attached at the Region Type level during Step 2, not just the deployment configuration, since both locations can define variables and the wrong one is easy to miss.
Costs higher than expected on the cloud tier. Check whether idle buffer instances are counted against per-second billing — an oversized buffer left running continuously accrues cost even with zero active matches.
Migration traffic split from the old platform shows worse latency than expected. Re-verify Region Type priority is actually routing to the geographically closest capacity rather than falling back unexpectedly to a distant region.

Advanced Tips for Production Fleets

Once the basic deployment is stable, a few refinements make a meaningful difference at scale. First, separate your Armada definitions by game mode or map rotation rather than running one monolithic Armada for every match type — this lets you tune buffer size independently for a high-demand ranked queue versus a low-demand casual mode instead of over-provisioning the casual mode to match ranked’s traffic pattern.

Second, if your studio operates in multiple geographic markets, define a distinct Region Type per market with bare-metal as the primary priority and cloud as the explicit fallback, rather than relying on a single global Region Type. This gives you per-market cost and latency visibility in the dashboard instead of one blended number that hides which market is actually driving your cloud overage.

Third, treat your Agones SDK integration as something to load-test independently of the rest of your game logic. Spin up a minimal test binary that does nothing but bind a socket, call ready, sleep, and call shutdown, deploy it to a staging Armada, and hammer it with scripted allocation requests. This isolates lifecycle bugs from gameplay bugs, which matters because the two failure modes look identical from a player’s perspective — a server that never responds — but require completely different fixes.

Finally, build your matchmaker’s retry logic to expect occasional Allocator failures during regional capacity exhaustion, and have it automatically retry against a secondary Region rather than surfacing a hard failure to the player. A brief fallback to a slightly higher-latency region beats a failed matchmaking attempt every time.

Complete Working Example: A Minimal Ranked Match Flow

Putting the pieces together, here is what a complete, minimal ranked-match flow looks like end to end, from match formation to a player connecting to a live GameFabric-hosted server.

Matchmaker service forms a match from the queue and generates a unique match ID.
Matchmaker calls the GameFabric Allocator /allocate endpoint, passing the target Armada, Region, and the match ID as metadata.
GameFabric selects warm capacity from the Armada’s buffer (or scales new capacity if the buffer is exhausted) and returns a connection IP and port.
The allocated game server container’s Agones SDK integration transitions from Ready to Allocated internally.
Matchmaker forwards the connection details to both matched players’ clients.
Players connect directly to the allocated instance over the exposed UDP port.
The game server runs the match, periodically calling the SDK health ping.
When the match ends, the server calls the SDK shutdown function.
GameFabric tears down or recycles the instance and the Armada’s buffer backfills to maintain its configured warm capacity.

That full loop, running reliably under load, is the actual deliverable of this tutorial — not just a server that boots, but a server that a real matchmaker can allocate, hand off, and recycle correctly under production traffic patterns.

Frequently Asked Questions

Is GameFabric only for studios migrating from Hathora or Unity Multiplay?
No. While the 2026 shutdowns drove a wave of migrations, GameFabric accepts new studios starting from scratch with no prior platform. The setup steps in this tutorial apply equally to a greenfield deployment.

Do I need to know Kubernetes to use GameFabric?
Not in depth. GameFabric’s dashboard and API abstract away raw Kubernetes manifests, but understanding pod lifecycle concepts (readiness, health checks, graceful shutdown) makes the Agones SDK integration step significantly faster to debug.

Can I run Unreal Engine dedicated servers on GameFabric?
Yes, as long as the server builds into a Linux container and implements the Agones SDK lifecycle calls. GameFabric does not publish an official engine compatibility matrix as of October 2026, so validate your specific build with Nitrado’s team before committing to a full migration.

How does GameFabric pricing compare to AWS GameLift Servers?
GameLift Servers publishes a per-instance-hour rate card tied to specific EC2 instance types. GameFabric’s cloud tier is billed per second with no published numerical rate card, and its bare-metal tier is quote-based. A direct cost comparison requires requesting a GameFabric quote against your specific concurrency pattern.

What happens if I don’t implement the Agones SDK calls correctly?
Your server will either never receive traffic (if it never calls ready) or will accept connections before it’s actually prepared to handle them (if it calls ready too early), both of which produce player-facing connection failures that look like platform bugs but are integration mistakes.

Is the Allocator API included by default?
Not necessarily. Third-party technical comparisons note that the Allocator service may need to be ordered separately from basic fleet deployment on some GameFabric plans, so confirm this explicitly with Nitrado before building a matchmaker integration around it.

Can I mix bare-metal and cloud capacity in the same fleet?
Yes. That is GameFabric’s core differentiator — Region Types let you prioritize bare-metal capacity first and fall back to elastic cloud capacity automatically when bare-metal is saturated, all within one Armada.

How long does a Hathora-to-GameFabric migration typically take?
It depends heavily on how much lifecycle abstraction your previous platform provided. Teams with minimal custom logic report migrations completed within a couple of weeks when working directly with GameFabric’s migration support team; teams with heavily customized allocation logic should budget longer for the parallel cutover period described in Step 12.