Emplacements mondiaux de l'Edge Cloud
Cibles de déploiement distinctes où un conteneur de serveur de jeu peut être planifié à la demande.

Migration
/
Hathora
Hathora a fermé son service d'hébergement de jeux en mai 2026.
Votre conteneur n'a pas à changer : conservez l'image que vous fournissez déjà, redirigez un appel d'allocation et déployez vers des Private Fleets automatisées pour un hébergement économique. Lorsque la demande dépasse la capacité de votre flotte, l'orchestration hybride bascule vers notre réseau Edge Cloud de plus de 615 emplacements dans le monde, offrant ainsi aux joueurs une couverture que vous n'avez jamais eu à acheter à l'avance.
Ce qui change (et ce qui ne change pas)
Une migration Hathora est un changement d'hébergement, pas une réécriture. Voici ce à quoi vous devez vous attendre pour votre migration.
Une analyse détaillée, fonctionnalité par fonctionnalité, est présentée à l'étape Étape 3 : Identifier et remplacer les fonctionnalités ci-dessous.
Ce qui reste inchangé
Votre netcode et transport
Edgegap ne touche jamais à votre transport, à votre sérialisation ou à votre boucle de tick. Le conteneur exécute le même binaire de serveur que celui que vous compilez aujourd'hui.
Conteneuriser
Vous envoyez déjà un conteneur à Hathora, l'artefact reste donc inchangé. Poussez la même image vers notre registre, ou conservez celle que vous utilisez aujourd'hui.
Votre flux de connexion client
Votre client reçoit toujours une adresse et un port et s'y connecte. Seule la provenance de cette adresse change.
Moteur, versions et CI
Même moteur, même version, même pipeline de build. Rien dans votre CI ne nécessite d'étape supplémentaire au-delà du push de l'image.
Qu'est-ce qui change
L'interface en ligne de commande disparaît
Il n'y a pas de SDK serveur à retirer, car Hathora n'en a jamais requis, et Edgegap non plus. Ce qui disparaît, c'est l'interface en ligne de commande (CLI) d'hébergement et l'étape de téléversement associée : vous poussez une image vers un registre et créez une version, depuis le tableau de bord ou l'API.
Un seul appel de déploiement remplace la salle
Là où votre backend appelait CreateRoom puis demandait les informations de connexion de cette salle, vous effectuez désormais un seul POST vers le point de terminaison de déploiement et recevez en retour un FQDN et un port. Les salles deviennent des déploiements, et les processus deviennent des statuts de déploiement et des webhooks.
Le choix des régions n'est plus un facteur de décision d'achat
Vous n'avez plus besoin d'acheter de la capacité région par région. Chaque déploiement est placé au meilleur des plus de 615 emplacements au moment de la requête pour Edge Cloud.
La capacité réservée devient une option
Hathora vous facturait par serveur actif sans rien proposer d'autre. Private Fleets ajoute du matériel dédié sans frais de sortie pour votre charge régulière, redimensionné au rythme de votre courbe de trafic, tout le reste étant déployé sur Edge Cloud.
Calendrier prévu
Étape 1
Remplacez les appels de création de salon et d'informations de connexion par une seule requête de déploiement. Aucune modification du code du serveur de jeu.
~2 heures
Étape 2
Votre serveur fonctionne déjà en tant que conteneur sur Hathora, cette étape est donc une vérification plutôt qu'un travail supplémentaire.
Déjà fait
Étape 3
Le registre d'Edgegap est disponible gratuitement, ou conservez ECR, DockerHub, GitLab, etc.
~30 min.
Étape 4
Une seule requête HTTP remplace la création de la salle et les informations de connexion.
environ 1 jour
Étape 5
Déployez à l'échelle mondiale sur Edge Cloud, et réduisez éventuellement encore plus vos coûts grâce à un hébergement sans frais d'egress sur Private Fleets.
Déploiement instantané
Étapes de migration détaillées
Assurez-vous de consulter notre documentation Migrer depuis Hathora pour obtenir les dernières mises à jour concernant ce processus.
Avant de commencer, nous supposons que : vous utilisez actuellement, ou avez récemment utilisé, Hathora, et vous disposez d'un conteneur de serveur de jeu fonctionnel.
Edgegap ne requiert pas de SDK pour l'intégration, et Hathora non plus, donc rien ne provient de votre serveur de jeu. Le travail se fait dans votre backend. Partout où il créait une salle puis demandait les informations de connexion de cette salle, il fait maintenant une seule demande de déploiement à Edgegap et reçoit l'adresse et le port dans la réponse. Le statut de déploiement et les webhooks remplacent le cycle de vie du processus que vous interrogiez, et votre client continue de se connecter à une adresse et à un port exactement comme il le fait aujourd'hui.
Votre serveur de jeu fonctionne déjà sous forme de conteneur, cette étape est donc une vérification plutôt qu'une reconstruction. Confirmez que l'image se crée et démarre localement, puis poussez-la vers le registre gratuit d'Edgegap, ou conservez ECR, DockerHub, GitLab ou tout autre registre compatible OCI. Si vous souhaitez reconstruire à partir de zéro, les outils de démarrage rapide pour Unity, Unreal Engine et Godot prennent de 5 à 20 minutes sur un projet de développement.
Hathora - Fonctionnalité | Edgegap - Fonctionnalité |
|---|---|
Authentification | Facultativement, ajoutez des contrôles d'accès précis : |
CLI d'hébergement | Aucune CLI requise ! Utilisez notre Tableau de bord ou automatisez les builds avec l'API. |
Créer un Build | Essayez nos outils de démarrage rapide - Unity / Unreal Engine. |
Lobbies Hathora |
Se regrouper pour le Matchmaking ou Réserver une place dans le navigateur de serveurs. |
Flotte | Private Fleets avec Persistance et Débordement vers le cloud. Possibilité de l'ajouter plus tard, ou par défaut sur le cloud Match-Bound. |
Mise en cache anticipée (Pro, Enterprise) - Déploiements en 3 secondes | Mise en cache active (Paiement à l'utilisation) - Déploiements en 0,5 seconde |
Service de Ping (Régions) | Balises de Ping (automatisées dans les SDK spécifiques aux moteurs) |
Télémétrie (Analyses) |
Edgegap propose également une fonctionnalité optionnelle similaire aux flottes de Hathora et au service Elastic Metal : des Private Fleets de serveurs persistants sur bare metal, avec un hébergement sans frais de transfert de données sortantes (egress) et un débordement automatique vers Edge Cloud lorsque la demande dépasse la capacité de la flotte.
Prix
Découvrez comment l'orchestration d'Edgegap est plus rentable par rapport à ce que vous payiez chez Hathora.
Hathora | Edgegap |
|---|---|
Facturé. La facturation par région et par flotte signifiait que la capacité inactive était facturée. | Non facturé sur Edge Cloud, où zéro déploiement actif coûte 0 $, et ajusté mensuellement sur les Private Fleets. |
Hathora | Edgegap |
|---|---|
Adresses IPv4 facturées en supplément. | IPv4 incluse, prix unique mondial, paiement à l'utilisation à 0,00115 $ par vCPU et par minute, fractionnable à partir de 0,25 vCPU. |
Hathora | Edgegap |
|---|---|
Capacité choisie et payée par région à travers 14 régions, dont 5 aux États-Unis. | Private Fleets pour votre base de référence, avec débordement (bursting) sur Edge Cloud à l'emplacement le plus approprié disponible au moment de la demande. |
(Chiffres de Hathora publiés dans notre guide de comparaison et de migration, mars 2026.)
Comparaison complète disponible ici : "Edgegap vs Hathora".

Clients
15 études de cas sont disponibles auprès de studios qui ont migré vers Edgegap depuis une autre plateforme.

Migration d'un jeu LiveOps pour solutioner la charge de travail DevOps
Découvrez pourquoi le tireur d'extraction VR n°1 est alimenté par l'hébergement et l'orchestration de serveurs de jeu d'Edgegap.
Case Study

Serveurs persistants qui "scale" & améliorent l'expérience des joeurs
Découvrez comment The Isle a amélioré l'expérience de ses joueurs grâce aux déploiements mondiaux de serveurs persistants d'Edgegap.
Case Study

Un MMO cosy migré en quelques jours grâce à l’orchestration d’Edgegap
Comment Qloud Games a migré l’hébergement des serveurs de jeu de Loftia chez Edgegap en moins de 24 heures et a lancé une bêta avec des milliers de joueurs.
Case Study

Guerre VR à grande échelle : Triangle Factory lance Forefront 1.0 sur Edgegap
Comment Triangle Factory a migré son jeu de tir en VR le plus ambitieux vers Edgegap et a lancé sa version 1.0 complète en toute confiance.
Case Study

Du Peer-to-Peer aux combats équitables : Bloody Bastards sur serveurs dédiés
Comment Tibith Ltd a migré Bloody Bastards, un succès mobile, du peer-to-peer vers les serveurs dédiés et le matchmaking d'Edgegap, garantissant que chaque match soit géré côté serveur.
Case Study

Comment Noodlecake propose le mode multijoueur tout en oubliant l'existence des serveurs
Comment Noodlecake a migré Super Flappy Golf vers l'orchestration automatisée d'Edgegap et s'est recentré sur le développement du jeu.
Case Study

Breachers migre vers Edgegap
Comment Triangle Factory a adapté son jeu de tir VR compétitif en 5v5 à une infrastructure conçue pour la précision qu'exige ce genre.
Case Study

Comment Blue Duck utilise les Fleets d'Edgegap pour l'orchestration de son MMO
Découvrez comment Blue Duck Studios utilise l'API Fleets d'Edgegap pour orchestrer les serveurs de son jeu de football.
Case Study

1047 Games sur Edgegap : une migration et un lancement fluides
Comment 1047 Games a migré Splitgate: Arena Reloaded vers Edgegap et a lancé Empulse sur son orchestration, avec un hébergement resté fiable tout au long.
Case Study

De l'orchestration homebrew à 50 000 joueurs du jour au lendemain
Comment Slipstream Games a réduit ses coûts de serveur de 50%, a diminué son ping de 200-250 ms à 100-110 ms et a lancé sur CrazyGames atteignant 50 000 joueurs en 24 heures.
Case Study

De la flotte à la demande : des serveurs dédiés pour un jeu de scooters
Comment iScoot est passé à une orchestration à la demande basée sur des instances, aboutissant à des serveurs dédiés 10 fois plus petits en terme de modèle de coûts
Case Study

Triangle Factory migre Hyper Dash chez Edgegap
Comment un jeu de tir en VR gratuit reste rapide, mondial et rentable grâce à une infrastructure à la demande qui s'adapte à ses joueurs.
Case Study
Découvrez l’impact de l’orchestration automatisée des serveurs de jeu d’Edgegap pour une expérience multijoueur impeccable.
Méthodologie
Chaque métrique indique ce qui est mesuré, sur quelle période et ce qui est exclu. Les résultats de référence sont datés du test qui les a produits et ne sont pas reformulés en tant que chiffres actuels.
Où les serveurs peuvent fonctionner et combien nous en avons exploités.
Cibles de déploiement distinctes où un conteneur de serveur de jeu peut être planifié à la demande.
Emplacements où un studio peut réserver des hôtes dédiés (bare-metal ou VM) pour son usage exclusif.
Nombre total de déploiements de serveurs de jeu orchestrés depuis février 2019, y compris les déploiements qui n'ont pas réussi à démarrer, selon la même méthode de calcul que nos concurrents.
La rapidité avec laquelle notre orchestration déploie un serveur, et ce qu'elle soutient en condition de test.
Démarrage à froid : provisionné à partir de zéro, et non alloué sur un serveur déjà en cours d'exécution. Mesuré jusqu'à ce que le conteneur soit prêt, avant le lancement du moteur de jeu.
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.
Ce à quoi nous nous engageons contractuellement pour notre orchestration, et ce que les moniteurs enregistrent.
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.
L'état des composants en direct est publié sur status.edgegap.com.
One entry per metric: what is measured, how, and over what window.
Un emplacement correspond à une cible de déploiement distincte : un site de centre de données chez l'un de nos fournisseurs d'infrastructure, dans lequel un conteneur de serveur de jeu peut être planifié à la demande. Les sites ne sont comptabilisés qu'une seule fois, quel que soit le nombre de fournisseurs présents dans la même zone métropolitaine, et uniquement lorsqu'ils acceptent des déploiements.
Back to the metric ↑Le sous-ensemble des 615+ où un studio peut réserver des hôtes physiques (bare-metal) ou des machines virtuelles dédiés pour son usage exclusif, plutôt que de déployer sur une capacité partagée à la demande. Publié en direct sur la page Fleet Manager. Ce nombre correspond également à celui qui comprend le volume de transfert sortant inclus.
Back to the metric ↑Comptabilisé comme le nombre total de déploiements enregistrés depuis février 2019, y compris les déploiements qui n'ont pas pu démarrer, selon la même méthode que celle utilisée par nos concurrents.
Back to the metric ↑Démarrage à froid : provisionné à partir de zéro, et non alloué sur un serveur déjà en cours d'exécution. Mesuré jusqu'à ce que le conteneur soit prêt, avant le lancement du moteur de jeu.
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 est l'expert de l'hébergement et de l'orchestration. Notre plateforme est conçue sur mesure pour vous aider à accélérer votre processus de développement, ce qui vous permet de vous concentrer sur ce dans quoi vous excellez : le développement.
Non, mais votre situation détermine la première étape. Si votre jeu est toujours en cours d'exécution quelque part, la migration est celle, ordinaire, décrite sur cette page : votre conteneur est déjà un conteneur, et le travail consiste simplement à rediriger un appel d'allocation. Si vos serveurs sont déjà hors ligne, le chemin est le même mais dans l'ordre inverse : déployez d'abord l'image sur Edgegap, puis redirigez le backend. Dans les deux cas, rien dans votre build ou votre code réseau n'a besoin d'être réécrit pour remettre les joueurs en ligne.
Parce qu'une transition qui vous est proposée reste une migration, et que les deux options représentent des volumes de travail technique différents. La méthode de transition publiée pour les clients d'Hathora vous demande d'intégrer un SDK serveur dans votre serveur de jeu pour la signalisation du cycle de vie (ready, allocate, shutdown), et de commander son service d'allocation séparément si votre backend demande des serveurs à la demande, comme le faisait l'API CreateRoom. Hathora ne demandait aucun SDK serveur dans votre serveur de jeu. Nous non plus : votre conteneur reste tel quel, et votre backend effectue un seul appel de déploiement. Comparez cela aux tarifs publiés et à l'accès en libre-service.
Moins que sur toute autre migration que nous publions, et nous préférons le dire plutôt que d'inventer du travail. Hathora était basé sur des conteneurs, donc l'artefact que vous poussez est l'artefact que vous construisez déjà. Ce qui change, c'est le vocabulaire et un seul appel : les salons deviennent des déploiements, les processus deviennent des statuts de déploiement et des webhooks, et l'interface en ligne de commande (CLI) est remplacée par le Tableau de bord ou l'API. Votre moteur, votre code réseau et votre flux de connexion client restent inchangés.
Pour être tout à fait honnête, il n'y a pas de solution de remplacement unique : Lobbies regroupait trois fonctionnalités qu'Edgegap sépare désormais. Pour le DevOps et les tests, l'API de statut de déploiement (Deployment Status API) vous indique ce qu'un déploiement est en train de faire. Pour l'automatisation du backend, le webhook de déploiement (Deployment Webhook) vous transmet directement ces événements. Pour la partie visible par les joueurs, Server Browser gère la recherche et la navigation, tandis que Group Up s'occupe du matchmaking et Reserve Seat de la réservation de places. La plupart des équipes finissent par utiliser deux de ces trois outils.
Private Fleets, et elles sont plus proches qu'on ne le pense : des serveurs persistants sur du matériel dédié, avec des frais de sortie réduits, et un débordement vers le cloud lorsque le trafic dépasse la capacité de la flotte. La différence réside dans ce que vous entretenez. La mise à l'échelle est automatisée plutôt qu'une configuration par région à ajuster, et vous redimensionnez mensuellement en fonction de l'évolution de votre courbe de trafic au lieu de vous engager avant une saison. Point important à vérifier pour chaque option comparée : un tampon de serveurs pré-démarrés est une capacité que vous exploitez et payez entre les sessions. Sur Edge Cloud, il n'y a pas de tampon à dimensionner.
Oui. Tous les backends pris en charge par Hathora le sont également ici : Epic Online Services, PlayFab, Unity Gaming Services, Nakama par Heroic Labs, Pragma (voir notre étude de cas conjointe), Beamable, ainsi que les backends personnalisés. Edgegap s'intègre également avec BrainCloud, LootLocker, Invokation Games, XSOLLA et Network Next, entre autres. Si le backend était la partie qui vous inquiétait le plus, c'est généralement celle qui demande le moins de travail lors de la transition.