Gameye vs. Edgegap: proven servers vs. a 615-location lottery

• Proven, not benchmarked: Edgegap leads with a 14M CCU figure from a synthetic test. Gameye's numbers are real games — 130M+ sessions and Chivalry 2's 250,000-player launch with zero downtime.
• You keep control: Gameye placement is one region parameter in your own matchmaker — auditable and reproducible. Edgegap's Server Score runs placement for you and hands back a city name, not the reasoning.
• Your players' data stays yours: Gameye receives a region name — no player IPs reach the platform. Edgegap's recommended strategy requires passing every player's public IP to its deployment API.
• Consistent hardware: Gameye runs 5GHz+ cores at every location. Edgegap's public pool varies 2.4–3.2 GHz across 17+ providers — enough to shift tick rate under load.

The real difference: control and proof, not location count

Edgegap's pitch is edge proximity, and for a globally scattered player base that latency advantage is real. But its model asks you to give up three things to get it. Gameye is built the other way around.

Proven in real launches, not a benchmark

Edgegap leads with a 14M CCU figure from a synthetic test — 40 deployments per second for 60 minutes in a controlled environment. Gameye's numbers come from real games: 130M+ sessions since 2017, and Chivalry 2's 250,000-player launch with zero downtime. When the question is "will this survive launch day," real players beat a lab.

Placement you control and can audit

Edgegap's Server Score runs placement for you — you supply the inputs and get a city name back, not the reasoning. Gameye placement is a single region parameter in your own matchmaker (location: "eu-west"): you decide it, you can reproduce it, and you can debug it. For a competitive title where you need to explain why a match landed where it did, that auditability is the difference between a fixable bug and a black box.

Your players' data stays yours

To get good placements, Edgegap's recommended strategy needs your matchmaker to collect every player's public IP and send it to its deployment API. Gameye receives a region name — no player IPs, no personal data ever reach the platform. For studios under GDPR or data-residency rules, that turns a compliance review into a non-issue.

When Edgegap is the better pick: if your players are thinly spread across many regions and shaving the last few milliseconds of proximity latency matters more than hardware consistency, auditable placement, or keeping player data in-house, Edgegap's edge network is a genuinely strong fit. For competitive and AAA titles, the trade usually runs the other way.

What is Edgegap?

Edgegap is a container orchestration platform focused on edge computing, offering 615+ locations across 17+ providers with a "regionless" deployment model. Edgegap's strengths are geographic distribution, self-serve onboarding with a free tier, and pay-per-use pricing — making it accessible for indie and mid-size studios.

Edgegap's public pool runs hardware ranging from 2.4 to 3.2 GHz across 17+ providers. DDoS protection varies by provider and location. Edgegap's recommended Server Score placement strategy requires passing player IP addresses to the deployment API.

What is Gameye?

Gameye is a managed orchestration platform built for the most demanding multiplayer games. It provides:

• Sub-second container scaling (0.5s average)
• Zero egress fees (included in pricing)
• 18 bare-metal providers, each qualifying to a hardware and protection baseline
• Game-grade DDoS protection built into every location
• Multi-provider redundancy with automatic failover
• Founded in 2017, 130M+ sessions orchestrated, 99.99% uptime
• Horizontal scaling across regions before cloud bursting

How does Gameye compare to Edgegap feature by feature?

Why aren't more locations always better?

Edgegap markets 615+ locations as a key differentiator. But more locations creates new problems:

"615 locations" is the size of the menu, not the size of the kitchen

The 615 figure is an aggregation of provider points-of-presence across 17+ underlying cloud and bare-metal specialists — not 615 data centres Edgegap runs. Stack the granular PoP-level locations from a handful of edge-cloud providers and the count climbs fast, but it measures addressable deployment targets, not standing concurrent capacity. It's the size of the menu, not the size of the kitchen.

That gap matters for game servers specifically. A game server is CPU-bound, needs high-clock dedicated cores, and runs for the full match — and edge nodes are, by design, a capacity-constrained tier. The established edge model is to serve what you can close to the player and overflow to cloud as load rises. A modest box in a tertiary PoP can hold a few containers, but the long tail of the 615 is thin in compute terms: the real work concentrates in a small number of well-stocked hubs, and the rest are placement options the orchestrator can reach for, not regions carrying meaningful capacity.

