Global Edge Cloud locations
Distinct deployment targets where a game server container can be scheduled on demand.

迁移
/
Hathora
Hathora 于 2026 年 5 月关闭了其游戏托管服务。
您的容器无需进行任何更改:保留您已交付的镜像,重新指定一个分配调用,并部署到自动化的私有舰队(Private Fleets)以实现高性价比的托管。当需求超出您的舰队承载能力时,混合编排将弹性分流至我们遍布全球 615+ 个地点的边缘云网络,从而让玩家获得无需提前购买即可享有的覆盖范围。
保持不变的是什么
您的网络代码和传输层
Edgegap 绝不干涉您的传输、序列化或 Tick 循环。容器运行的正是您今天构建的同一服务器二进制文件。
容器化
您已经将容器寄送至 Hathora,因此该制品保持不变。请将相同的镜像推送到我们的注册表,或者保留您目前使用的镜像。
您的客户端连接流程
您的客户端仍然会接收到一个地址和端口并进行连接。唯一改变的是该地址的来源。
引擎、版本与持续集成
相同的引擎、相同的版本、相同的构建流水线。除了推送镜像之外,您的 CI 不需要任何新步骤。
有哪些变化
CLI 将不复存在
这里没有需要剥离的服务器 SDK,因为 Hathora 从不要求,Edgegap 也同样不需要。需要移除的是托管 CLI 及其相关的上传步骤:现在您只需通过控制面板或 API 将镜像推送到镜像仓库并创建版本即可。
一次部署调用即可替换该房间
在您以前的后端调用 CreateRoom 然后请求该房间连接信息的地方,现在您只需向部署端点发送一次 POST 请求,即可获取 FQDN 和端口。房间变为了部署,进程变为了部署状态和 Webhook。
区域不再是购买决策的限制因素
您不再需要逐个区域购买容量。每次部署都会在请求时放置在 615+ 个边缘云位置中最佳的位置。
预留容量成为一种选择
Hathora 过去按运行的服务器数量向您收费,且不提供任何底层支持。Private Fleets 为您的稳定负载增加了免出站流量费的专用硬件,并随着您的流量曲线变化调整大小,超出部分则全部部署在 Edge Cloud 上。
预期时间表
步骤 1
将房间创建和连接信息调用替换为单个部署请求。无需更改游戏服务器代码。
~2 小时
步骤 2
您的服务器已经作为容器在 Hathora 上运行,因此这一步只是进行检查,而不是实际的工作。
已完成
步骤 3
Edgegap 的镜像仓库可免费使用,或者您也可以继续使用 ECR、DockerHub、GitLab 等。
~30 分钟
步骤 4
只需一个 HTTP 请求即可代替房间创建和连接信息。
约1天
第 5 步
在全球边缘云(Edge Cloud)上进行部署,还可选择通过专属机群(Private Fleets)免流量费托管来进一步降低成本。
即时部署
详细迁移步骤
请务必参考我们的“从 Hathora 迁移”文档,以获取该过程的最新更新。
在开始之前,我们希望:您目前正在使用或最近使用过 Hathora,并且您有一个可以正常运行的游戏服务器容器。
Edgegap 不需要集成 SDK,Hathora 也是如此,因此您的游戏服务器不需要进行任何修改。工作完全在您的后端。只要后端创建了房间并请求该房间的连接信息,现在它就会向 Edgegap 发起一个部署请求,并在响应中接收地址和端口。部署状态和 Webhooks 替代了您以前轮询的进程生命周期,而您的客户端将像今天一样继续连接到地址和端口。
您的游戏服务器已经作为容器运行,因此这一步是检查而不是重建。确认镜像在本地构建并启动,然后将其推送到 Edgegap 的免费注册表,或者保留 ECR、DockerHub、GitLab 或任何其他兼容 OCI 的注册表。如果您想从头开始重建,适用于 Unity、Unreal Engine 和 Godot 的快速启动工具在开发项目上仅需 5 到 20 分钟。
Hathora - 功能 | Edgegap - 功能 |
|---|---|
身份验证 | 可选:添加细粒度的访问控制: |
托管 CLI | |
创建构建 | 试试我们的快速入门工具 - Unity / Unreal Engine。 |
Hathora 大厅 |
|
舰队 | |
主动缓存 (专业版, 企业版) - 3 秒部署 | 活动缓存 (按需付费) - 0.5 秒部署 |
Ping 服务 (区域) | Ping 信标 (在特定引擎的 SDK 中自动执行) |
遥测 (分析) |
Edgegap 还提供了一个类似于 Hathora 的舰队和 Elastic Metal 的可选功能:裸金属上的持久服务器私有舰队,具有免流出托管功能,并且在需求超出舰队容量时自动溢流到边缘云(Edge Cloud)。
定价
了解 Edgegap 的编排方案与您之前向 Hathora 支付的费用相比,是如何实现高性价比的。
Hathora | Edgegap |
|---|---|
计费。按地区、基于车队的计费意味着闲置容量也需要收费。 | 在边缘云(Edge Cloud)上不计费,其中零活动部署的费用为 $0,并且在私有车队(Private Fleets)上每月调整至合适规模。 |
Hathora | Edgegap |
|---|---|
IPv4 地址作为额外项计费。 | 包含 IPv4,全球统一价格,按需付费,价格为每 vCPU 每分钟 $0.00115,可从 0.25 vCPU 起分拆计算。 |
Hathora | Edgegap |
|---|---|
在 14 个地区中按地区选择并支付容量,其中 5 个地区位于美国。 | 私有车队(Private Fleets)作为您的基线,在请求时可突发扩展至最佳可用位置的边缘云(Edge Cloud)。 |
(Hathora 数据源自我们于 2026 年 3 月发布的对比与迁移指南。)
完整对比请见此处:“Edgegap vs Hathora”。

