Héberger un serveur RedM : de zéro à en ligne

Contrairement à FiveM, RedM (le mod multijoueur de Red Dead Redemption 2, développé par la même équipe Cfx.re) souffre d'un vrai trou de documentation en français : peu de guides à jour, beaucoup d'informations reprises d'un serveur FiveM sans vérifier qu'elles s'appliquent. Ce guide couvre le chemin complet pour un propriétaire de serveur : choisir un hébergement adapté, installer et configurer FXServer pour RedM, réduire la latence, puis éviter les erreurs qui coûtent le plus cher en début de projet.

Choisir un hébergement adapté à la taille du projet

La configuration nécessaire dépend directement du nombre de joueurs visés, pas d'un chiffre universel. Trois paliers couvrent la quasi-totalité des projets RedM :

• Petit serveur ou serveur de test (jusqu'à une dizaine de joueurs) : 2 vCPU, 6 à 8 Go de RAM, 20 Go SSD NVMe. Suffisant pour tester des scripts ou une carte custom avant l'ouverture.
• Serveur communautaire stable (jusqu'à 32-64 joueurs, jobs, commerces, inventaire) : 4 vCPU haute fréquence (plus de 3,5 GHz), 12 à 16 Go de RAM, 40 à 80 Go SSD NVMe si vous utilisez des maps custom ou des MLO volumineux, et une bande passante d'au moins 1 Gbps.
• Gros serveur public (64+ joueurs, staff dédié, VOIP externe) : 6 à 8 vCPU avec boost au-delà de 4 GHz, 32 Go de RAM, 100 Go NVMe, protection anti-DDoS avancée en couche 7.

Le disque compte autant que le CPU sur RedM : une base SQL, des logs et des ressources volumineuses sur un disque mécanique (HDD) provoquent des temps d'accès qui se traduisent directement en lags côté joueur. SSD ou NVMe n'est pas une option de confort, c'est un prérequis.

VPS ou serveur dédié ?

Un VPS convient à la grande majorité des serveurs communautaires : coût réduit, déploiement rapide, scalable si votre projet grandit. Sa limite apparaît en cas de pic de charge, les ressources étant partagées avec d'autres machines virtuelles sur le même hôte physique. Un serveur dédié garantit des performances constantes et un meilleur uptime, au prix d'un budget plus élevé et d'un peu plus de maintenance. Pour un premier projet, un VPS correctement dimensionné suffit largement ; réservez le dédié aux communautés déjà établies qui ont dépassé les limites d'un VPS partagé.

Installer et configurer le serveur

Une fois l'hébergement choisi, l'installation suit toujours la même séquence :

1. Récupérer l'artefact serveur : RedM utilise le même moteur FXServer que FiveM, avec un canal de build dédié (build_proot_rdr3 pour Linux). Téléchargez-le exclusivement depuis le portail officiel Cfx.re, jamais depuis un lien tiers, et préférez la version « recommended » à la « latest » pour un serveur en production.
2. Obtenir une clé de licence Keymaster : inscrivez-vous sur le portail Keymaster de Cfx.re, créez un projet RedM et liez-le à l'adresse IP de votre serveur. La clé générée est à conserver précieusement, elle identifie votre serveur auprès de l'infrastructure Cfx.re.
3. Écrire le fichier server.cfg : nom du serveur, nombre de slots, clé Keymaster, ressources à charger au démarrage (une ligne ensure par ressource). C'est le fichier central de toute la configuration.
4. Ajouter les ressources une par une : placez-les dans le dossier resources/ et activez-les progressivement plutôt que toutes en même temps. Tester chaque ressource isolément est la façon la plus rapide d'identifier celle qui pose problème en cas de crash au démarrage.
5. Relier une base de données si votre projet en a besoin (MySQL ou MariaDB), via un connecteur comme ghmattimysql, pour stocker les données joueur de façon persistante.

Si vous préférez gérer le serveur via une interface plutôt qu'en ligne de commande, notre guide d'installation de Pterodactyl couvre la mise en place d'un panneau de gestion, transposable de FiveM à RedM.

Lancer et tester avant l'ouverture

Démarrez le serveur et surveillez la console en temps réel plutôt que de la fermer immédiatement : la majorité des erreurs de configuration se signalent explicitement au démarrage, avant même la première connexion d'un joueur. Connectez-vous ensuite depuis le client RedM via « Direct Connect » en entrant l'IP du serveur, idéalement avec un second compte pour tester les interactions sans dépendre d'un seul point de vue. txAdmin, l'interface d'administration officielle intégrée à FXServer, simplifie cette phase : logs en direct, redémarrage à distance, gestion des permissions par rôle.

Réduire la latence une fois le serveur en ligne

Une latence RedM idéale se situe entre 20 et 50 ms, reste jouable jusqu'à 100 ms, et dégrade nettement l'expérience au-delà de 150 ms. Quatre causes concentrent la quasi-totalité des cas :

• Localisation du serveur : plus la distance avec la majorité de vos joueurs est grande, plus le temps de transit augmente. Pour une communauté francophone, un hébergement en France ou en Europe de l'Ouest reste le choix logique.
• Scripts mal optimisés : une ressource qui boucle inutilement ou n'est pas revue depuis longtemps consomme du CPU serveur en continu. Visez des scripts qui tournent à 0,00-0,02 ms de temps CPU au repos, une donnée que txAdmin affiche directement par ressource.
• Matériel sous-dimensionné : CPU saturé, RAM insuffisante ou disque non-SSD se traduisent directement en lags, quelle que soit la qualité des scripts installés par-dessus.
• Attaques DDoS : une protection anti-DDoS incluse dans l'hébergement évite qu'un pic malveillant ne mette le serveur à genoux sans prévenir.

Un redémarrage planifié toutes les 12 à 24 heures, hors des heures de pointe, limite aussi l'accumulation de fuites mémoire sur les sessions longues, un classique des serveurs RP qui tournent sans interruption.

Les erreurs qui coûtent le plus cher au démarrage

• Sous-dimensionner l'hébergement pour économiser : un VPS en dessous de 4 vCPU et 8 Go de RAM avec un disque mécanique fera fuir les premiers joueurs dès les premiers ralentissements. C'est l'erreur la plus fréquente et la plus coûteuse à corriger après coup.
• Empiler les scripts sans les tester : ajouter une dizaine de ressources d'un coup rend impossible d'identifier laquelle cause un crash. Une logique modulaire, ressource par ressource, coûte plus de temps au départ mais en fait gagner énormément en diagnostic.
• Négliger la sécurité de base : pare-feu actif, ports par défaut changés, accès RDP ou SSH protégé, sauvegardes automatiques de la base de données et des fichiers serveur. Ce sont des réglages d'une heure qui évitent des incidents qui, eux, se comptent en jours.
• Ouvrir au public avant d'être prêt : une phase de test privée, même courte, permet de corriger les bugs critiques et les incohérences de configuration avant que les premiers joueurs ne se forgent une première impression, rarement rattrapable une fois négative.

Checklist avant l'ouverture

• Hébergement dimensionné pour la taille de communauté visée, disque SSD/NVMe obligatoire.
• Artefact FXServer téléchargé depuis le portail officiel Cfx.re, licence Keymaster générée et liée à l'IP du serveur.
• server.cfg écrit, ressources activées et testées une par une.
• txAdmin configuré (whitelist, permissions, sauvegardes automatiques).
• Test en conditions réelles avec au moins un second compte avant l'ouverture publique.

Si vous partez vraiment de zéro, la logique d'installation d'un serveur FXServer reste la même que sur FiveM : notre guide de mise en place d'un serveur FiveM détaille les bases communes aux deux, et notre guide de sécurisation côté serveur s'applique à l'identique sur RedM (l'architecture qui valide tout côté serveur ne dépend pas du jeu). Si vous découvrez encore RedM en tant que joueur avant de vouloir héberger votre propre projet, notre guide pour bien débuter sur RedM couvre ce premier pas. Toutes nos offres d'hébergement RedM sont préconfigurées pour ce cahier des charges, avec protection anti-DDoS incluse.