Nor is warm, pre-provisioned hardware standing by in all 615 at once — that volume of idle capacity would be prohibitively expensive. Deploying a container in seconds is a real strength of the cache-and-deploy model, but it is distinct from acquiring the underlying machine, which provisions in minutes to hours. Most of the tail stays cold and lights up just-in-time from a shared pool. "615 locations" and "615 locations with capacity ready right now" are not the same claim.

So the meaningful question was never 9 versus 615. It's how much real, well-peered capacity sits in the metros that actually carry your players — which is exactly what Gameye's qualified bare metal plus cloud burst is built around.

What's actually in the 615

Both Gameye and Edgegap work with third-party providers — that's how game server infrastructure works at scale. The difference is what those providers are and how the count is constructed.

Edgegap's 615 includes every AWS Region and Availability Zone — their own announcement of joining the AWS Partner Network describes deploying across "all AWS Regions and Availability Zones — on-demand and in one click." Standard hyperscaler regions (AWS, Google Cloud, Alibaba Cloud) count toward the headline number alongside commodity cloud (Vultr, DigitalOcean, OVHcloud) and colocation (Equinix). The "17+ providers" figure also bundles in SDK and technology partners — ProudNet, Red Hat, and others — who supply no compute at all.

When a session is ready, the Edgegap API returns the underlying host's raw public IP: an AWS IP, a Vultr IP, or an OVH IP depending on placement. The FQDN Edgegap provides is DNS pointing at a third-party server. That's not a criticism — it's how cloud orchestration works — but it does mean the 615 locations are a mix of standard cloud regions, commodity VMs, and colocation, not a purpose-built game server network.

The most revealing data point: when Edgegap deployed onto infrastructure genuinely close to the network edge — a September 2023 partnership with Colt Technology Services and City Infrastructure Network in London — they issued a press release calling it "the world's first game server running on true edge infrastructure." That statement only makes sense if everything else in their 615-location network is standard cloud and hosting. They said the quiet part loud.

Most edge infrastructure was built for video, not game servers

The majority of edge nodes on the internet exist to serve video. Video accounts for 38–54% of all downstream internet traffic (Sandvine, 2024), and that demand has driven the design of CDN infrastructure for 25 years. Google explicitly describes their Media CDN as "optimized for high-throughput egress workloads, such as streaming video." Akamai's entire network was built on media delivery. The edge computing industry, in other words, was architected around a fundamentally different problem than multiplayer gaming.

CDN edge nodes are stateless — they cache identical content and push it to users. They're storage-heavy, tolerant of 2–18 seconds of buffering latency, and tuned for TCP throughput. A game server is the opposite in every dimension: stateful, compute-bound, requiring sub-20ms round-trip time, and dependent on UDP or QUIC rather than TCP. The hardware profile is different too — CDN nodes are I/O-bound and need large disk caches; game servers need fast single-thread CPU clock speeds and high RAM per session.

This matters when evaluating a 615-location edge network. If a significant portion of that footprint is built on CDN-style infrastructure — optimised for video egress rather than real-time game server compute — then physical proximity to those nodes doesn't translate directly into better game server performance. A node close to your players that can't run a stateful authoritative server at low latency isn't an advantage. It's just a number on a marketing page.

Gameye's infrastructure is purpose-built for game server workloads: bare-metal nodes with 5GHz+ single-thread clock speeds, high RAM per vCPU, and network configurations built for UDP latency rather than TCP throughput. The location count is smaller because the qualification standard is built around what game servers actually need — not what CDN video delivery needs. Read more about edge node infrastructure →

Hardware Inconsistency — and Why It Shows Up in Your Code

Edgegap's public pool runs between 2.4 and 3.2 GHz across 17+ providers — a 25%+ variance in CPU throughput.

A game server binary that runs physics at 128Hz on a 3.2 GHz core will behave differently on a 2.4 GHz core under load. Tick rate drifts. Physics steps accumulate error. The bugs that result are nearly impossible to reproduce — they are tied to whichever node the session landed on, which neither the developer nor the player can predict or control.

Gameye requires 5 GHz+ cores and 4 GB RAM per vCPU at every location it deploys to. A binary that passes testing on one Gameye location behaves identically on every other. That consistency is a developer guarantee, not a marketing claim.

Network Peering Variability

