Où trouver le server.cfg de mon serveur FiveM ?

Dans le dossier racine de votre serveur, accessible via le gestionnaire de fichiers de votre panel ou via SFTP. Si vous utilisez txAdmin, vous avez désigné le fichier pendant la configuration initiale, txAdmin sait donc exactement quelle config est chargée.

Quelle est la différence entre start et ensure ?

Les deux démarrent une ressource, mais ensure la redémarre aussi si elle tourne déjà. Cela rend ensure plus prévisible, et c'est aujourd'hui le choix courant dans pratiquement chaque server.cfg.

Combien de joueurs puis-je définir avec sv_maxclients ?

Par défaut, sv_maxclients est réglé sur 48. Pour aller au-delà, OneSync est obligatoire et des conditions supplémentaires de Cfx.re s'appliquent. Choisissez dans tous les cas un nombre adapté à votre offre et à votre communauté réelle.

Ma clé de licence doit-elle figurer dans le server.cfg ?

Si vous utilisez txAdmin, vous saisissez la clé pendant la configuration et txAdmin la gère pour vous ; vous n'avez alors pas besoin de mettre sv_licenseKey vous-même dans le server.cfg. Ne partagez jamais votre clé, même quand vous publiez votre config en ligne pour demander de l'aide.

// FiveM

server.cfg expliqué : les lignes qui comptent vraiment

24 août 2026 · 5 min de lecture

Ouvrez le dossier de n'importe quel serveur FiveM et vous le trouverez toujours : server.cfg. C'est le premier fichier que FXServer lit au démarrage, et il détermine le nom de votre serveur, le nombre de joueurs simultanés et les ressources qui tournent. Pourtant, beaucoup d'admins débutants le traitent comme un fichier magique auquel il vaut mieux ne pas toucher. Dommage, car qui comprend son server.cfg résout seul la moitié des problèmes de démarrage. Dans cet article, nous passons en revue les lignes qui comptent vraiment, et celles qui n'y ont justement pas leur place.

Comment FXServer lit votre server.cfg

Le server.cfg n'est pas du code de programmation, mais une liste d'instructions. FXServer lit le fichier de haut en bas et exécute chaque ligne une par une. Cela semble trivial, mais cela explique aussitôt pourquoi l'ordre est important : un script qui repose sur un framework doit être démarré après ce framework. Les lignes commençant par # sont des commentaires et sont ignorées. Utilisez-les généreusement pour diviser votre fichier en blocs, car après un an de bricolage, une config sans structure devient un labyrinthe.

Si vous utilisez txAdmin, comme c'est le cas par défaut sur les serveurs FiveM de MC-Node, vous désignez un server.cfg pendant la configuration initiale et vous pouvez ensuite le modifier via le gestionnaire de fichiers ou SFTP. Important à retenir : les modifications de convars ne prennent effet qu'après un redémarrage complet du serveur. Recharger une ressource ne suffit pas.

Les convars qui comptent vraiment

Les convars sont les paramètres de votre serveur. Voici une base saine :

# liste des serveurs et présentation
sv_hostname "Ma ville RP | Français | Whitelist"
sets sv_projectName "Ma ville RP"
sets sv_projectDesc "Roleplay français avec scripts personnalisés"
sets tags "roleplay, francais, whitelist"
sets locale "fr-FR"

# technique
sv_maxclients 48
set onesync on

sv_hostname est le nom affiché dans la liste des serveurs ; sv_projectName et sv_projectDesc remplissent la fiche du serveur autour. Soyez concret : "RP français | Whitelist | 18+" attire exactement les bons joueurs, "Server123" n'attire personne.
sets tags et sets locale déterminent la façon dont on vous trouve. Les joueurs filtrent réellement la liste des serveurs par langue et par tags, alors réglez locale sur fr-FR si vous visez des joueurs francophones. Si votre serveur n'apparaît pas du tout dans la liste, la cause est généralement un problème de licence ou de config.
sv_maxclients est le nombre maximal de joueurs simultanés ; par défaut, il est de 48. Ne le gonflez pas pour faire joli, choisissez une valeur adaptée à votre offre et à votre communauté.
set onesync on active OneSync, le modèle de synchronisation moderne de FXServer. Au-delà de 48 slots, OneSync est de toute façon obligatoire et des conditions supplémentaires de Cfx.re s'appliquent. La base de connaissances explique comment activer OneSync.

