Migrer son serveur FiveM d'un hébergeur à l'autre : licence Keymaster et IP

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 (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. Elle se gère aujourd'hui depuis le Cfx.re Portal : l'ancien Keymaster (keymaster.fivem.net) a été définitivement retiré le 1er décembre 2025, et les clés ainsi que les enregistrements de serveur existants ont été repris tels quels lors de la bascule, sans rien à refaire de votre côté. 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 sur le Portal. 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 le Cfx.re Portal 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 (qu'il s'agisse d'un VPS ou d'un serveur dédié), 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 réseau, 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 en dépendre publiquement, grâce au nom de domaine détaillé ci-dessous.

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.cfg lui-même (variables sv_hostname, sets tags). Les joueurs se connectent avec connect play.votreserveur.com exactement 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.

Ce qui migre automatiquement, ce qui doit être refait à la main

Avant de détailler les étapes de transfert, un tableau récapitulatif évite les mauvaises surprises le jour de la bascule :

Exporter et importer la base de données ESX ou QBCore

La base de données est ce qui contient la vraie valeur d'un serveur RP établi : les comptes joueurs, l'inventaire, l'argent, les grades et les comptes de société. Elle ne migre jamais automatiquement d'un hébergeur à l'autre, et sa structure diffère selon le framework installé :

• Sur ESX Legacy, la table users porte le compte du joueur (identifiant, comptes, groupe, inventaire, job, grade), items définit les objets disponibles, et job_grades porte la hiérarchie et le salaire de chaque échelon d'un métier. Les comptes de société (society_police, society_taxi, etc., gérés par esx_society) doivent démarrer avant les scripts qui les utilisent, à vérifier dans l'ordre du nouveau server.cfg.
• Sur QBCore, l'essentiel du personnage (identifiant, licence, argent, informations de personnage, job, gang, position, métadonnées) vit dans une seule table players. Les définitions d'objets et de gangs, elles, sont le plus souvent des tables Lua de configuration plutôt que des lignes en base : elles migrent avec les fichiers de resources, pas avec l'export SQL.

Dans les deux cas, la procédure reste un export SQL classique (mysqldump ou l'export intégré de phpMyAdmin/Adminer) depuis l'ancien hébergeur, suivi d'un import sur la base créée chez le nouvel hébergeur, avant même de démarrer le nouveau serveur.

Faire correspondre la version de l'artifact FXServer entre les deux hébergeurs

FXServer est distribué sous forme d'artifacts, des builds numérotées publiées en continu par Cfx.re. Un ancien serveur figé depuis des mois peut tourner sur un artifact nettement plus ancien que celui que le nouvel hébergeur installe par défaut : un saut de version trop important peut révéler des natives dépréciées ou un comportement changé sur des scripts anciens. Avant la bascule, notez le numéro de build affiché au démarrage de l'ancien serveur, et testez vos ressources sur l'artifact recommandé actuel chez le nouvel hébergeur plutôt que de découvrir un script cassé une fois les joueurs redirigés.

Vérifier les dépendances entre resources avant la bascule

Un script FiveM déclare ses dépendances dans son fxmanifest.lua (bibliothèques partagées, frameworks requis). Un transfert de dossier qui oublie une resource dépendante, souvent une bibliothèque utilitaire discrète plutôt qu'un script visible, fait planter tout ce qui en dépend au démarrage, sans message toujours explicite. Avant de considérer le transfert terminé, comparez la liste complète du dossier resources/ de l'ancien serveur à celle copiée sur le nouveau, dossier par dossier, plutôt que de vous fier au chargement sans erreur apparente en console.

Vérifier l'intégrité du transfert avec un hash

Au-delà de comparer visuellement la liste des dossiers copiés, un moyen plus fiable de détecter une copie corrompue (coupure réseau en plein SFTP, fichier tronqué) est de comparer une empreinte de hachage avant et après transfert : sha256sum (ou md5sum, moins robuste mais suffisant pour détecter une corruption accidentelle plutôt qu'une modification volontaire) calculé sur une archive du dossier resources/ avant l'envoi, puis recalculé sur la copie arrivée chez le nouvel hébergeur. Deux empreintes identiques confirment un transfert fidèle ; une différence indique un fichier corrompu ou incomplet, à retransférer avant de considérer la resource fiable.

Tester sur un second FXServer avant la coupure finale

La bascule la plus sûre ne coupe jamais l'ancien serveur avant d'avoir validé le nouveau en conditions réelles. Faites tourner le nouveau serveur sur son port et son IP propres, connectez-vous en direct à cette nouvelle adresse (sans passer par le domaine, encore pointé sur l'ancien serveur à ce stade), et vérifiez dans l'ordre : connexion et spawn du personnage, lecture correcte de l'inventaire et de l'argent depuis la base réimportée, chargement de l'ensemble des resources sans erreur en console, et accès admin fonctionnel via les permissions ACE reconfigurées. C'est seulement une fois ces quatre points validés que la bascule du domaine, détaillée plus haut, doit intervenir.

Ce que txAdmin garde en local, indépendamment de la base MySQL

Une partie de la configuration ne vit ni dans server.cfg ni dans la base de données du framework, mais dans le fichier de données propre à txAdmin sur l'ancien serveur : elle ne migre donc jamais automatiquement.

Recréer les tâches planifiées : redémarrage automatique et sauvegardes

Deux automatisations discrètes, mais faciles à oublier le jour d'une migration, ne survivent jamais au transfert de fichiers :

• Le redémarrage programmé de txAdmin (réglé dans Settings puis Restart Schedule, le plus souvent toutes les 6 à 12 heures pour limiter la dérive mémoire d'un serveur qui tourne en continu) est une configuration locale à l'installation : une installation neuve chez le nouvel hébergeur démarre sans aucun horaire programmé, à reprogrammer explicitement avec le même rythme pour retrouver la stabilité dont bénéficiait l'ancien serveur.
• Une sauvegarde automatique, qu'elle tourne via une tâche planifiée côté ancien hébergeur ou via une automatisation propre au panel utilisé, ne se recrée pas non plus toute seule sur le nouveau serveur : il faut la reconfigurer avant de considérer la migration terminée, plutôt que de découvrir son absence le jour où on en a réellement besoin.

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 :

1. Sauvegardez l'intégralité du dossier serveur (resources, artefacts, server.cfg) vers votre poste ou un espace de stockage temporaire, avec rsync, SFTP ou l'export intégré de votre panel si vous utilisez Pterodactyl.
2. 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.
3. Installez le nouveau serveur chez le nouvel hébergeur, réimportez le dossier et la base, puis collez la même sv_licenseKey que sur l'ancien serveur.
4. 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.

Combien de temps d'indisponibilité annoncer aux joueurs

Avec un domaine déjà pointé et un TTL abaissé à l'avance (voir plus haut), et le nouveau serveur testé en parallèle avant la bascule (voir plus haut), le temps d'indisponibilité réel se limite le plus souvent à quelques minutes : le temps que la propagation DNS touche la majorité des résolveurs, pas des heures. Ce qui rallonge une migration n'est presque jamais la bascule du domaine elle-même, mais un import de base de données incomplet ou un artifact incompatible découvert après coup (voir plus haut) : les deux se préviennent en testant sur le second FXServer avant de couper quoi que ce soit. En pratique, la fenêtre à annoncer aux joueurs va de quelques minutes à une petite heure selon la taille de la base et le nombre de resources à transférer, communiquée à l'avance plutôt qu'au moment où le serveur disparaît sans explication.

Checklist du jour de la migration

• Licence Cfx.re Portal : 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.
• Logs txAdmin (admin.log, server.log) copiés si l'historique de modération doit être conservé.
• Redémarrage programmé et sauvegardes automatiques reconfigurés dans txAdmin, pas seulement les resources et la base.
• Empreinte hash comparée sur les resources transférées, pour écarter une copie corrompue.
• 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.