Proximity is not latency. Each edge location has different peering arrangements with ISPs, and cost-optimised, blended transit is exactly what keeps a sprawling edge footprint affordable. A location physically close to a player can sit on cheap routes and lose to a well-peered, IXP-adjacent hub further away — and average ping hides the jitter and route instability players actually feel under load. Across 615 PoPs spanning 17+ providers, peering quality is heterogeneous by construction; more locations amplifies that inconsistency rather than resolving it.

DDoS Protection Patchwork

With 17+ providers, DDoS mitigation quality varies by location and contract. During an attack, your weakest link determines your resilience.

Game-aware DDoS protection is an entry requirement for every Gameye provider. No provider is added to the Gameye network without it. Every location a session can land on has active DDoS mitigation, not just the locations on high-profile providers.

The "Regionless" Tradeoff

Edgegap markets regionless deployment as simpler. The reality depends on what you are building.

Gameye's regional integration is a single string parameter in your session start call. For a game with a concentrated player base, you pass location: "eu-west" and you are done. No player data collection, no measurement infrastructure, no ongoing beacon caching. Edgegap's Server Score strategy requires collecting every player's public IP and passing it to the deployment API.

For global games that need dynamic placement, both approaches require client-side latency measurement. With Gameye, placement logic lives in your matchmaker — you own it, you can log it, and you can reproduce every placement decision exactly. Gameye placement decisions are fully auditable. With Edgegap's regionless model, the platform's algorithm makes the final call, and the reasoning is not exposed for inspection.

Player Data Leaves Your Infrastructure

Edgegap's Server Score strategy requires passing every player's public IP address to the deployment API at session start. For studios operating under GDPR or data residency requirements, this raises questions about what player network data is transmitted to a third-party platform.

Gameye receives a region name only. No player IP addresses or personal data pass to the Gameye platform.

Consistent Hardware Requires a Sales Conversation

Edgegap's public pool runs hardware ranging from 2.4 to 3.2 GHz across 17+ providers — a meaningful range for tick-rate-sensitive games. Edgegap offers private bare metal pools with consistent 3.7-5.1 GHz hardware, but this tier has no public pricing. Edgegap's own documentation describes hybrid orchestration as "available only via client request due to required information necessary to propose a final pricing."

A studio that needs hardware consistency for competitive multiplayer cannot evaluate Edgegap on the same terms as their standard offering. Edgegap's private bare metal pools are pre-provisioned at specific locations — making the model regional in all but name. The global placement optimisation that defines regionless applies only to the variable-hardware public pool.

Gameye provides 5 GHz+ cores and 4 GB RAM per vCPU at every location, at standard pricing, from day one. No enterprise qualification is required for hardware consistency.

How do regions work for large-scale games?

Edgegap frames regional architecture as outdated. But there's a reason AAA studios use it:

1. Baseline capacity on premium bare metal — Run your steady-state traffic on high-performance, consistent hardware in major population centers.
2. Horizontal scaling within regions — When traffic spikes, scale across proven infrastructure in that region first.
3. Cloud bursting for peaks — Only burst to cloud capacity for extreme spikes (launches, free weekends).

This model optimises for performance consistency, not location count. Players in Frankfurt get the same hardware quality as players in Dallas. Tick rates stay stable. Gameplay feels fair.

Gameye has orchestrated 130M+ sessions using this model, including Chivalry 2's 250,000-player launch spike with zero downtime.

How accurate is Edgegap's comparison page?

Edgegap publishes a comparison page about Gameye and updates it periodically. Where it's inaccurate, here's the correction:

Why choose Gameye as an alternative to Edgegap?

What do studios say about Gameye?

Key terms

Frequently asked questions: Gameye vs Edgegap

Switching from Edgegap as an Unreal Engine studio?

Edgegap's hardware consistency issue matters more for UE titles than most engines — Unreal Engine's physics and networking ticks are sensitive to CPU throughput. The 25%+ clock speed variance across Edgegap's public pool means different tick behavior on different nodes, producing bugs nearly impossible to reproduce.

Gameye qualifies every location at 5GHz+ cores. A UE5 server that passes testing behaves identically in production regardless of which datacenter handles the session. Chivalry 2 (Unreal Engine 4, Torn Banner Studios) ran its 250,000-player launch on Gameye with zero downtime.

Container-based, no UE plugin required. Your Linux dedicated server build runs as-is. See how Unreal Engine dedicated server hosting works on Gameye →

Related comparisons