Skip to main content
TRACK A·INSTALL YOUR SERVER·Verified June 2026 · Lua 5.4 · ox_lib 3.x
Learning with an AI assistant?
Copies this lesson plus 2026 ground rules (no lua54 'yes', Cfx.re Portal, correct callback signatures) as a ready-to-paste mentor prompt.
Module 07 · Bonus

Convars: set, setr, and sets in server.cfg

A convar (configuration variable) is a key/value pair you set in server.cfg. Scripts read it to decide how they behave: a database connection string, a Tebex secret, a debug flag, a starting balance. You tune these without editing any script. One thing trips up everyone, and it is a security issue, not a cosmetic one: the prefix you use to declare a convar decides whether the value is sent to every connected player. Pick the wrong prefix on a secret and you have leaked it. This lesson makes that difference clear.

You'll learn
What a convar is, the three prefixes (set, setr, sets), exactly who can read each, and why a secret must always be set and never setr.
Time
~8 minutes
Why now
Scripts and frameworks tell you to add convar lines to server.cfg. This lesson makes those lines make sense so you never leak a secret by using the wrong prefix.
BEFORE YOU START

The three prefixes, and who can read each

When a script's install notes tell you to add a convar, they write it as one of three commands. They look almost identical. They behave completely differently, and the difference is who receives the value.

  • set name value declares a server-only convar. Only the server reads it. Clients never receive it. Use this for anything a player must never see: a database connection string, an API key, a Tebex secret, an owner ID.
  • setr name value declares a replicated convar. The r is for replicated. The server reads it, and the value is also pushed to every connected client. Use this only for config that is safe for players to know and that the client genuinely needs, such as a debug flag that turns on extra on-screen logging.
  • sets name value declares a server-info convar. It is exposed in the server's public info and the server browser, for example sets tags "roleplay, economy". Treat every sets value as fully public. Never place a secret in it.

That is the whole rule. set stays on the server. setr rides along to every client. sets is broadcast to the public server browser.

text
set    mysql_connection_string "..."   # server only, safe for secrets
setr   myscript_debug true             # also sent to every client
sets   tags "roleplay, economy"        # public, shown in the server browser
A script's README shows setr myscript_apikey YOUR_KEY. Do you paste your real key there?

No. setr replicates the value to every connected player, so your API key would be sent to every client and could be extracted. That line is wrong for a secret. Use set myscript_apikey YOUR_KEY instead, so the value stays on the server. If the script genuinely cannot read the key unless it is replicated, that is a red flag worth raising with the author, not a reason to leak the key.

Editing server.cfg does not apply the change

One model to lock in. Editing the server.cfg file does not execute the changed line on a running server. A single-resource restart does not re-read server.cfg either. To apply a new or changed convar, do a full server restart (or deliberately re-run the cfg with exec). In txAdmin, that is the dashboard Restart action, not a single-resource restart.

You can also set a convar live from the server console, which takes effect immediately with no restart:

text
setr myscript_debug false

The server.cfg line is the value the convar starts at on the next boot. A live set or setr from the console overrides it until the next restart.

If something went wrong

SymptomFix
A secret you set with setr showed up on a clientsetr replicates to every client. Change it to a plain set, then rotate the secret (revoke the key or webhook and issue a new one), because the old value may already have reached players.
A convar change did not take effectEditing server.cfg does not execute it. Do a full server restart, or exec the cfg. A single-resource restart does not re-read server.cfg.
A convar value keeps reverting no matter what you setA resource is calling SetConvar() at runtime and overwriting the server.cfg value. server.cfg sets the initial value, but code that runs after startup wins. Find and fix the resource that re-sets it.
sv_licenseKey or another engine convar will not change at runtimeEngine-protected convars can only be set in server.cfg at startup; they cannot be changed live. Edit server.cfg and fully restart.
Your license key or secret ended up in a public GitHub repoYou committed server.cfg with the secret in it. Rotate it immediately (revoke the key at portal.cfx.re, or rotate the webhook or database password), then add server.cfg to .gitignore so it never commits again.

What you can do now

  • Name the three convar prefixes and say who reads each: set is server-only, setr replicates to every client, sets is broadcast to the public server browser.
  • Always declare a secret as set, never setr, because setr sends the value to every connected player.
  • Explain that editing server.cfg does not apply a convar; a full server restart or exec is required, while a live set in the server console applies immediately.
PREVIOUS
Endpoints, ports, and going public