Notez aussi la différence entre set, setr et sets. Avec set, une valeur reste sur le serveur, setr la partage avec le jeu de vos joueurs et sets la rend publiquement visible dans la liste des serveurs. Tout ce que vous définissez avec sets peut donc être lu par n'importe qui ; n'y mettez jamais rien qui doive rester privé.

Et sv_licenseKey ? Elle fait formellement partie de cette liste, mais si vous utilisez txAdmin, vous saisissez votre clé de licence pendant l'assistant de configuration et txAdmin la gère ensuite pour vous. Vous n'avez donc pas besoin de la mettre vous-même dans le server.cfg, et c'est d'ailleurs l'endroit le plus sûr.

ensure : vos ressources dans le bon ordre

La majeure partie d'un server.cfg moyen se compose de lignes ensure. ensure démarre une ressource, et la redémarre si elle tourne déjà. Vous verrez parfois l'ancien start ; il fonctionne, mais ensure est l'habitude la plus robuste. La règle d'or pour l'ordre : les fondations d'abord, puis ce qui repose dessus.

# fondations : base de données et framework
ensure oxmysql
ensure es_extended

# ensuite seulement les scripts qui en dépendent
ensure esx_garage
ensure mon_jobscript

Si vous démarrez un script de métier avant que votre framework ne tourne, le script plante ou attend indéfiniment, et vous obtenez une console remplie de messages rouges. Certaines ressources déclarent proprement leurs dépendances dans leur fxmanifest.lua, mais ne vous y fiez pas aveuglément : un ordre logique dans le server.cfg évite neuf problèmes de démarrage sur dix.

Ce qui n'a pas sa place dans votre server.cfg

Ce que vous omettez est au moins aussi important :

Les mots de passe et clés secrètes. Pensez à un mot de passe de base de données dans une chaîne de connexion ou aux clés API de services externes. Le problème : le server.cfg est précisément le fichier que l'on copie et partage quand on demande de l'aide quelque part. Ne partagez votre config qu'après en avoir retiré tous les secrets, et traitez ce fichier comme s'il devait un jour devenir public.
rcon_password, sauf si vous utilisez vraiment rcon. Avec txAdmin, vous avez rarement besoin de rcon, et un mot de passe rcon faible est une porte dérobée ouverte vers votre console. Mieux vaut alors omettre complètement cette ligne.
Les lignes mortes. Des ensure de ressources supprimées depuis longtemps, des expérimentations commentées d'il y a des mois : faites le ménage. Chaque ligne que vous ne comprenez plus est une source de confusion future.

Les erreurs fréquentes

Les ensure en double. Démarrer deux fois la même ressource arrive plus vite qu'on ne le pense, surtout si vous avez collé une config d'exemple par-dessus vos propres lignes. Cela ne casse généralement rien, mais votre console se plaint et le débogage devient inutilement confus.
Un ensure sans ressource. Vous supprimez un dossier de ressource mais oubliez la ligne. Résultat : un message "Couldn't find resource" à chaque démarrage. Inoffensif, mais cela pollue votre console et vous fait manquer les vraies erreurs.
Des noms presque corrects. Le nom dans ensure doit correspondre exactement au nom du dossier de la ressource, majuscules et traits d'union compris. Les espaces dans les noms de dossiers, c'est de toute façon chercher les ennuis.
Oublier de redémarrer. Vous modifiez sv_maxclients, ne voyez rien changer et continuez à chercher, alors que la modification n'a simplement pas encore été chargée.

Pour presque toutes ces erreurs, le même principe s'applique : la console en direct de txAdmin vous dit littéralement ce qui ne va pas. Lisez les premiers messages à chaque démarrage ; cela prend trente secondes et vous épargne des heures de tâtonnements.

Honnêtement : la perfection n'est pas nécessaire

Un server.cfg n'a pas besoin d'être une œuvre d'art. Une bonne config, c'est un fichier avec des blocs clairs, un ordre d'ensure logique et aucun secret à l'intérieur. Commencez petit, ajoutez une ressource à la fois et vous saurez toujours d'où vient un problème. Quand votre serveur grandit, votre config grandit avec lui, et c'est là que cette base propre paie doublement.