Pourquoi lancer son propre serveur FiveM plutôt que rejoindre celui des autres

FiveM server control is the line between playing in someone else's roleplay city and shaping every rule of your own. On a public city you accept the loading screen, the jobs, the whitelist policy and the ping you are given. Running the platform yourself hands you the configuration file, the resource stack, the permission tree and the slot logic. Here is what that actually changes, technically.

What FiveM server control actually unlocks

When you join a public city, you interact with a finished product. Everything you experience — the framework, the economy, the anti-cheat rules, the vehicle whitelist, even how many players can be visible around you — was decided by an administrator you will never talk to. The moment you administrate the FXServer yourself, those decisions move into files you can edit and reload on the fly.

Concretely, taking FiveM server control gives you authority over four layers:

• server.cfg — convars, endpoints, slot count, game build, OneSync mode, license key, MySQL string.
• The resource stack — which scripts start, in which sequence, and which ones you patch or rewrite.
• Permissions — ACE principals, admin groups, command whitelisting, txAdmin accounts.
• Framework identity — ESX, QBCore, a hybrid, or a standalone build with no framework at all.

If you are looking for the technical specifications behind a machine capable of running a 64-slot roleplay city on high-frequency Ryzen and NVMe storage, the details live on the FiveM server hosting page. The rest of this article stays on configuration and administration.

Public city compared to an instance you administrate

Layer	Public city	Instance you administrate
server.cfg	Invisible, fixed	Editable, reloadable, versioned
Scripts	Whatever the staff installed	Any resource you audit and start
Framework	Imposed (usually ESX or QBCore)	Your choice, including custom forks
Slots	Queue during peak hours	sv_maxclients tuned to your hardware
Admin tools	Reserved to staff	Full ACE tree and txAdmin ownership
Data	Not yours	MySQL dumps you keep and restore

server.cfg: the single file that defines your city

Almost everything measurable about an FXServer passes through server.cfg. It is read line by line at startup, which means the sequence matters: convars must be set before the resources that read them are started.

A realistic skeleton

# Network
endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

# Identity
sv_hostname "Los Santos Roleplay | FR/EN"
sv_projectName "LSRP"
sv_projectDesc "Serious roleplay, whitelist only"
sets tags "roleplay, esx, whitelist"
sets locale "en-US"

# Slots and sync
sv_maxclients 64
set onesync on
set onesync_population true
set onesync_distanceCullVehicles true

# Game build (DLC map and vehicles)
sv_enforceGameBuild 3095

# Security
sv_scriptHookAllowed 0
sv_authMaxVariance 1
sv_authMinTrust 5

# Database
set mysql_connection_string "mysql://fivem:[email protected]:3306/es_extended?charset=utf8mb4"

# Keys
sv_licenseKey "yourKeymasterKey"
set steam_webApiKey ""

The convar prefixes people get wrong

• set — server-side only. Database credentials, internal flags.
• setr — replicated to clients. Used when a script needs the value on both sides.
• sets — pushed to the listing metadata (tags, locale, banner).

Putting a MySQL string behind setr replicates your credentials to every connected client. It happens more often than it should. Keep secrets on set, and keep the file out of any public Git repository.

Game build and DLC content

sv_enforceGameBuild decides which GTA V content the client loads. A vehicle pack built for a recent DLC will simply fail to spawn on an older build, and MLO interiors that rely on newer map data will render as holes in the ground. When a map or car stops working after an update, the build number is the first line to check. The official reference for every convar is documented on the FiveM technical documentation.

Editing it in practice

Through a Pterodactyl panel, server.cfg sits in the file manager and can be edited directly, with the live console next to it. A typical iteration loop looks like this:

# In the live console, after editing a resource
refresh
ensure es_extended

# Reload the whole configuration
exec server.cfg

# Watch what a resource costs each frame
resmon 1

No full restart needed for most changes — only convars read at boot (endpoints, onesync, maxclients, game build) require a clean restart from the panel.

Resources, frameworks and script control

This is where FiveM server control becomes genuinely different from any other game in the catalogue. FiveM is not a game with mod support bolted on; it is a scripting platform where nearly every gameplay element is a Lua, JS or C# resource you start yourself.

Start sequence is not cosmetic

Resources are started in the sequence written in server.cfg. Dependencies must come first, otherwise you get the classic Failed to load script or an empty ESX object on the client side.

# 1. Core services
ensure mapmanager
ensure chat
ensure spawnmanager
ensure sessionmanager
ensure hardcap

# 2. Database layer
ensure oxmysql

# 3. Framework
ensure es_extended

# 4. Shared libraries
ensure ox_lib
ensure [standalone]

# 5. Jobs, economy, custom scripts
ensure [esx_addons]
ensure [jobs]
ensure [custom]

Bracketed folders like [jobs] start every resource inside them, which keeps a large city readable. Sub-folders inside sub-folders do not chain, so keep the nesting one level deep.

ESX or QBCore: a structural decision

Both frameworks give you players, jobs, inventory and money. The difference is in how they expose data and how large the third-party ecosystem is around each one.

Criterion	ESX	QBCore
Player object	xPlayer, long-standing API	Player.PlayerData, metadata-oriented
Identifier	License-based by default	Citizen ID with character slots
Inventory	Usually ox_inventory or esx_inventoryhud	qb-inventory, ox_inventory supported
Script availability	Very wide, older codebases	Wide, more consistent modern structure
Migration effort	Heavy once the economy is live	Heavy once the economy is live

The practical advice: pick one before you write a single custom job. Migrating a populated database between frameworks means remapping every identifier, every inventory row and every job grade. Test both on a staging instance, then commit.

