server.cfg explained: the lines that actually matter
Open the folder of any FiveM server and you'll always find it: server.cfg. It's the first file FXServer reads on startup, and it decides what your server is called, how many players can join at once and which resources run. Yet many new admins treat it like a magic file you're better off not touching. A shame, because anyone who understands server.cfg can solve half of all startup problems on their own. In this article we walk through the lines that actually matter, and the lines that don't belong in there at all.
How FXServer reads your server.cfg
server.cfg isn't programming code, it's a list of commands. FXServer reads the file from top to bottom and executes every line one by one. That sounds trivial, but it instantly explains why order matters: a script that depends on a framework has to be started after that framework. Lines starting with # are comments and get skipped. Use them generously to divide your file into blocks, because after a year of tinkering an unstructured config is a maze.
If you run with txAdmin, as is standard on the FiveM servers from MC-Node, you point it at a server.cfg during setup and can edit it afterwards through the file manager or SFTP. Important to remember: changes to convars only take effect after a full server restart. Just reloading a resource isn't enough.
The convars that actually matter
Convars are your server's settings. This is a healthy baseline:
# server list and presentation
sv_hostname "My RP City | English | Whitelist"
sets sv_projectName "My RP City"
sets sv_projectDesc "English roleplay with custom scripts"
sets tags "roleplay, english, whitelist"
sets locale "en-US"
# technical
sv_maxclients 48
set onesync onsv_hostnameis the name in the server list;sv_projectNameandsv_projectDescfill in the server card around it. Be specific: "English RP | Whitelist | 18+" attracts exactly the right players, "Server123" attracts nobody.sets tagsandsets localedetermine how people find you. Players genuinely filter the server list by language and tags, so setlocaleto the language you're targeting, likeen-USfor an English-speaking community. If your server doesn't show up in the list at all, the cause is usually a licence or config problem.sv_maxclientsis the maximum number of concurrent players; the default is 48. Don't crank it up for show, pick something that fits your plan and your community.set onesync onenables OneSync, FXServer's modern synchronisation model. For more than 48 slots OneSync is mandatory anyway, and extra conditions from Cfx.re apply. The knowledge base explains how to enable OneSync.
Also mind the difference between set, setr and sets. With set a value stays on the server, setr shares it with your players' game and sets makes it publicly visible in the server list. Anything you set with sets can be read by everyone, so never put anything in there that should stay private.
And sv_licenseKey? Formally it belongs in this list too, but if you use txAdmin you enter your licence key during the setup wizard and txAdmin manages it for you from then on. You don't need to put it in server.cfg yourself, and that's the safest place for it anyway.
ensure: your resources in the right order
The bulk of an average server.cfg consists of ensure lines. ensure starts a resource, and restarts it if it's already running. You'll occasionally see the older start; it works, but ensure is the more robust habit. The rule of thumb for the order: foundation first, then whatever builds on top of it.
# foundation: database and framework
ensure oxmysql
ensure es_extended
# only then the scripts that depend on them
ensure esx_garage
ensure my_jobscriptStart a job script before your framework is running and the script will crash or wait forever, leaving you with a console full of red errors. Some resources declare their dependencies neatly in their fxmanifest.lua, but don't rely on that blindly: a logical order in server.cfg prevents nine out of ten startup problems.
What doesn't belong in your server.cfg
What you leave out is at least as important:
- Passwords and secret keys. Think of a database password in a connection string or API keys for external services. The problem: server.cfg is exactly the file people copy and share when they ask for help somewhere. Only share your config with all secrets cut out, and treat the file as if it will go public one day.
rcon_password, unless you really use rcon. With txAdmin you rarely need rcon, and a weak rcon password is an open back door into your console. Better to leave the line out entirely.- Dead lines. Ensures for resources you removed ages ago, commented-out experiments from months back: clean them up. Every line you no longer understand is future confusion.
Common mistakes
- Duplicate ensures. Starting the same resource twice happens faster than you'd think, especially if you pasted an example config on top of your own lines. It usually doesn't break anything, but your console complains and debugging becomes needlessly confusing.
- An ensure without a resource. You delete a resource folder but forget the line. Result: a "Couldn't find resource" message on every start. Harmless, but it clutters your console so you miss real errors.
- Names that are almost right. The ensure name has to match the resource's folder name exactly, including capitalisation and hyphens. Spaces in folder names are asking for trouble anyway.
- Forgetting to restart. You change
sv_maxclients, see nothing happen and keep searching, while the change simply hasn't been loaded yet.
For nearly all of these mistakes the same applies: txAdmin's live console literally tells you what's going wrong. Read through the first messages on every start; it takes thirty seconds and saves you hours of guesswork.
Honestly: it doesn't have to be perfect
A server.cfg doesn't need to be a work of art. A good config is a file with clear blocks, a logical ensure order and no secrets in it. Start small, add one resource at a time and you'll always know where a problem came from. As your server grows, your config grows with it, and that's when a tidy foundation pays off twice over.