Créer un serveur RedM en 2026 : la checklist complète

La plupart des guides pour créer un serveur RedM s’arrêtent au moment où la console affiche « Server started ». C’est la partie facile, 10 pour cent du travail. Les 90 autres pour cent décident si vous aurez encore une communauté dans trois mois : une base de données qui survit à un crash, un staff incapable de ruiner l’économie par accident, des événements qu’on ne peut pas détourner, et une sauvegarde que vous avez réellement restaurée une fois. Voici la configuration d’un serveur RedM que nous suivrions nous-mêmes en 2026, dans l’ordre où vous en avez besoin.

Il suppose un serveur de roleplay avec un framework. Rien ici n’exige d’acheter quoi que ce soit chez nous, et notre propre produit n’a droit qu’à une section que vous pouvez sauter.

#Créer un serveur RedM : ce qu’il vous faut d’abord

• Une copie de Red Dead Redemption 2 et un compte Cfx.re. Les joueurs ont besoin du jeu pour se connecter. Vous avez besoin du compte pour lier txAdmin et demander une clé de licence.

• Une clé de licence serveur. Chaque FXServer en a besoin d’une, demandée gratuitement sur le portail Cfx.re (beaucoup de guides l’appellent encore Keymaster). La clé est liée à votre compte et se place dans server.cfg.

• Une machine pour le faire tourner. Un PC personnel suffit pour construire et tester. Pour des joueurs, louez un VPS ou un serveur dédié avec une IP publique fixe.

• Les artefacts serveur. Les binaires de FXServer, disponibles pour Windows et Linux sur la page de téléchargement officielle. Cfx.re décrit la version Linux comme un portage de courtoisie, et indique que les problèmes ont plus de chances d’être corrigés sous Windows. Si vous connaissez bien Linux, c’est quand même un bon choix. Sinon, Windows vous fera perdre moins de temps.

Côté matériel, il n’existe pas de tableau officiel pour un serveur RedM de roleplay, alors prenez ceci comme une règle empirique tirée de l’expérience, pas comme une garantie. FXServer fait l’essentiel de son travail sur quelques threads, donc la vitesse d’un cœur compte plus que leur nombre. Prévoyez un stockage rapide (NVMe) et au moins 8 Go de RAM pour un petit serveur. Votre framework et le nombre de scripts pèsent plus que le nombre brut de joueurs.

#Créer un serveur RedM : installer FXServer avec txAdmin

txAdmin est livré avec les artefacts FXServer et c’est la manière standard de gérer un serveur : un panel web pour démarrer, arrêter et redémarrer, lire la console, gérer les joueurs et planifier les redémarrages. Le guide officiel de txAdmin couvre le premier lancement. En bref :

1. 1

   Téléchargez la version recommandée pour votre système et extrayez-la dans son propre dossier, à l’écart des données du serveur.

2. 2

   Lancez FXServer.exe (Windows) ou run.sh (Linux). Une page txAdmin s’ouvre avec un code PIN.

3. 3

   Liez votre compte Cfx.re et définissez le mot de passe administrateur.

4. 4

   Nommez le serveur et choisissez un modèle de déploiement (une recette), ou indiquez à txAdmin un dossier de données que vous avez déjà.

5. 5

   Saisissez votre clé de licence quand la recette la demande, exécutez la recette, puis enregistrez et démarrez.

Certains frameworks RedM publient une recette txAdmin qui télécharge le framework, ses dépendances et un lot de ressources de base d’un seul coup. C’est le chemin le plus rapide vers une pile de type serveur RedM 2026 fonctionnelle, et vous pouvez lire la recette avant de l’exécuter. Une recette installe des logiciels sur votre machine.

#Choisir un framework et sa base de données

Le framework décide de ce qu’attend chaque script de votre serveur : personnages, inventaire, métiers, argent. En changer plus tard revient à refaire la plupart de vos ressources, donc choisissez une fois.

• VORP Core est l’un des deux grands frameworks de roleplay, avec un large catalogue de scripts et une documentation publique.

• RSG Core est l’autre, inspiré de QBCore sur FiveM. Si vous connaissez cet écosystème, sa structure vous semblera familière.

• D’autres frameworks existent, et standalone est un choix légitime si vous construisez une petite expérience scriptée sans systèmes de roleplay complets.

Choisissez selon les scripts que vous voulez faire tourner et la communauté à qui demander de l’aide, pas selon un tableau de fonctionnalités.

Les deux grands frameworks ont besoin d’une base de données, MySQL ou MariaDB, accessible via la ressource oxmysql sur les installations actuelles. Créez une base et un utilisateur dédiés au serveur, gardez la base sur la même machine (ou sur un réseau privé), et n’exposez pas le port 3306 à Internet. Certains guides d’installation l’ouvrent à toutes les adresses par commodité. Ne copiez pas cette partie. Placez la chaîne de connexion dans server.cfg au-dessus de vos lignes ensure, avec charset=utf8mb4 pour que les pseudos accentués soient stockés correctement.

