Configuring server.cfg

server.cfg is the file FXServer reads at startup. It sets the ports, the name in the server list, the player cap, the licence key, and the order resources start in. This page covers the keys that actually change how the server behaves, and the two that hand over the server if you get them wrong.

Every line is a console command. Anything you can put in server.cfg you can also type into the live console, and the reverse is true, which is why testing a change in the console before writing it into the file is usually the fastest way to work.

Where the file lives and when it is read

The file sits in your server data directory, next to resources/. The server reads it once at startup, either because you passed it on the command line:

~/artifacts/run.sh +exec server.cfg

or because txAdmin was told which file to use during setup. Changes to the file do nothing until the server restarts, or until you run exec server.cfg again in the console, which re-runs the file over the running server.

The keys that matter

Endpoints

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

0.0.0.0 means every address on the machine. The two are set separately and both are needed: gameplay runs over UDP, and the join handshake, resource downloads, and the server list's view of you all run over TCP. Change the port and you must change both lines, then open the new port on the firewall. See Port rules.

Identity in the server list

sv_hostname "My server"
sets sv_projectName "My server"
sets sv_projectDesc "One line about what this server is"
sets tags "roleplay, economy, custom"
sets locale "en-US"

sv_hostname is the name players see. The sets lines are what the server list uses to describe and filter you, and they are published to anyone who asks the server for its info, signed in or not. Write them for a stranger reading a list, and do not put anything private in them.

The server icon is served through the same public endpoint. Set it through txAdmin and keep it at the small square PNG the server list expects; an oversized image inflates every reply the server sends to every scraper that asks.

Players and OneSync

sv_maxclients YOUR_PLAYER_CAP
set onesync on

sv_maxclients is the cap you want. It is not the cap you necessarily get. The effective ceiling depends on the OneSync mode and on the tier attached to your keymaster licence key, and the server clamps your number to whatever that allows.

onesync takes on, legacy, or off. Without OneSync you are held to the base game's network limit, which is low. on is the current mode and what almost every modern framework expects; scripts written against state bags and entity ownership need it.

To find out what you actually got, read the startup console: the server reports the OneSync mode and the client limit it settled on as it comes up. Your keymaster page shows the tier the key carries. Those two together are the real answer, and they beat any number written in a guide.

The licence key

sv_licenseKey "your-key-here"

Without a valid key the server starts, fails authentication, and exits. The key identifies one server, is tied to an IP address you set in keymaster, and can be revoked.

Steam web API key

set steam_webApiKey "your-steam-web-api-key"

This lets the server resolve a steam: identifier for players who launch through Steam. Frameworks, admin tools, and anticheats that ban on a Steam identifier need it; without it those players still connect, they have no Steam identifier attached, and the console says so at startup.

Get a key from https://steamcommunity.com/dev/apikey. It is tied to your own Steam account and it is a credential, so treat it like the licence key. If you do not use Steam identifiers, leave the key out.

RCON

rcon_password ""

RCON is a remote console protocol. It runs on the game's UDP port, its password travels in the clear, and there is no rate limiting worth the name in front of it. Anyone who guesses or intercepts the password gets the server's console.

set, setr, and sets

Three commands set a convar, and the difference is who can read it.

The rule that matters: setr and sets are public. A setr value is sent to every client that connects and can be read out of the game, and a sets value is handed to anyone who queries the server's info endpoint. Secrets go in set, and only in set.

Starting resources with ensure

ensure mapmanager
ensure chat
ensure spawnmanager
ensure sessionmanager
ensure basic-gamemode
ensure hardcap

ensure starts a resource, and restarts it if it is already running, which makes it safe to run twice. start only starts a stopped resource. The name is the resource's own folder name under resources/, not the [bracket] folder it is grouped in.

Order is literal. The file runs top to bottom, so anything a resource depends on must be ensured above it: the database resource before anything that queries the database, the framework core before the jobs and inventories built on it. A resource that starts too early usually fails with an error about a missing export or a nil object, which reads like a broken script and is actually a wrong line order.

When you add a resource while the server is running, the server does not know the folder exists yet. In the console:

refresh
ensure my-new-resource

Then add the ensure line to server.cfg so it survives the next restart. This is the step people forget, and the symptom is a resource that works until the server reboots.

Splitting the file with exec

exec permissions.cfg
exec secrets.cfg

exec reads another config file at that point in the sequence, so it behaves exactly as if you had pasted its contents there. Splitting is worth doing for two reasons: admin permissions and resource groups get long, and a separate secrets.cfg can be excluded from version control while the rest of your config stays in it.

Paths are resolved relative to the directory the server was started from, so keep the files with server.cfg and always start the server from the same directory. The WorkingDirectory line in the systemd unit in Installing a FiveM server on Linux is what pins that.

Order still applies. A file that sets convars a later ensure depends on has to be exec'd above that ensure.

A minimal server.cfg

Enough to bring up a working server, with nothing in it you have to delete later:

 # Endpoints
endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"
 
 # Identity
sv_hostname "My server"
sets sv_projectName "My server"
sets sv_projectDesc "One line about what this server is"
sets tags "default"
sets locale "en-US"
 
 # Players. Read the startup console for the cap you actually get.
sv_maxclients YOUR_PLAYER_CAP
set onesync on
 
 # Remote console stays off
rcon_password ""
 
 # Resources, in dependency order
ensure mapmanager
ensure chat
ensure spawnmanager
ensure sessionmanager
ensure basic-gamemode
ensure hardcap
 
 # Licence key. Keep this line out of version control.
sv_licenseKey "your-key-here"

Related