Auditing what you install

Escrow-protected resources are common, and obfuscated Lua is not. Before an unknown script touches your database, check it for:

• outbound HTTP calls to unknown domains (PerformHttpRequest);
• ExecuteCommand calls that grant principals at runtime;
• raw SQL concatenation instead of prepared parameters;
• events registered server-side without an identifier check — the root cause of most economy exploits.

# Quick grep pass on a freshly downloaded resource
grep -rn "PerformHttpRequest" ./resources/[custom]/
grep -rn "ExecuteCommand" ./resources/[custom]/
grep -rn "add_principal" ./resources/[custom]/

Permissions, admin tooling and OneSync slot management

The ACE system, in plain terms

FiveM permissions are built from principals (who you are) and aces (what that identity is allowed to run). You attach an identifier to a group, then grant the group specific commands.

# Groups
add_ace group.admin command allow
add_ace group.moderator command.kick allow
add_ace group.moderator command.ban allow
add_ace group.moderator command.tp allow
add_ace group.moderator command.stop deny
add_ace group.moderator command.quit deny

# Inheritance
add_principal group.admin group.moderator

# People
add_principal identifier.license:1a2b3c4d5e6f7890 group.admin
add_principal identifier.discord:123456789012345678 group.moderator

# Resource-level rights
add_ace resource.txAdmin command allow

Two rules save a lot of trouble. First, never grant command allow to anyone who does not need stop, quit and exec — those three commands can take the whole city offline or reload a modified configuration. Second, prefer license or Discord identifiers over IP-based logic, which changes constantly.

txAdmin as the administration layer

txAdmin runs alongside FXServer and gives you a web interface for restarts, scheduled reboots, player actions, ban records and a live performance graph. Point it at your configuration and let it manage the process:

# Typical launch on Linux
cd /home/container/artifacts
bash run.sh +set serverProfile default +set txAdminPort 40120

Enable two-factor authentication on every txAdmin account and give each staff member their own login. Shared credentials make ban audits meaningless. Scheduled restarts every 6 to 12 hours also clear memory drift from heavy resource stacks and keep the server thread responsive.

OneSync and slot count

OneSync moves entity ownership to the server instead of the clients, which is what allows a city to go beyond the legacy 32-player ceiling and keep vehicles, props and NPCs consistent across the map.

• set onesync on — required for any sv_maxclients above 32.
• set onesync_population true — server-driven ambient population; disable it if you spawn your own traffic and pedestrians through a script.
• set onesync_distanceCullVehicles true — stops streaming distant vehicles to each client, a real gain on high slot counts.
• set onesync_forceMigration true — helps when entity ownership sticks to a disconnected client.

Raising sv_maxclients is not a pure configuration decision. Each additional player adds server-thread work, state bag replication and database queries. A roleplay city with 40 heavy resources behaves very differently at 32 and at 64 slots. Watch the txAdmin performance chart: if the server thread regularly exceeds the frame budget, either trim resources or move to a machine with more single-thread headroom before adding slots. High-frequency Ryzen cores and NVMe storage matter more here than raw core count, because the FXServer main thread is largely single-threaded.

Protecting the data you now own

The database is the city. Characters, vehicles, properties, bank accounts — all of it lives in MySQL, and a bad script update can wipe a table in seconds.

# Manual dump before any risky migration
mysqldump -u fivem -p es_extended > /backups/es_extended_$(date +%F_%H%M).sql

# Restore
mysql -u fivem -p es_extended < /backups/es_extended_2025-03-14_0300.sql

Automatic panel backups cover the resource folder and configuration; a scheduled SQL dump covers the economy. Keep at least one copy outside the machine that runs the city. Add whitelist enforcement through your framework or a Discord-linked resource, keep sv_scriptHookAllowed 0, and rotate your Keymaster key if it ever appears in a screenshot or a public repository. Volumetric attacks are filtered upstream by the network-level anti-DDoS, but application-level abuse — event spam, exploited scripts, mass connect attempts — is yours to handle through configuration and code review.

Where the same logic applies elsewhere

The pattern is not specific to Los Santos. Community-driven titles follow the same structure: a configuration file, a mod or resource stack, a permission model and a slot budget. If you administrate several communities, the approach you build here transfers directly to a RedM server or a heavily modded Rust server, and more configuration walkthroughs are collected on the Fly-Serv blog.

Closing thoughts

FiveM server control is not about having more buttons. It is about owning the four layers that define a roleplay city: the configuration file, the resource stack, the permission tree and the slot budget. Master those, keep dumps of your database, and the city stops being something you visit and becomes something you engineer, patch and grow at your own pace.

FAQ

Why do my players get stuck on the loading screen after I raise sv_maxclients?

A slot count above 32 requires OneSync. Add set onesync on before the resource block in server.cfg and restart the process fully — this convar is read only at boot. If the freeze persists, check the console for a resource failing during the join sequence, usually the framework or the MySQL layer timing out on a slow query.

Can I switch from ESX to QBCore without losing my players' characters?

Technically yes, practically it is a migration project. Both store data in MySQL but use different identifier logic and different inventory schemas. Dump your database first, map ESX identifiers to QBCore citizen IDs with a conversion script, then rebuild inventories and job grades. Test the whole process on a staging instance before touching the live database.

How do I stop a staff member from being able to shut down the whole city?

Never grant add_ace group.moderator command allow. Whitelist commands one by one (command.kick, command.ban, command.tp) and explicitly deny command.stop, command.quit and command.exec. Give each staff member an individual txAdmin account with two-factor authentication so every action stays traceable in the logs.