#Configuration d’un serveur RedM : l’essentiel de server.cfg

Votre server.cfg est le fichier qui fait la différence entre un labo et un vrai serveur. Voici une forme courte et fonctionnelle pour RedM. Chaque directive ci-dessous vient du manuel serveur de Cfx.re.

# Lancer RedM, pas FiveM
set gamename rdr3

# Réseau : ne changez le port que si vous y êtes obligé
endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

# OneSync est requis au-delà de 32 slots
set onesync on
sv_maxclients 48

# Votre clé de licence du portail Cfx.re. Ne la publiez jamais.
sv_licenseKey "YOUR_LICENSE_KEY"

# Référencement
sv_hostname "My RedM Server"
sets sv_projectName "My RedM Server"
sets sv_projectDesc "Serious roleplay in the Old West."
sets locale "fr-FR"

# Bloquer les clients Script Hook (valeur par défaut, laissée explicite)
sv_scriptHookAllowed 0

# Connexion à la base de données, au-dessus de chaque ligne ensure
set mysql_connection_string "mysql://user:password@localhost/dbname?charset=utf8mb4"

# Optionnel : figer une version du jeu. Cfx.re indique la build 1491 pour RedM ;
# laissez en commentaire sauf si un script dont vous dépendez le demande.
# sv_enforceGameBuild 1491

Quelques remarques sur ce fichier. Au-delà de 32 slots, FXServer exige OneSync, et au-delà de 64 il exige onesync on, donc le régler dès le départ vous évite une migration. sv_enforceGameBuild n’agit qu’au démarrage et le tableau officiel ne liste qu’une seule build RedM, donc nous le laissons comme option plutôt que comme recommandation : n’y touchez que si une ressource le documente. sv_scriptHookAllowed est désactivé par défaut, et Cfx.re avertit que l’activer rend le serveur vulnérable à des problèmes de sécurité. Enfin, lancez le serveur avec +exec server.cfg depuis votre dossier de données, ou txAdmin le fait pour vous.

#Ressources et ordre de chargement

Les ressources démarrent dans l’ordre des lignes ensure. Un script qui a besoin de la base de données ou du framework doit venir après eux, sinon il démarre, ne trouve rien et échoue au premier usage. L’ordre qui marche presque partout :

ensure oxmysql
ensure your_framework_core
ensure your_framework_modules   # inventaire, personnages, menus
ensure security_and_moderation  # anticheat, journalisation
ensure gameplay_scripts
ensure maps_and_cosmetics

• Ajoutez les scripts un par un. Redémarrez, lisez la console, testez en jeu, puis ajoutez le suivant. Vingt scripts ajoutés d’un coup et une erreur, ce sont vingt suspects.

• Lisez le script avant de le lancer. Le code serveur s’exécute avec un accès complet à votre base de données et à vos fichiers. Un script piraté ou ayant fuité est une façon classique de perdre un serveur.

• Testez les changements sur une copie. N’expérimentez pas sur le serveur en production un samedi soir.

#Rôles et permissions du staff

Donnez à chaque membre du staff le minimum dont il a besoin, et donnez-le à une personne nommée, pas à un compte partagé. txAdmin a ses propres comptes administrateurs avec des permissions fines pour le panel. En jeu, FXServer utilise un système de permissions ACE configuré dans server.cfg :

# Modérateurs : peuvent utiliser les commandes que vous leur accordez, rien d’autre
add_principal identifier.license:MODERATOR_LICENSE group.moderator

# Admins
add_ace group.admin command allow
add_ace group.admin command.quit deny
add_principal identifier.license:ADMIN_LICENSE group.admin

• Réservez le rôle de propriétaire aux personnes qui peuvent aussi toucher à l’hôte et à la base de données. C’est la vraie racine de votre serveur.

• Ne donnez jamais au staff en jeu de pouvoirs qui permettent de créer de l’argent ou des objets sauf si leur rôle l’exige, et journalisez chaque usage. La plupart des catastrophes d’économie commencent par une commande du staff.

• Retirez les accès le jour où quelqu’un quitte l’équipe, dans txAdmin, dans server.cfg, sur l’hôte et sur votre Discord.

#Des sauvegardes avant votre premier joueur

Il vous faut deux types de sauvegarde : le dossier de données du serveur (ressources, configurations) et votre base de données. Les joueurs tiennent bien plus à la seconde que vous. Stockez des copies hors de la machine, car une sauvegarde sur le même disque meurt avec le disque.

mysqldump -u youruser -p yourdatabase | gzip > /backups/server-$(date +%F).sql.gz

