server.cfg, OneSync and the ensure order

The server.cfg is your server's startup script: a text file that FXServer reads top to bottom every time you boot. In it you configure the network, name the server, enable synchronization, define permissions and, above all, decide WHICH resources to load and IN WHAT ORDER. If something goes wrong on startup, 90% of the time the cause is right here.

An example server.cfg, commented#

# --- Network: where the server listens ---
endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

# --- Presentation ---
sv_hostname "Crxative-M | ESX | Roleplay ES"
sv_maxclients 48              # max number of players (>32 requires OneSync)
sv_projectName "Crxative-M"
sv_projectDesc "Spanish roleplay server"

# --- Server-authoritative sync ---
set onesync on
sv_endpointprivacy true       # does not expose player IPs

# --- Base resources (ORDER matters, see below) ---
ensure oxmysql
ensure ox_lib
ensure es_extended
ensure my_resource

# --- Secrets (outside the repository) ---
exec secrets.cfg

Key directives you should know#

• endpoint_add_tcp / endpoint_add_udp "0.0.0.0:30120": the port the server listens on. 0.0.0.0 means «all network interfaces». 30120 is FiveM's standard port.
• sv_maxclients: maximum simultaneous players. More than 32 REQUIRES OneSync to be enabled.
• sv_hostname: the name shown in the server list (supports colors with ^1, ^2…).
• sv_licenseKey "...": your key from cprx.fivem.net (keymaster). It is personal and non-transferable: NEVER share it or push it to Git.
• set onesync on: enables modern server-authoritative synchronization.
• sv_endpointprivacy true: hides the IP addresses of connected players.
• exec other.cfg: runs another config file as if it were written here (ideal for separating secrets).

ensure, start, stop and restart#

To load resources you have several commands, but in the server.cfg you'll almost always want ensure. The difference: start only launches the resource if it's stopped (and fails ugly if it was already running). ensure is smarter: if the resource isn't running, it starts it; if it was already running, it restarts it. It's idempotent, so it's safe to keep in the cfg and run again.

ensure  oxmysql      # start or restart (what you'll use almost always)
start   oxmysql      # only starts if it's stopped
stop    oxmysql      # stops the resource
restart oxmysql      # stops it and starts it again

ensure [my_category]   # with brackets: starts a GROUP of resources
                       # (a folder that groups several resources)

The ensure order (this is the critical part)#

FXServer loads resources in the SAME order they appear in the server.cfg. And many resources depend on others: they need their «base» already loaded to work. If you start an ESX resource before es_extended, that resource will ask for the ESX object and get nil, because it doesn't exist yet. Result: the classic attempt to index a nil value (global 'ESX') error.

# CORRECT ORDER: dependencies first, then whoever uses them

ensure oxmysql        # 1. database (everything else needs it)
ensure ox_lib         # 2. base library (UI, callbacks, utilities)
ensure es_extended    # 3. the framework (ESX) or qb-core

# 4. NOW yes: resources that depend on the above
ensure esx_menu_default
ensure esx_jobs
ensure my_jobs_resource

• oxmysql first: any resource that touches the database needs it available from startup.
• ox_lib after: tons of modern resources use its callback, menu and notification system.
• es_extended (ESX) or qb-core: the framework that exposes the main object jobs, money, inventory… all hang from.
• Your resources last: those that call exports['es_extended'] or ox_lib must ALWAYS go below them.

OneSync: what it is and why to enable it#

OneSync is FiveM's modern synchronization system. The key idea is server-authoritative: authority over what happens in the world (entities, positions, vehicles, NPCs) belongs to the server, not each client. That allows more players, entities created server-side and far less cheating, because the client stops being «the source of truth».

• Lets you exceed 32 players (set onesync on reaches up to 128; with onesync_population and Infinity mode, much more).
• Enables server-side entities: you can create vehicles and objects from server.lua that all players see consistently.
• Reduces desync and shuts the door on many cheats, because state is validated on the server.
• Remember: sv_maxclients > 32 will NOT work without OneSync enabled.

ACE permissions: who can do what#

Permissions in FiveM are managed with ACE (Access Control Entries). It works with two pieces: add_principal assigns a player (by their identifier) to a group, and add_ace grants a group (or player) permission over a command «object». That's how you define who is an administrator and which commands they can use.

# We give an identifier the group.admin group
add_principal identifier.fivem:1234567 group.admin
# (identifier.steam:..., identifier.license:..., identifier.discord:... also work)

# The admin group can use every command
add_ace group.admin command allow

# Specific permission: only the admin group can use /revive
add_ace group.admin command.revive allow

Secrets: never push your license to Git#

The sv_licenseKey, database passwords or any sensitive token must not live in the server.cfg you push to your repository. The standard practice is to move them into a separate secrets.cfg (added to .gitignore) and load it with exec.

# secrets.cfg  (this file goes in .gitignore, NEVER in the repository)
sv_licenseKey "your_keymaster_key_here"
set mysql_connection_string "mysql://user:password@localhost/crxative?charset=utf8mb4"
set discord_webhook "https://discord.com/api/webhooks/..."

# And in server.cfg, at the end:
#   exec secrets.cfg