Migration Guide

Edgegap to Gameye: A Container-Native Migration

You're already running Docker — so this isn't a rebuild. Swap how your server learns its port, drop the Arbitrium sidecar if you use it, and repoint your deploy call. What you gain: consistent 5 GHz bare metal, included egress, and game-aware DDoS at every location.

Container-native No rebuild Days, not weeks 5 min read
📦

Already containerized? Most of the work is done.

Edgegap and Gameye are both Docker-native, so your server image carries over as-is. The migration is configuration, not a rebuild — the only code touch is how your server reads its port. Everything below is the full surface.

Jump to the migration path →

Edgegap is a capable edge-orchestration platform — easy to start, broad geographic reach. Studios move to Gameye for two things the edge model doesn't solve: hardware consistency and bandwidth cost. Edgegap's public pool runs roughly 2.4–3.2 GHz across 17+ providers, so your tick rate depends on where a session lands; and it bills per-GB egress on top of compute and RAM, so the bill climbs with player traffic.

The good news: migrating doesn't mean re-architecting. You're already container-native — the move is mostly configuration, and your game doesn't change.

What changes
  • How your server learns its port (ARBITRIUM_PORT_GAMEPORT_INTERNAL → a fixed port in bridge mode, or Gameye's injected port var)
  • The Arbitrium Sidecar Agent / SDK — removed (Gameye needs none)
  • Your deploy call (Edgegap deploy API → Gameye POST /session)
  • Port-mapping config (Edgegap 1:1 mapping → Gameye container/host port declaration)
  • Where Gameye pulls your image from (point it at your registry)
What doesn't change
  • Your Docker image and server binary
  • Authoritative game server logic and netcode
  • Client connection flow (still receives IP + port)
  • Matchmaking rules and player grouping logic
  • Graceful shutdown (both platforms send SIGTERM)

Where does the cost difference come from?

Edgegap's per-vCPU rate looks low, but two more lines move the real total — bandwidth, and the hardware your sessions actually land on.

Per-GB egress

Edgegap bills bandwidth per gigabyte (~$0.10/GB) on top of compute. Game servers stream constant state to every player, so this scales directly with concurrency — for a busy multiplayer title it's often the single largest line. Gameye includes all bandwidth in its $0.07/vCPU/hr rate, on every provider and region.

Variable hardware

Edgegap's public pool spans roughly 2.4–3.2 GHz across 17+ providers. A game-server tick is single-threaded, so a slower core hosts fewer players and can wobble under load — and you may run more instances to hold tick rate. Gameye runs 5 GHz+ bare metal at every location, so per-core capacity is consistent.

Separate RAM meter

Edgegap adds a per-GB-hour RAM charge as its own line. Gameye's rate is per vCPU, all-in — no separate RAM meter to model or forecast.

DDoS & placement variance

Across 615 aggregated locations, DDoS protection and hardware quality vary by the underlying provider. Gameye uses curated premium locations with game-aware DDoS built into every one — consistent protection instead of a placement lottery.

Pricing lineEdgegapGameye
Compute~$0.069/vCPU-hr$0.07/vCPU-hr ($0.027 reserved)
RAMSeparate per-GB-hrIncluded
Egress / bandwidth~$0.10/GBIncluded — every provider & region
NetThree metered linesOne all-in rate

Rates, not a monthly total — your delta depends on traffic and how many instances variable hardware forces you to run. Model your own load profile in the Gameye vs Edgegap cost calculator, where Edgegap's per-GB egress is built in.


What does the migration path look like?

1
Keep your Docker image — point Gameye at it

You don't repackage anything. Edgegap and Gameye both run standard OCI/Docker images, so your existing server image is the artifact. Push it to a registry Gameye can pull from (Docker Hub or any OCI-compatible registry) and point Gameye at the image:tag. Gameye pulls it when starting sessions.

See the container guide in Gameye Docs →

2
Swap how the server learns its port

This is the one real code change. On Edgegap your server reads Arbitrium env vars to know where to listen and advertise:

  • ARBITRIUM_PORT_GAMEPORT_INTERNAL — port to bind
  • ARBITRIUM_PORT_GAMEPORT_EXTERNAL / ARBITRIUM_PUBLIC_IP — what clients connect to
  • ARBITRIUM_PORTS_MAPPING — the full mapping

On Gameye, pick one: bridge mode — bind a fixed port (e.g. 7777, declared with EXPOSE) and Gameye maps it to a host port returned in the session response, so your server reads no port env var at all; or read Gameye's injected port variable if you prefer dynamic. Either way, declare the port and protocol in your Gameye port config — the equivalent of Edgegap's 1:1 port mapping. Bridge mode is usually less code than the Arbitrium path.

See the port setup in the Dockerfile guide →

3
Drop the Arbitrium sidecar / SDK — if you used it

If you ran the Arbitrium Sidecar Agent (ASA), or pulled Edgegap's SDK or relay APIs into your build, remove them. Gameye orchestrates at the container level — there's no sidecar to run and no in-binary SDK to maintain or version. If your server only read environment variables (the common case), there's nothing to remove here at all.

4
Repoint your deploy call

Wherever your backend or matchmaker calls Edgegap's deploy API, swap it for a single POST to Gameye's Session API — IP and host port come back in the same response, no status polling:

Before (Edgegap)
// Create deployment → poll status → read ports mapping + public IP
POST /v1/deploy { app, version, ip_list } → poll → ports / public_ip
After (Gameye)
POST /session
{ "image": "your-image:tag", "region": "eu-west",
  "ports": [{ "type": "udp", "container": 7777 }], "env": {...} }
→ 200 OK: { "ip": "1.2.3.4", "ports": [{ "host": 27015 }] }

Match config you passed to Edgegap via env carries over to Gameye's env field. Your matchmaker itself — Unity Matchmaker, Nakama, Pragma, OpenMatch, or custom — doesn't change; only the allocation call does. See the Session API guide →

5
Parallel run by region — then shift traffic

Run Edgegap and Gameye in parallel. Route one region's traffic to Gameye, validate session start time, tick stability, and cost over a few days, then shift region by region. No hard cutover required — if anything is off, traffic rolls back without players noticing.

Because you're already container-native, most teams complete end-to-end validation in days. The actual traffic shift is a configuration change.

What doesn't change: Your authoritative server logic, networking model, client connection flow, player-facing behaviour, and any matchmaking rules. The migration scope is the infrastructure layer — not your game.


How do Edgegap and Gameye compare side by side?

Edgegap Gameye
Hardware / clock ~2.4–3.2 GHz, varies by provider 5 GHz+ bare metal, every location
Egress / bandwidth fees ~$0.10/GB None — every provider & region
RAM billing Separate per-GB-hr charge Included in vCPU rate
Compute pricing ~$0.069/vCPU-hr + RAM + egress $0.07/vCPU/hr flat ($0.027 reserved)
DDoS protection Varies by underlying provider Game-aware, every location
Locations 615+ aggregated, variable quality Curated premium metros
Provider failover Re-deploy on another node Automatic, multi-provider
In-container agent / SDK Arbitrium Sidecar / SDK (optional) None — standard port/health check
Container model Docker / OCI Docker / OCI — same image
Matchmaker Any (deploy API) Any HTTP matchmaker — Nakama, Pragma, FlexMatch STANDALONE, custom
Player data for placement Player IPs to deploy API (Server Score) Region targeting — no player IPs required
Trial access Self-serve Self-serve

Why do studios move from Edgegap to Gameye?

Consistent hardware

Gameye runs 5 GHz+ bare metal at every location. Edgegap's public pool spans roughly 2.4–3.2 GHz across 17+ providers, so the same session can land on a noticeably slower core depending on placement. Consistent clock means consistent tick rate and predictable players-per-core.

Bandwidth (and RAM) included

One all-in rate — $0.07/vCPU/hr ($0.027 reserved). No per-GB egress line that scales with players, no separate per-GB-hour RAM meter. Edgegap bills all three; Gameye bills one.

Game-aware DDoS everywhere

Every Gameye location ships with DDoS protection tuned for UDP game traffic. On Edgegap, protection and hardware quality vary by the underlying provider across 615 aggregated points-of-presence.

Same container, no sidecar

Your Docker image carries over unchanged. No Arbitrium Sidecar Agent to run, no SDK in your binary — Gameye orchestrates at the container level. The only code touch is how your server reads its port.

Keep your matchmaker

Gameye's Session API is a single HTTP POST. Whatever calls Edgegap's deploy API today — Nakama, Pragma, Unity Matchmaker, OpenMatch, or custom — repoints to Gameye. Your matchmaking logic doesn't change.

Gradual, low-risk migration

Parallel-run by region and validate Gameye on a slice of traffic before shifting the rest. No hard cutover. Because you're already container-native, most teams validate in days.


Frequently asked questions

Do I need to change my container to migrate from Edgegap to Gameye?

Barely. Both platforms run your dedicated server as a Docker image, so the image itself carries over. The one real change is how your server learns its port: on Edgegap it reads ARBITRIUM_PORT_GAMEPORT_INTERNAL and related env vars; on Gameye you either bind a fixed port (bridge mode) and let Gameye map it, or read Gameye's injected port variable. If you used the Arbitrium Sidecar Agent or SDK, remove it — Gameye needs no sidecar or SDK in the container.

Why do studios move from Edgegap to Gameye?

Hardware consistency and bandwidth cost. Edgegap's public pool spans roughly 2.4–3.2 GHz across 17+ providers, so a single-threaded tick can wobble depending on placement; Gameye runs 5 GHz+ bare metal at every location. Edgegap also bills per-GB egress (~$0.10/GB) on top of compute and a per-GB-hour RAM charge; Gameye includes both in $0.07/vCPU/hr. And game-aware DDoS is built into every Gameye location rather than varying by provider.

Do I keep my matchmaker when moving from Edgegap?

Yes. Gameye's Session API is a single HTTP POST and is matchmaker-agnostic. Whatever calls Edgegap's deploy API today — Unity Matchmaker, Nakama, Pragma Engine, OpenMatch, or a custom backend — repoints to Gameye's POST /session. Your matchmaking rules and player grouping are unchanged; you only swap the allocation call.

How does Edgegap pricing compare to Gameye?

Edgegap meters three lines: compute (~$0.069/vCPU-hr), a per-GB-hour RAM charge, and ~$0.10/GB egress — so bandwidth grows with player traffic. Gameye charges one published rate, $0.07/vCPU/hr on demand ($0.027 reserved), with bandwidth and RAM included and no separate egress line. For bandwidth-heavy multiplayer, the included-egress difference is usually the largest number.

Does Gameye offer regionless placement like Edgegap?

Gameye uses a curated set of premium locations rather than aggregating 615 commodity points-of-presence. You target a region and Gameye places the session on consistent bare metal there. Edgegap's regionless model optimizes for proximity across variable hardware (and its recommended placement strategy passes player IP addresses to the deploy API). Gameye optimizes for consistent, game-grade performance in the metros that actually carry your players. Full comparison →

How long does an Edgegap-to-Gameye migration take?

Because you're already container-native, most teams validate in days rather than weeks. Swap the port lookup, drop the Arbitrium sidecar if you used it, repoint the deploy call to Gameye's Session API, then parallel-run one region before shifting traffic. Your game binary, netcode, and matchmaking logic don't change.

Ready to move off Edgegap?

Start a Developer Trial, point Gameye at your existing image, and run your first session on 5 GHz bare metal — egress included from the first session. Because you're already container-native, validation is usually a matter of days.