Multiplayer studios have spent the past year watching their game-server hosting options shift under their feet. Hathora, once a popular pick for indie and mid-size teams, announced in March 2026 that it was joining Fireworks AI and would wind down game hosting entirely by May 5, 2026, pushing customers toward Nitrado’s GameFabric. That shakeup left a lot of developers re-evaluating who actually publishes clear pricing, doesn’t require an SDK baked into the game binary, and can take a Docker image straight to production. Gameye, a game-server orchestration platform running since 2017, has been picking up attention for exactly that reason: published per-vCPU pricing, no mandatory SDK, and a REST API that treats your existing container as the unit of deployment.
This tutorial walks through deploying a Dockerized multiplayer game server to Gameye from scratch: building a headless Linux server binary, containerizing it, pushing it to a registry, wiring up the REST API, and validating that a real client can connect to an allocated session. It also covers the pitfalls that trip up teams moving from Kubernetes-based orchestration (Agones) or SDK-driven platforms (PlayFab, GameLift) to a no-SDK model, plus the cost math you need before you commit real player traffic to it.
What Gameye Actually Is, and Why It’s Different From Agones or GameLift
Gameye is a game-server orchestration platform, not a game engine plugin or a matchmaking service. It deploys dedicated game servers globally across a mix of bare-metal and cloud infrastructure and exposes a single REST API for starting, tracking, and tearing down server sessions. According to Gameye’s own documentation, the platform runs across 21 infrastructure providers spanning more than 200 datacenters on six continents, blending dedicated bare-metal capacity with burst cloud capacity from providers including AWS, Google Cloud, Microsoft Azure, Akamai, and Tencent Cloud.
The core design decision that separates Gameye from Agones or Amazon GameLift is the SDK requirement. Agones expects your game-server binary to call lifecycle functions like Ready(), Allocate(), and Shutdown() through its SDK, and GameLift has its own server SDK with comparable lifecycle hooks. Gameye’s pitch, laid out on its platform overview page, is that you skip that step: you package your existing server binary into a standard Docker image, push it to a container registry, and call Gameye’s REST API to allocate a session. The orchestration layer handles placement, scaling, and teardown from the outside, without needing code inside your server process to report readiness.
It’s worth being clear-eyed about why this matters right now rather than treating it as an abstract architecture choice. The game-hosting market reshuffled hard in the first half of 2026. Hathora’s pivot to AI inference work stranded a real number of live titles mid-contract, and Unity’s own Multiplay service handed its hosting business off to a third party during the same stretch. Studios that got burned by a vendor exit are, understandably, weighting portability and low integration surface more heavily than they did two years ago. A Docker-image-plus-REST-API model is inherently more portable than one built around a proprietary SDK, because swapping providers later means re-registering an image and re-pointing API calls rather than ripping SDK calls out of your server codebase and replacing them with a different vendor’s equivalent.
That tradeoff matters for two groups of teams. If you’re running a custom engine or an older codebase where adding a hosting-vendor SDK would mean non-trivial engineering work, a no-SDK model removes a chunk of integration effort. If you already have deep expertise operating Kubernetes clusters and want granular control over autoscaling policy, network CNI, and node pools, Agones or a self-managed Kubernetes fleet still gives you more knobs to turn. Gameye trades some of that control for less integration surface and a single published price per vCPU-hour.
Prerequisites: What You Need Before Starting
This tutorial assumes a Linux-buildable dedicated server (Unity, Unreal, Godot, or a fully custom binary) and basic familiarity with Docker and REST APIs. Confirm these versions before you start:
| Tool / Account | Minimum Version | Notes |
|---|---|---|
| Docker Engine | 24.0 or later | Used to build and push the OCI-compatible image |
| Docker Compose (optional) | v2.20+ | Useful for local multi-container testing |
| Unity (if applicable) | 2021.2 or later | Needed for the built-in Dedicated Server build target; earlier versions use a headless Linux build with -batchmode -nographics |
| Gameye account | Active account with API key | Sign up directly through gameye.com, not through a reseller |
| Container registry access | Docker Hub, GitLab Registry, Amazon ECR, or Google Artifact Registry | Any OCI-compatible registry works; private registries need credentials configured on the Gameye side |
| curl or Postman | Any recent version | For calling the Session API directly while testing |
| A payment method on file | N/A | Gameye’s free evaluation environment has capacity limits; production traffic needs billing configured |
You’ll also want a basic understanding of your game’s network protocol (UDP or TCP) and the port your server binds to, since you’ll need to expose that explicitly in both the Dockerfile and the session request.
Step 1: Build a Headless Linux Dedicated Server
Whatever engine you’re using, the server binary needs to run without a display, without waiting on interactive input, and without requiring a GPU. For Unity 2021.2 and later, install the Dedicated Server build support module through Unity Hub, then in the editor go to File → Build Settings, switch the target platform to Dedicated Server, and select Linux as the target. This produces a headless binary with graphics and audio subsystems stripped out, which keeps the container image smaller and avoids pulling in libraries the game server will never touch. Gameye’s own Unity dedicated server guidance walks through this same build path if you want a second reference alongside Unity’s official docs.
If you’re on an older Unity version without the Dedicated Server module, build a standard Linux server build and launch it with -batchmode -nographics flags to suppress the rendering pipeline. Unreal Engine and Godot both support headless Linux server builds through their standard export/build pipelines; the exact steps vary by engine version, but the target is the same: a binary that starts, binds to a network port, and runs indefinitely without a window manager.
Test the binary locally before touching Docker at all. Run it directly on a Linux machine or VM, confirm it binds to the expected port, and connect a client to verify basic gameplay works. Debugging a broken server build is far easier outside a container than inside one.
Step 2: Write the Dockerfile
Gameye’s documentation recommends a Linux base such as Ubuntu 22.04 LTS, with the game’s network port explicitly exposed. Here’s a minimal working pattern for a custom or engine-exported server binary:
FROM ubuntu:22.04
# Install any runtime dependencies your engine needs
RUN apt-get update && apt-get install -y
libc6
libstdc++6
ca-certificates
&& rm -rf /var/lib/apt/lists/*
WORKDIR /server
COPY ./build/ /server/
RUN chmod +x /server/MyGameServer
EXPOSE 7777/udp
ENTRYPOINT ["/server/MyGameServer"]Swap in the correct executable name, port, and protocol (UDP or TCP) for your game. If your engine’s Linux build needs specific shared libraries (common with Unreal’s Linux dedicated server target), install them explicitly in the Dockerfile rather than assuming the base image already has them — this is one of the most common causes of a container that builds fine but crashes on start.
Step 3: Build and Test the Image Locally
Build the image and run it locally before pushing anything to a registry:
docker build -t my-game-server:latest .
docker run --rm
-p 7777:7777/udp
my-game-server:latestConfirm four things at this stage: the container starts without hanging on interactive input, it binds to the port you exposed, it logs a clear readiness message you can grep for, and it shuts down cleanly when you send it a stop signal (docker stop). That last point matters more than it looks — a server that ignores SIGTERM and has to be force-killed will behave the same way in production, which means players get dropped mid-match instead of getting a graceful disconnect message.
Step 4: Push the Image to a Container Registry
Gameye pulls your image from any OCI-compatible registry — Docker Hub, GitLab Container Registry, Amazon ECR, and Google Artifact Registry are all documented options. Tag the image with an immutable version number rather than relying on latest, since a mutable tag makes rollbacks and debugging painful once you have live sessions running against a specific build.
docker tag my-game-server:latest
registry.example.com/my-studio/my-game-server:1.0.0
docker login registry.example.com
docker push registry.example.com/my-studio/my-game-server:1.0.0If the registry is private, you’ll need to hand Gameye pull credentials in the next step — either through the dashboard or an API field for registry authentication, depending on which onboarding flow you’re using.
Step 5: Register the Image With Gameye
Log into the Gameye dashboard and register the image by providing the full image name and tag, registry credentials if the image is private, the container port and protocol, and any launch arguments or environment variables your server needs at startup. Gameye can pre-pull registered images across its network, which reduces the cold-start delay when a session is actually allocated — useful if your matchmaker expects sub-second server availability rather than a multi-second image pull on first request.
Double-check the port and protocol fields here against what’s actually in your Dockerfile’s EXPOSE line. A mismatch between the registered port and the exposed port is one of the most common reasons a session allocates successfully but players can’t connect — the container is running, but Gameye is routing traffic to a port nothing is listening on.
Step 6: Choose Target Regions
Gameye’s coverage spans North America, Europe, South America, Asia-Pacific, the Middle East, and Africa, with named locations including London, Amsterdam, Frankfurt, Singapore, Tokyo, São Paulo, Mumbai, Dubai, and Johannesburg. For a first deployment, pick two or three regions close to your expected player base rather than trying to cover every available location — you can always add regions later once you have real latency and demand data.
If your matchmaker already has regional player distribution data from a previous hosting setup, use it here. If you don’t, start with your primary market’s nearest region plus one adjacent region, and instrument latency from day one so you can make an evidence-based decision about expanding coverage.
Step 7: Allocate a Session Through the REST API
This is the step that replaces the SDK integration you’d otherwise need with Agones or GameLift. Your backend (typically the matchmaker) calls Gameye’s session endpoint with the registered image, a target region, and any launch arguments, and Gameye starts a container and returns the connection details players need.
curl -X POST "$GAMEYE_API_BASE/session"
-H "Authorization: Bearer $GAMEYE_API_KEY"
-H "Content-Type: application/json"
-d '{
"image": "registry.example.com/my-studio/my-game-server:1.0.0",
"region": "frankfurt",
"args": [
"--mode", "team-deathmatch",
"--max-players", "16"
]
}'Treat the field names, base URL, and authentication header above as illustrative rather than a guaranteed copy-paste schema — confirm the exact request format against your current Gameye dashboard and API documentation before wiring this into production code, since API surfaces evolve. The response includes a host IP and mapped port that your matchmaker hands off to the connecting client.
Step 8: Wire the Endpoint Into Your Matchmaker
Once Gameye returns a session’s host and port, your matchmaker needs to store the session identifier, hand the connection details to the players assigned to that match, track the session’s health and player count, and release or destroy the session once the match ends or the lobby times out. None of this lifecycle management lives inside the game-server binary in Gameye’s model — it’s entirely the matchmaker’s job, which is a meaningful architectural difference from an SDK-based platform where the server itself reports state changes.
Gameye’s integration list includes documented paths for Pragma Engine, Nakama, Unity Matchmaker, and Amazon GameLift FlexMatch, so if you’re already running one of those matchmaking layers, check for an existing connector before building a custom integration from scratch.
Step 9: Add Lifecycle and Failure Handling
Because there’s no in-process SDK reporting readiness or failure, your matchmaker needs to handle several failure modes explicitly: allocation requests that fail because a region is at capacity, containers that crash after allocation but before a player connects, players who never connect within a timeout window, and sessions that need to be forcibly torn down after a match ends. Build retry logic with a fallback region, and set a hard timeout on unconfirmed sessions so you’re not paying for containers nobody ever joined.
Step 10: Load Test Before Going Live
Run a synthetic load test that allocates sessions at the rate you expect during a real launch spike, not just steady-state traffic. Watch three things specifically: how long allocation takes under concurrent load, whether any region hits capacity limits and how gracefully your matchmaker’s fallback logic handles that, and whether your billing projection (Step 12) holds up against actual measured session duration and concurrency, not your original estimate.
Step 11: Set Up Monitoring and Alerting
Because Gameye’s orchestration sits outside your game binary, most of your visibility into server health has to come from your matchmaker’s own logging plus whatever session-status data the API exposes. At minimum, track allocation success rate by region, average and p99 allocation latency, session duration distribution (to catch containers that hang instead of shutting down), and hourly vCPU consumption against your budget. Feed these into whatever alerting stack you already run — Prometheus, Datadog, or a simple cron job hitting a status endpoint is enough to start.
Building a CI/CD Pipeline Around Your Gameye Deployments
Manually building, tagging, and pushing images works fine for the first deployment, but it falls apart the moment more than one engineer is shipping server builds. Wire the build-and-push steps from earlier into whatever CI system your studio already runs — GitHub Actions, GitLab CI, or Jenkins all handle this pattern the same basic way. The pipeline should build the headless server binary, run it through an automated smoke test that confirms the process starts and binds to its port, build and tag the Docker image with the commit hash or a semantic version, push it to your registry, and then call Gameye’s image-registration step automatically rather than leaving that as a manual dashboard click someone forgets to do.
# Simplified GitHub Actions step for build, push, and registration
- name: Build server image
run: docker build -t $REGISTRY/my-studio/my-game-server:$GITHUB_SHA .
- name: Push image
run: |
echo "${{ secrets.REGISTRY_PASSWORD }}" | docker login $REGISTRY -u ${{ secrets.REGISTRY_USER }} --password-stdin
docker push $REGISTRY/my-studio/my-game-server:$GITHUB_SHA
- name: Register with Gameye
run: |
curl -X POST "$GAMEYE_API_BASE/images"
-H "Authorization: Bearer ${{ secrets.GAMEYE_API_KEY }}"
-H "Content-Type: application/json"
-d "{"image": "$REGISTRY/my-studio/my-game-server:$GITHUB_SHA", "port": 7777, "protocol": "udp"}"Gate the registration step behind a manual approval for production releases, even if the build-and-push steps run automatically on every merge. That gives you a deliberate checkpoint before a new server version starts receiving live matchmaking traffic, and it gives you a clean audit trail of exactly which commit is running in each region if something goes wrong later. Keep the previous version’s image registered and available as a rollback target for at least a few days after any release — if a regression only shows up under real player load, you want to be able to route new sessions back to the last known-good build within minutes, not hours.
Capacity Planning for a Real Player Base
Capacity planning on a per-vCPU-hour platform is fundamentally a forecasting problem, not an infrastructure problem, which is a different mental model than sizing a fixed cluster. Start by estimating peak concurrent sessions, not average concurrent sessions — a launch weekend or a content-update spike can produce concurrency several times higher than your steady-state baseline, and that’s exactly when allocation latency and regional capacity limits matter most. Multiply your expected peak concurrent sessions by the vCPU allocation per session and the average session duration in hours, then apply the $0.07 on-demand rate to get a rough hourly cost ceiling during peak windows.
| Scenario | Peak Concurrent Sessions | vCPU per Session | Approx. Hourly Cost at Peak |
|---|---|---|---|
| Small indie launch | 50 | 0.5 | ~$1.75/hr |
| Mid-size studio, regional launch | 500 | 1 | ~$35/hr |
| Established live-service title, global peak | 5,000 | 1 | ~$350/hr |
| Major launch weekend spike | 20,000 | 1 | ~$1,400/hr |
These figures are illustrative math based on the published $0.07/vCPU-hour on-demand rate, not a guarantee of what your title will actually cost — real sessions rarely run a clean full hour, and per-second billing means your actual bill should track below these ceiling numbers if match durations are shorter. Use this table as a sanity check before a launch, not as a final budget line item, and re-run it with real telemetry once you have a week or two of production data. If your forecast shows sustained peak usage rather than occasional spikes, revisit the reserved-capacity pricing tier mentioned in Step 12, since committing to predictable baseline usage can meaningfully undercut the on-demand rate over a full billing cycle.
Step 12: Understand the Pricing Model Before You Scale
Gameye’s published on-demand rate is $0.07 per vCPU-hour, billed by the second with no minimum session length, at a standard ratio of 1 vCPU to 2 GB of RAM. The platform advertises no separate egress fees, with bandwidth included in the compute rate — a meaningful difference from providers that bill data transfer separately. Gameye also lists a reserved or committed-capacity rate around $0.035 per vCPU-hour for teams willing to commit to sustained usage.
| Platform | Published Pricing | SDK Required in Server Binary | Egress Fees |
|---|---|---|---|
| Gameye | $0.07/vCPU-hr on-demand, ~$0.035/vCPU-hr reserved | No | None advertised — included in compute rate |
| Edgegap | $0.00115/vCPU-minute (fractionable), billed per second | Optional | $0.10/GB monthly network egress |
| Agones (self-managed on GKE/EKS/AKS) | Free software; you pay standard cloud VM pricing per node | Yes — lifecycle SDK calls required | Standard cloud provider egress rates |
| Nitrado GameFabric | Not publicly published; requires a sales conversation | Yes, when built on Agones lifecycle integration | Not publicly published |
Run the math on your own concurrency before committing. A single continuously running 1-vCPU server at the on-demand rate costs roughly $0.07 × 24 × 30, or about $50 a month, before accounting for RAM tiers above the default ratio, storage, support-plan charges, or any contract terms specific to your account. Because billing is per-second with no idle infrastructure cost claimed, short match-based sessions that spin up and tear down quickly should, in principle, avoid paying for server time nobody used — but validate that against your actual invoice once you have a few weeks of production traffic, not just the marketing page.
Step 13: Plan Your Migration Path if You’re Coming From Hathora or GameFabric
If your studio is one of the teams displaced by Hathora’s March 2026 exit from game hosting, the good news is that the migration to a no-SDK platform like Gameye is mostly a re-registration exercise rather than a rewrite. Hathora’s own deployment model didn’t require a game-server SDK either, so if your server binary was already SDK-free, the heaviest lift is re-pointing your matchmaker’s allocation calls at a new API and re-registering your existing Docker image with the new provider. Budget time for re-validating region coverage and latency, since the two providers don’t necessarily operate identical datacenter footprints, and re-run your load test (Step 10) rather than assuming performance parity.
Common Pitfalls When Deploying to Gameye
A handful of mistakes account for most of the failed deployments teams run into during their first week on any no-SDK orchestration platform.
- Port mismatch between Dockerfile and session request. The container starts and looks healthy, but nothing routes to it because the exposed port in the image doesn’t match what’s registered or requested.
- Ignoring SIGTERM in the server binary. Without SDK lifecycle hooks, your process needs to handle standard shutdown signals gracefully on its own, or players get disconnected without warning when a session is torn down.
- Testing only steady-state load, never a launch spike. Allocation latency and regional capacity behave very differently under a sudden concurrency spike than under gradual, predictable traffic.
- Using the
latesttag in production. When something breaks, you can’t tell which build is actually running, and you can’t roll back to a known-good version cleanly. - Skipping a fallback region in matchmaker logic. If your primary region hits capacity or has an outage, a matchmaker with no fallback just fails allocation requests instead of degrading gracefully.
- Under-provisioning RAM relative to the 1:2 vCPU-to-RAM ratio. Games with heavier per-session memory footprints than the default ratio can hit out-of-memory kills that look like random crashes if you don’t account for the ratio upfront.
- Assuming pricing parity with your previous provider. Egress-included pricing and per-second billing change the math significantly compared to providers with separate bandwidth charges — recalculate rather than assuming your old budget still applies.
- Not instrumenting session duration from day one. Without this data, you can’t tell whether containers are hanging past match end and quietly burning budget.
Expected Output: What a Successful Deployment Looks Like
Once everything is wired correctly, a session allocation request should return a response resembling this within roughly a second or two of the API call:
{
"session_id": "sess_8f2a91c3",
"status": "running",
"host": "203.0.113.42",
"port": 7777,
"protocol": "udp",
"region": "frankfurt",
"created_at": "2026-09-24T14:02:11Z"
}Your matchmaker passes the host and port fields to connecting clients, and the game’s own network layer takes over from there. If the client connects and gameplay behaves normally, your deployment pipeline is working end to end. If the container logs show the process starting and binding correctly but no client traffic ever arrives, revisit Step 6 (port registration) before assuming it’s a client-side networking issue.
Troubleshooting Guide
These are the issues that come up most often once a Gameye deployment moves from a local test into a real regional rollout.
- Container starts but no client can connect. Check for a port or protocol mismatch between your Dockerfile’s
EXPOSEline, the port registered with Gameye, and the port your matchmaker is handing to the client. - Session allocation returns a capacity error. The requested region may be at capacity. Add a fallback region to your matchmaker’s retry logic instead of surfacing the error directly to players.
- Server process exits immediately after container start. Usually a missing shared library dependency in the base image — rebuild with verbose logging and check for missing
.sofile errors in the container logs. - High allocation latency under load. Confirm whether your image has been pre-pulled to the target region; a cold pull on first request adds meaningful delay compared to a pre-warmed image.
- Players report being dropped mid-match with no warning. Check whether your server binary is handling SIGTERM cleanly, or whether sessions are being force-killed by a timeout your matchmaker set too aggressively.
- Billing looks higher than your original estimate. Instrument actual session duration and compare it against the durations you used for your cost projection — matches running longer than expected, or sessions not being torn down promptly after players leave, are the usual culprits.
- Private registry image fails to pull. Re-verify the registry credentials registered with Gameye; expired tokens are a common cause of a working local build that fails to pull remotely.
- Inconsistent behavior between regions. Regional infrastructure isn’t always identical across bare-metal and cloud burst capacity; if one region behaves differently, isolate the test to that region specifically before assuming it’s a code issue.
- Session data missing after a match ends. If you need post-match analytics, make sure your matchmaker captures session metadata before releasing the session, since the container and its logs disappear once torn down.
Advanced Tips for Production Deployments
Once the basic pipeline is stable, a few refinements make a meaningful difference at scale. Pre-pull your image to every region you plan to use before a scheduled content update or launch event, rather than relying on organic traffic to warm the cache. Build a canary rollout path where a small percentage of new sessions get routed to a newly registered image version before you cut over fully, which limits blast radius if a build has a regression that only shows up under real player load. Track cost per concurrent player, not just total spend, since that’s the metric that actually tells you whether your server-side optimization work is paying off as your player base grows. And if you’re running a global title, consider whether player-reported latency data should feed back automatically into your region-selection logic rather than relying on a static region list you set once at launch.
Complete Working Example: A Minimal Session Allocation Service
Here’s a minimal Node.js service that ties the pieces together — it accepts a matchmaking request, calls Gameye’s session API, and returns connection details to the client. This is intentionally stripped down; production code needs the retry, fallback-region, and monitoring logic described above.
import express from "express";
import fetch from "node-fetch";
const app = express();
app.use(express.json());
const GAMEYE_API_BASE = process.env.GAMEYE_API_BASE;
const GAMEYE_API_KEY = process.env.GAMEYE_API_KEY;
const IMAGE = "registry.example.com/my-studio/my-game-server:1.0.0";
const FALLBACK_REGIONS = ["frankfurt", "london", "amsterdam"];
async function allocateSession(region, args) {
const res = await fetch(`${GAMEYE_API_BASE}/session`, {
method: "POST",
headers: {
"Authorization": `Bearer ${GAMEYE_API_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({ image: IMAGE, region, args })
});
if (!res.ok) throw new Error(`Allocation failed in ${region}: ${res.status}`);
return res.json();
}
app.post("/matchmake", async (req, res) => {
const { mode, maxPlayers } = req.body;
const args = ["--mode", mode, "--max-players", String(maxPlayers)];
for (const region of FALLBACK_REGIONS) {
try {
const session = await allocateSession(region, args);
return res.json({
sessionId: session.session_id,
host: session.host,
port: session.port,
region: session.region
});
} catch (err) {
console.warn(`Region ${region} failed, trying next:`, err.message);
}
}
res.status(503).json({ error: "No regions available" });
});
app.listen(3000, () => console.log("Matchmaker listening on port 3000"));Wrap this with the session-timeout, teardown, and monitoring logic from Steps 9 and 11 before pointing real player traffic at it, and swap the region list for one driven by your own player geography data once you have it.
How Gameye Compares to Agones, Edgegap, and PlayFab
The right choice depends heavily on how much infrastructure control your team wants versus how much you’re willing to hand off. Teams already running Kubernetes at scale, with dedicated platform engineers, often get more long-term value from Agones because it’s free software layered on infrastructure you already operate and understand deeply. Teams that want edge-optimized placement with a fractionable per-minute billing model and don’t mind an optional SDK tend to look at Edgegap. Teams already inside the Microsoft/Azure ecosystem, especially those using Xbox Live services, often default to PlayFab Multiplayer Servers for the tighter platform integration. Gameye’s niche is teams that want published, predictable per-vCPU pricing with bandwidth included, and who’d rather not modify their server binary at all to get there.
| Factor | Gameye | Agones (self-managed) | PlayFab Multiplayer Servers |
|---|---|---|---|
| Integration model | Docker image + REST API, no SDK | Kubernetes + Agones SDK lifecycle calls | Azure VM-hour billing + PlayFab SDK |
| Operational burden | Low — Gameye manages placement and scaling | High — you manage clusters, upgrades, scaling policy | Medium — managed VMs, but Azure-specific tooling |
| Pricing transparency | Published: $0.07/vCPU-hr on-demand | Standard cloud VM pricing per node, no separate fee | Published VM-hour rates plus zone-based egress |
| Best fit | Teams wanting minimal binary changes and predictable per-vCPU cost | Teams with existing Kubernetes expertise wanting full control | Studios already committed to the Azure/Xbox ecosystem |
Security Considerations for Production Game Servers
A no-SDK deployment model shifts more security responsibility onto your own container image and matchmaker rather than a vendor SDK. Keep your base image patched against known CVEs, since you’re responsible for the full OS layer inside the container rather than a managed runtime. Never bake API keys or registry credentials into the image itself — inject them as environment variables or secrets at deploy time. Rate-limit your matchmaker’s session-allocation endpoint so a client-side bug or a deliberate abuse attempt can’t spin up unlimited paid sessions against your account. And validate all launch arguments passed through the API before they reach the container’s command line, since unvalidated input flowing into a process launch is a classic injection vector regardless of which orchestration platform sits underneath it.
Frequently Asked Questions
Does Gameye require a game-server SDK in my binary?
No. Gameye’s documented model is Docker image plus REST API, with lifecycle and readiness handled through the orchestration layer and your own matchmaker rather than in-process SDK calls.
What does Gameye cost for a small indie project?
The published on-demand rate is $0.07 per vCPU-hour with bandwidth included and no separate egress fee. A continuously running single-vCPU server works out to roughly $50 a month before considering RAM tiers above the default 1:2 ratio or any account-specific terms — actual costs for match-based games with short session durations should be lower since billing is per second.
Can I migrate directly from Hathora to Gameye?
Since Hathora also used a Docker-based, largely SDK-light deployment model, migrating your container image to Gameye is generally a re-registration and matchmaker re-pointing exercise rather than a code rewrite. Re-run your load tests after migrating rather than assuming identical performance across providers.
Which game engines does Gameye support?
Gameye is engine-agnostic since the deployment unit is a Docker container rather than an engine-specific plugin. Documented guidance exists for Unity (via the Dedicated Server build module in 2021.2+) and general Linux server builds; Unreal, Godot, and custom engines work as long as they produce a headless Linux binary that can run in a container.
How many regions does Gameye support?
Gameye’s documented coverage spans North America, Europe, South America, Asia-Pacific, the Middle East, and Africa, with named locations including London, Amsterdam, Frankfurt, Singapore, Tokyo, São Paulo, Mumbai, Dubai, and Johannesburg, running across more than 200 datacenters and 21 infrastructure providers.
Is there a free tier to test Gameye before committing?
Gameye offers a limited evaluation environment for integration testing, though it’s capacity-limited and not intended for live production traffic. Check the current dashboard for the specific limits on your account tier before planning a public launch against it.
What happens if a region I’m using hits capacity?
Your matchmaker needs to handle this explicitly by retrying the allocation request against a fallback region, as shown in the example service above. Gameye’s API returns an error on a failed allocation rather than silently queuing the request indefinitely.
How does Gameye’s pricing compare to Edgegap or Agones?
Edgegap publishes a fractionable per-vCPU-minute rate plus a separate $0.10/GB egress charge, while Gameye bundles bandwidth into its $0.07/vCPU-hour rate. Agones itself is free open-source software, but you pay standard cloud VM pricing for the underlying nodes, plus the ongoing engineering cost of managing the Kubernetes cluster yourself.