The FiveM server.cfg, line by line

A FiveM server.cfg is a list of console commands run at boot. That is all it is, and understanding that explains most of its oddities: there is no schema, order matters, and a typo does not raise an error. It just runs a command that does nothing.

Cfx.re's server setup documentation covers getting one running. What follows is what the file is doing once it does.

The keys that must never be in a public repo

sv_licenseKey is your server's identity with Cfx.re. Anybody who has it can run a server as you, and getting it revoked is your problem to sort out afterwards.

steam_webApiKey is worse if you use it, because it is tied to your Steam account rather than to the server.

Both belong outside the file you version-control. The usual arrangement is a second config holding only secrets, pulled in with exec, and excluded from git. People discover this rule by pushing a repo, and the window between pushing and noticing is the whole vulnerability.

sv_maxclients, and the number people choose wrong

This caps concurrent players. The instinct is to set it high in case you get popular, and it is the wrong instinct for the same reason it is wrong in Minecraft: an empty slot costs nothing, but it is visible.

Thirty-two players in a 128-slot server reads as a server that used to be busy. The same thirty-two in a 48-slot server reads as a server filling up. Nothing changed but the denominator, and the denominator is most of what a stranger scrolling a list of roleplay servers is judging.

onesync, which is not a performance setting

OneSync changes how entity state is synchronised and is what allows player counts above the old 32-slot ceiling. It is a capability, not an optimisation: turning it on does not make a struggling server faster, and turning it off does not fix desync.

If your server stutters at 40 players, OneSync is the thing making 40 players possible, not the thing making them laggy. The cause is nearly always in resources, and it belongs with the rest of the lag diagnosis.

ensure, start and the order problem

ensure starts a resource and restarts it if it is already running. start only starts it. Most of a modern server.cfg is a list of ensure lines, and their order is the load order.

This is where framework servers break. A resource that depends on your core framework must be ensured after it. ESX and QBCore both publish an expected order, and the difference between the two is one of the more consequential early decisions: the comparison is its own subject and worth settling before the resource list grows past twenty lines.

The symptom of a wrong order is a resource that errors on boot about a function that does not exist. The function exists. It just did not exist yet when that line ran.

The commands you will actually use

The server commands reference lists the rest. The ones worth knowing by heart are refresh after adding a resource to the folder, restart <resource> for a single one, and stop/start when restart is not enough because the resource left state behind.

quit shuts the server down. On a supervised setup that means a restart, which is usually what you wanted, and if it is not, that is a sign your process manager and your intent disagree.

What the file cannot do

It cannot hide your endpoint. endpoint_add_tcp and endpoint_add_udp are what your server listens on, and a reverse proxy in front of FiveM is a different arrangement with its own documented setup rather than a line in this file.

It also cannot make your server appear in the server list if the ports are not actually reachable. A config that looks perfect and a firewall that drops UDP produce a server that runs, logs nothing unusual, and is invisible to everybody, which is the same class of problem as any other connection that quietly fails.

It cannot validate anything you wrote. Every line is a command handed to the server in order, so a misspelled convar is accepted, stored, and read back by nothing. The resource that expected it falls through to its own default and behaves almost correctly, which is the version of this problem that takes an evening to find.

Read the file top to bottom once. It is about sixty lines and you will be editing it for as long as the server exists.