Faites aussi un dump avant chaque mise à jour de ressource et chaque changement de framework. Puis faites l’étape que la plupart des propriétaires sautent : restaurez la sauvegarde sur un serveur de test et vérifiez que les personnages et les inventaires sont intacts. Une sauvegarde que vous n’avez jamais restaurée est un espoir, pas une sauvegarde.

#La sécurité dès le premier jour

Le moment le moins cher pour boucher une faille, c’est avant que les joueurs en dépendent. Trois choses comptent au lancement.

Les événements serveur

Chaque gestionnaire RegisterNetEvent est une porte sur laquelle n’importe quel client peut frapper, avec n’importe quels arguments. Les scripts qui font confiance au client pour dire combien d’argent il a gagné, ou quel objet il a reçu, sont la source des duplications et des exploits d’économie. Vérifiez cela avant d’ajouter un script, et encore avant d’écrire le vôtre. Les détails sont dans notre guide pour sécuriser les événements serveur RedM, et le versant des dégâts dans l’article sur les dupes d’argent.

Un anticheat dès le départ

Installer un anticheat après l’arrivée du premier tricheur est la méthode coûteuse : à ce moment-là, les joueurs ont vu ce que le serveur tolère. Il y a plusieurs façons d’en choisir un, détaillées dans notre guide d’achat de l’anticheat RedM. Quel que soit votre choix, vérifiez qu’il fonctionne avec votre framework (voir anticheat pour VORP).

Si vous choisissez Baobab AC, la mise en place est courte et documentée pas à pas sur la page d’installation. Ce qui compte pour un nouveau serveur :

• Votre serveur a besoin d’un accès HTTPS sortant vers l’API Baobab, donc un pare-feu de sortie restrictif le bloquera.

• Vous créez le serveur dans le panel et copiez sa clé d’API à la création, car elle n’est affichée qu’une seule fois.

• Placez la clé dans server.cfg avec set, jamais setr : une convar setr est répliquée à tous les clients connectés, ce qui rendrait votre clé lisible par n’importe quel joueur.

• Chargez-le juste après le core de votre framework, et exemptez votre staff via les groupes ACE admin pour que les tests ne déclenchent pas de détections.

• Il démarre en alerte seule : rien n’est sanctionné tant que vous n’avez pas décidé d’appliquer les sanctions, ce qui vous laisse le temps de lire d’abord ce qu’il voit sur votre propre serveur.

• La ressource se met à jour toute seule sur le disque et applique la nouvelle version à votre prochain redémarrage.

Vous pouvez voir à quoi ressemble le panel sans compte dans la démo en ligne, et la page des fonctionnalités liste chaque détection.

Une politique de ban qui tient

Écrivez vos règles avant le premier ban, et décidez qui peut bannir et sur quelles preuves. Les tricheurs reviennent avec de nouveaux comptes. Le fonctionnement des bans matériels et par identifiants, ce qu’ils peuvent et ne peuvent pas faire, est expliqué dans notre article sur le ban HWID RedM.

#Créer un serveur RedM : la checklist du jour du lancement

N’ouvrez pas les portes avant que chaque ligne soit vraie.

1. 1

   Clé de licence définie dans server.cfg, fichier gardé privé et hors de tout dépôt public.

2. 2

   gamename rdr3, OneSync et endpoints configurés, serveur visible et joignable depuis une machine extérieure à votre réseau.

3. 3

   Pare-feu : port de jeu ouvert, txAdmin restreint, port de la base fermé à Internet.

4. 4

   Base de données sur un utilisateur dédié, utf8mb4, identifiants réutilisés nulle part ailleurs.

5. 5

   Ordre de chargement vérifié : base de données, framework, modules, sécurité, gameplay.

6. 6

   Chaque script lu, sa source connue, et aucun fichier piraté ou ayant fuité.

7. 7

   Événements serveur revus pour tout ce qui laisse un client décider de l’argent, des objets ou de l’XP.

8. 8

   Comptes du staff nominatifs, permissions minimales, chacun testé une fois.

9. 9

   Anticheat en marche, staff exempté, et une connexion de test vérifiée dans la console et le panel.

10. 10

    Politique de ban et règles écrites et affichées là où les joueurs peuvent les lire.

11. 11

    Sauvegarde faite, stockée hors de la machine, et restaurée une fois sur un serveur de test.

12. 12

    Planning de redémarrage défini dans txAdmin, avec un message d’avertissement pour les joueurs.

13. 13

    Une annonce qui dit aux joueurs comment signaler un problème, et un membre du staff éveillé pour la première soirée.

Les parties techniques prennent un après-midi. Les règles du staff, les sauvegardes et l’habitude de lire avant d’installer sont ce qui garde un serveur debout. Pour le volet anticheat, commencez par comment fonctionne un anticheat RedM. La page des tarifs est publique quand vous serez prêt à comparer.