客户
共有 15 个从其他平台迁移到 Edgegap 的工作室案例研究可供参考。

迁移现场运维多人游戏到Edgegap以解决DevOps工作负载
发现为什么#1 VR提取射手游戏是由Edgegap的游戏服务器托管和 orchestration提供支持的。
Case Study

能够即时扩展并改善最终用户体验的持久服务器
了解《岛屿》如何通过Edgegap的全球持续服务器部署提升玩家体验。
Case Study

借助 Edgegap 的游戏服务器编排,几天内迁移了一款轻松治愈的 MMO
Qloud Games 如何在不到 24 小时内将 Loftia 的游戏服务器托管迁移到 Edgegap,并成功举办了一场拥有数千名同时在线玩家的完美封闭测试
Case Study

大规模VR战争:Triangle Factory在Edgegap上发布Forefront 1.0
Triangle Factory 如何将其雄心勃勃的 VR 射击游戏迁移到 Edgegap,并充满信心发布了完整的 1.0 版本。
Case Study

从点对点到公平对决:《Bloody Bastards》启用专属服务器
了解 Tibith Ltd 如何将拥有 4000 万次下载的热门手游《Bloody Bastards》从 P2P 迁移至 Edgegap 的专用服务器和匹配系统,从而确保每场比赛都由服务器端进行权威判定。
Case Study

Noodlecake 如何实现多玩家游戏并让人忘却服务器的存在
Noodlecake 如何将 《Super Flappy Golf》 迁移至 Edgegap 的自动编排系统,并重新专注于游戏开发。
Case Study

竞争激烈的VR游戏需要与之匹配的基础设施:Breachers 迁移至 Edgegap
了解 Triangle Factory 如何将其竞争激烈的 5v5 VR 射击游戏引入专为该类型游戏所需精度而构建的基础设施。
Case Study

使用 Edgegap 的 Fleet 实现完全自动化的服务器管理流程
了解蓝鸭工作室如何使用Edgegap的Fleets API来协调其足球游戏的服务器。
Case Study

Edgegap 上的 1047 Games:平稳的迁移与发布
了解 1047 Games 如何将《Splitgate: Arena Reloaded》迁移到 Edgegap,并在其编排服务上发布 Empulse,同时在整个过程中保持托管服务的稳定可靠。
Case Study

从自制编排到一夜之间达到五万名玩家
Slipstream Games 如何将服务器成本降低 50%,将其延迟从 200-250 毫秒减少到 100-110 毫秒,并在 CrazyGames 上发布,24 小时内达到了 50,000 名玩家。
Case Study

从车队到按需:为一款独立滑板车游戏提供专用服务器
iScoot 如何从基于整批服务器的托管迁移到按需、基于实例的编排,从而将专用服务器缩小到原来的 1/10,并构建出适合独立游戏的成本模型。
Case Study

