Changer d'hébergeur pour un serveur FiveM soulève presque toujours la même inquiétude : est-ce que ma licence va casser, et comment mes joueurs vont-ils retrouver le serveur si l'adresse change ? Les deux questions ont des réponses simples, mais elles sont rarement expliquées ensemble. Ce guide couvre la licence Keymaster (qui ne bouge pas), l'adresse IP (qui, elle, change forcément), et la solution qui règle ce deuxième point une fois pour toutes : un nom de domaine.
La licence Keymaster n'est pas liée à une adresse IP
Première chose à savoir, et elle rassure d'entrée : la clé de licence générée sur keymaster.fivem.net (la valeur que vous placez dans server.cfg sous sv_licenseKey) est associée à votre compte Cfx.re, pas à l'adresse IP du serveur qui la fait tourner. Vous pouvez arrêter votre serveur chez un hébergeur, le redémarrer ailleurs avec la même clé, et il fonctionnera sans démarche supplémentaire côté Keymaster. C'est ce qui rend une migration FiveM fondamentalement plus simple qu'une migration de site web avec ses certificats et ses enregistrements DNS complexes : la partie « identité du serveur » ne bouge pas.
Ce que la clé de licence protège, c'est l'usage de la plateforme Cfx.re elle-même (accès aux artefacts, au serveur de mise à jour, à l'infrastructure réseau qui relaie les connexions), pas un hébergement en particulier. Vous n'avez donc rien à régénérer ni à réautoriser sur Keymaster après une migration : copiez la même valeur de sv_licenseKey dans le server.cfg du nouveau serveur, et c'est réglé.
Ce qui change réellement : l'adresse IP
Ce qui change, en revanche, c'est l'adresse IP publique du serveur : elle appartient à l'hébergeur, pas à vous, et un nouvel hébergeur signifie mécaniquement une nouvelle IP. C'est ce détail qui inquiète le plus les propriétaires de serveur, parce que c'est cette adresse que les joueurs utilisent pour se connecter (connect 51.xxx.xxx.xxx:30120 par exemple) ou qu'ils ont enregistrée dans leurs favoris FiveM.
Il n'y a pas de manipulation qui « transfère » une IP d'un hébergeur à un autre : chaque hébergeur possède ses propres plages d'adresses, et ce n'est de toute façon pas souhaitable de chercher à contourner ça. La bonne réponse n'est pas de sauver l'ancienne IP, c'est de ne plus jamais dépendre d'une IP publiquement.
Pointer un nom de domaine vers votre serveur : la solution durable
Un nom de domaine (ou un sous-domaine, ex. play.votreserveur.com) réglé une bonne fois pour toutes règle le problème des futures migrations, y compris celle-ci :
- Créez un enregistrement DNS de type A (ou AAAA en IPv6) pointant votre domaine ou sous-domaine vers l'adresse IP actuelle du serveur, depuis l'interface de votre registrar ou de votre zone DNS.
- Communiquez ce domaine aux joueurs plutôt que l'IP brute : dans le Discord de votre communauté, sur vos réseaux, et dans le
server.cfglui-même (variablessv_hostname,sets tags). Les joueurs se connectent avecconnect play.votreserveur.comexactement comme avec une IP. - Le jour d'une future migration, il suffit de modifier la cible de l'enregistrement A pour qu'il pointe vers la nouvelle IP. Le domaine ne change jamais, seule sa destination change en coulisses : côté joueur, rien à retenir de nouveau.
Anticipez la propagation DNS. Un changement d'enregistrement A n'est pas instantané pour tout le monde : certains résolveurs mettent en cache l'ancienne valeur pendant la durée du TTL (time to live) de l'enregistrement. Avant une migration planifiée, abaissez le TTL à une valeur courte (300 secondes, par exemple) quelques heures à l'avance : la bascule se propage alors beaucoup plus vite le jour J. Remontez-le à une valeur normale une fois la migration stabilisée.
Sauvegarder et transférer les données du serveur
Une fois la question de l'adresse réglée, le reste de la migration est un transfert de fichiers classique :
- Sauvegardez l'intégralité du dossier serveur (resources, artefacts,
server.cfg) vers votre poste ou un stockage temporaire, avecrsync,SFTPou l'export intégré de votre panel si vous utilisez Pterodactyl. - Exportez votre base de données si le serveur en utilise une (comptes joueurs, inventaires, économie) avec un export SQL classique. Vérifiez la taille du fichier obtenu avant de le considérer complet.
- Installez le nouveau serveur chez le nouvel hébergeur, réimportez le dossier et la base, puis collez la même
sv_licenseKeyque sur l'ancien serveur. - Testez en interne (connexion directe à la nouvelle IP, avant même de basculer le DNS) que les scripts, la base et les artefacts fonctionnent, plutôt que de découvrir un problème une fois les joueurs redirigés.
Checklist du jour de la migration
- Licence Keymaster : rien à faire, la même clé fonctionne sur la nouvelle IP.
- TTL de l'enregistrement DNS abaissé quelques heures avant, pour une propagation rapide.
- Nouveau serveur testé en direct sur sa nouvelle IP avant de rediriger le domaine.
- Enregistrement A mis à jour vers la nouvelle IP, ancien serveur gardé actif quelques heures en parallèle si possible.
- Annonce aux joueurs (Discord, réseaux) une fois la bascule confirmée, en rappelant qu'ils se connectent toujours au même domaine.
- Ancien hébergement résilié seulement après confirmation que tout fonctionne sur le nouveau, jamais le jour même.
Si votre hébergement actuel est justement la raison de cette migration (lags, support qui ne répond pas, protection réseau absente), notre guide sécurité réseau et anti-DDoS détaille ce qu'un hébergement FiveM sérieux doit couvrir par défaut. Toutes nos offres FiveM incluent cette protection sans option payante, et notre guide de mise en place d'un serveur FiveM couvre l'installation initiale si vous repartez sur une base propre. Enfin, si vous protégez déjà votre communauté des tricheurs, notre guide anti-cheat complète cette checklist de migration.