Most FiveM owners inherit their fivem server.cfg from a template, a YouTube tutorial, or a friend’s zip file, and then never open it again until something breaks at 2 a.m. That file is the control panel for your entire server — it decides who connects, what loads, in what order, and what secrets you accidentally hand to every client. Reading it line by line is the single highest-leverage hour you’ll spend, because nearly every “random” crash and “unfixable” exploit traces back to something quietly wrong in this one file.

The anatomy: the lines every config has

Strip away the noise and a working config has a handful of load-bearing lines. endpoint_add_tcp "0.0.0.0:30120" and the matching endpoint_add_udp bind the ports players actually connect through — get these wrong and nobody connects, full stop. sv_maxclients sets your slot cap (remember anything above 32 requires OneSync). sv_hostname is the name in the server browser, and sv_projectName / sv_projectDesc are what txAdmin and the newer server-list cards display. None of these are exciting, but a typo in the endpoint line is the most common “my server won’t start” cause there is.

Ensure, start, and why order is load-bearing

FiveM loads resources top to bottom, exactly as written. ensure is the modern keyword (start if stopped, restart cleanly if already running); start still works but ensure is what you want. The order is not cosmetic — it is a dependency chain.

  • Dependencies first. oxmysql before anything that touches the database. ox_lib before any resource that requires it. A script that errors on boot with “oxmysql was not found” almost always loaded before the database wrapper did.
  • Framework before its children. On a qb-core build, qb-core ensures first, then qb-target/qb-menu/shared dependencies, then jobs, shops, and gameplay resources. Get the framework boot order wrong and half your scripts silently fail to register exports — the load-order context written up on qb-tebex.io exists because this trips up nearly everyone running their first qb server.
  • Maps and streamed assets can usually go late, but anything other scripts depend on for spawn points or props should be up before them.

The OneSync line and population convars

One line unlocks more than 32 players: set onesync on. For anything above ~48 concurrent you want OneSync Infinity behavior, not the legacy mode, because it brings entity culling and the population routing that keeps a full city from syncing everything to everyone. Pair it with sensible sv_endpointPrivacy true so player IPs aren’t exposed, and know that flipping OneSync on is also what enables server-side entity creation that a lot of modern scripts assume exists.

Recommended FiveM scripts for your server


Convars and secrets: set vs setr vs sets

This is the section that quietly leaks your data. The three setter keywords are not interchangeable, and the difference is about who can read the value.

  • set — server-side only. The default. Use it for anything sensitive.
  • setr — replicated to every connected client. Convenient for values your client scripts genuinely need, dangerous if you ever put a secret here. Never setr an API key.
  • sets — server-info, shown in the public server browser metadata. Purely for display strings like a Discord link.

Your real secrets — sv_licenseKey (your CFX key), steam_webApiKey, database connection strings, webhook URLs — must use plain set, and ideally live in a separate secrets.cfg that you exec and keep out of version control. txAdmin and the artifact deployer generate a lot of this scaffolding for you, and the breakdown of those auto-generated configs on cfxre-tebex.io is worth reading before you start hand-editing what a tool wrote.

Security: the lines that get servers wiped

A misconfigured config is how most “we got hacked” stories actually start. Walk these deliberately.

  • rcon_password — the single most dangerous line in the file. If it’s blank, weak, or replicated, anyone can take full remote control of your server. Set a long random value, or leave it unset entirely if you don’t use RCON. Never setr it.
  • ACE permissions. Build admin access with add_ace and add_principal tied to identifiers (license, Discord), not by handing out RCON. Example: add_principal identifier.license:xxxx group.admin then add_ace group.admin command allow. Granular ACE beats a shared password every time.
  • sv_scriptHookAllowed — keep this false on any serious RP server. Allowing ScriptHook is an open invitation for menu/mod-menu cheaters.
  • sv_endpointPrivacy true so the server doesn’t leak player IP addresses to one another.

Performance convars and what never to copy blindly

A few convars genuinely affect feel and stability. sv_enforceGameBuild pins you to a specific GTA build (for example 2802 or 3258) so a Rockstar update doesn’t desync your players or break a DLC-dependent script overnight — pick one deliberately rather than chasing the newest. onesync_distanceCullVehicles and onesync_distanceCull help large servers shed sync load by not streaming distant entities, but they’re trade-offs, not free wins: cull too aggressively and players see cars pop in late. sv_requestParanoia and a sensible onesync_population setting round out the large-server toggles. The deeper optimization-convar tuning collected on 0resmon-tebex.io is where to go once your config is clean and you’re chasing the last few milliseconds.

Upgrade your server — shop our FiveM scripts


Exec, includes, and keeping the file maintainable

A 600-line monolithic config is where mistakes hide. Use exec to split it into readable pieces: exec server-secrets.cfg for keys and passwords (gitignored), exec permissions.cfg for all your add_ace/add_principal lines, and the main file for endpoints, convars, and the resource list. The order exec lines run still matters — secrets and permissions before the resources that need them. This structure also means you can hand a teammate the main config to edit ensure-order without ever exposing your license key, and you can diff changes cleanly instead of scrolling a wall of text hunting for what moved.

The rule that ends most config disasters: never paste a line you can’t explain. Tutorial configs are riddled with someone else’s license key, a leftover dev rcon_password, replicated values that should be private, and resources ensured in an order that only worked on the author’s machine. Open the file, read every line, delete what you don’t use, and understand what each cvar does before it ships. Your fivem server.cfg is the one file where five minutes of reading prevents five hours of firefighting.