按需、按预算:Triangle Factory 将 Hyper Dash 引入 Edgegap
一款免费 VR 射击游戏如何利用随玩家规模缩放的按需基础设施,保持快速运行、全球覆盖和高成本效益。
Case Study
了解 Edgegap 自动化游戏服务器编排如何带来无缝的多人游戏体验。
研究方法
每个指标都说明了测量的内容、时间窗口以及排除的内容。基准测试结果的日期可追溯到产生这些结果的测试,并且不会重述为当前数据。
Where servers can run, and how many we have run.
Distinct deployment targets where a game server container can be scheduled on demand.
Locations where a studio can reserve dedicated bare-metal or VM hosts for its exclusive use.
Total game server deployments orchestrated since February 2019, including deployments that failed to start, the same basis our competitors use.
How fast our orchestration delivers a server, and what it sustains under test.
From cold start: provisioned from scratch, not allocated onto an already-running server. Measured to container ready, before the game engine starts.
Started deployments per second, averaged over a continuous 60-minute benchmark. Available to each game from confirmed studios with live traffic.
Concurrent sessions reached on real game server containers, at 100 players per server.
What we commit to contractually for our orchestration, and what the monitors record.
Committed under our SLA. Trailing 90-day measured uptime: 99.999%.
Cloud and bare-metal providers under contract and carrying production traffic. Failover is automatic.
Live component status is published at status.edgegap.com.
One entry per metric: what is measured, how, and over what window.
A location is a distinct deployment target: one datacenter site at one of our infrastructure providers, in which a game server container can be scheduled on demand. Sites are counted once each regardless of how many providers operate in the same metro, and count only while accepting deployments.
Back to the metric ↑The subset of the 615+ where a studio can reserve dedicated bare-metal or VM hosts for its exclusive use rather than deploying into shared on-demand capacity. Published live on the Fleet Manager page. This is also the number that carries the included-egress allowance.
Back to the metric ↑Counted as total deployment records since February 2019, including deployments that failed to start, the same basis our competitors use.
Back to the metric ↑From cold start: provisioned from scratch, not allocated onto an already-running server. Measured to container ready, before the game engine starts.
Back to the metric ↑The orchestrator started real game server containers continuously for 60 minutes, averaging 40 started deployments per second over the full hour, counted at deployment start rather than at ready state. Measured across 550+ locations and 17 providers in November 2023. The benchmark ran for a single game. Capacity is allocated per game, so every game on the platform can scale to this level independently and at the same time.
Back to the metric ↑In November 2023, the platform sustained 40 game server deployments per second for 60 minutes across 550+ locations and 17 providers, reaching 14 million concurrent sessions at 100 players per server. Game servers were real containers; player clients were simulated. The benchmark ran for a single game. Capacity is allocated per game, so every game on the platform can scale to this level independently and at the same time.
Back to the metric ↑Availability is committed at 99.99% under our SLA and measured continuously against five independently monitored components: Container Registry, Dashboard, Public API, Public Documentation and Website. Trailing 90-day measured uptime: 99.999%. The live figure is published on status.edgegap.com.
Back to the metric ↑Distinct suppliers under contract and carrying production traffic, counted at corporate-entity level. Failover across providers is automatic; it is the premise of the multi-cloud architecture.
Back to the metric ↑What gets reviewed, on what cadence, and what carries its own date.
Platform figures on this page are reviewed and refreshed quarterly. Metrics drawn from live sources (availability and game server deployments) carry their own as-of dates and are updated as measured. Benchmark results are dated to the test that produced them and are not restated as current figures.
Edgegap 是托管和编排方面的专家。我们的平台专为帮助您加速开发流程而构建,让您可以专注于自己擅长的事情——开发。
不,但您的具体情况决定了第一步。如果您的游戏仍在某处运行,那么迁移就是本页面所述的普通迁移:您的容器本身已经是一个容器,工作仅限于重新指向一个分配调用。如果您的服务器已经关闭,那么路径是一样的,只是顺序相反:先在 Edgegap 上部署镜像,然后重新指向后端。无论哪种方式,您都不需要重写任何关于构建或网络代码的内容,就能让玩家重新在线。
因为向您提供的过渡方案仍然属于迁移,且这两种路径所需的工程成本不同。为 Hathora 客户发布的过渡路径要求您将服务器 SDK 集成到游戏服务器中,以进行生命周期信号传递(就绪、分配和关闭),并且如果您的后端需要按需请求服务器(如 CreateRoom API 那样),则需要单独订购其分配服务。而 Hathora 之前并不要求在您的游戏服务器中安装服务器 SDK。我们也是如此:您的容器保持原样,您的后端只需进行一次部署调用。请将此与已公布的价格以及自助服务访问权限一起进行权衡。
这比我们发布的任何其他迁移方案都要简单,我们宁愿如实相告,也不愿凭空捏造工作量。Hathora 本身就是基于容器的,因此您推送的制品就是您已经构建好的制品。改变的只是词汇表和一次调用:房间(rooms)变成了部署(deployments),进程(processes)变成了部署状态和 Webhook,而 CLI 则被控制台(Dashboard)或 API 取代。您的引擎、网络代码和客户端连接流程都保持原样,无需任何改动。
老实说,没有一个可以直接替代的方案:Lobbies 捆绑了三项功能,而 Edgegap 将它们分离开来。对于 DevOps 和测试,Deployment Status API 会告知您部署的运行状况。对于后端自动化,Deployment Webhook 会向您推送这些事件。对于面向玩家的部分,Server Browser 处理搜索和浏览,并配合 Group Up 进行玩家匹配或使用 Reserve Seat 预留位置。大多数团队最终会使用这三项功能中的两项。
专用舰队(Private Fleets),它们比字面意思更贴合您的需求:运行在专用硬件上的持久性服务器,具有更低的流出流量成本,并在流量超出舰队承载能力时提供云端溢流支持。两者的区别在于您需要维护什么。其扩缩容是自动化的,无需您针对每个区域进行精细调整,并且您可以根据每月的流量曲线变化来调整合适的内容,而不是在旺季到来前就做出盲目的资源承诺。在对比任何方案时,都值得注意这一点:预先启动的服务器缓冲区是您在游戏会话之间需要运行并付费的容量。而在 Edge Cloud 上,无需预留任何缓冲区。
是的。Hathora 支持的每个后端在这里都受到支持:Epic Online Services、PlayFab、Unity Gaming Services、Nakama by Heroic Labs、Pragma(请参阅我们的联合案例研究)、Beamable 以及自定义后端。Edgegap 还与 BrainCloud、LootLocker、Invokation Games、XSOLLA 和 Network Next 等进行了集成。如果您最担心的是后端部分,那么这通常是移动起来工作量最小的部分。