START HERE·MAKING THINGS HAPPEN·Verified June 2026 · Lua 5.4 · ox_lib 3.x
Learning with an AI assistant?
Copies this whole lesson - every step, code block, and the exact console errors - plus 2026 ground rules (no lua54 'yes', Cfx.re Portal, correct callback signatures) as a ready-to-paste mentor prompt.
Start Here · Making things happen

config.lua: settings you can safely change

Here is a secret about FiveM that nobody tells beginners: most of the time, you will not write a script from scratch. You will download one someone else built, open one file, change a few values, and restart. That one file is almost always called config.lua. It is where a script keeps the settings you are meant to change, kept separate from the code you should not. This is the last lesson of the module, and it is the one you will use the most.

You'll learn
What a config file is, why almost every script ships with one, what a Config table looks like, and the one rule that lets you customize any script without breaking it.
Time
~10 minutes
Difficulty
Beginner
You need
You finished "Exports: share code between resources". A test server you can restart helps, but you can follow the whole lesson by reading.
BEFORE YOU START

What a config file is

A config file is a plain Lua file, almost always named config.lua, that does one job: it defines a table of settings. The script then reads that table to decide how to behave. The settings live in one file, the actual logic lives in others, and you only ever touch the settings file.

Vocabulary

config
Short for configuration: the settings that control how a script behaves, like prices, locations, or which language to show. A config is the collection of choices the script author left open for you to make.
the Config table
A Lua table, usually written Config = {}, where each setting is stored under a name. The script reads values out of this table instead of having those values hard-baked into its code.
shared_script
A line in fxmanifest.lua that loads a file on both the client and the server. config.lua is loaded as a shared_script so both sides read the exact same settings.
key and value
Inside a table, every setting has two parts. The key is the name (like Price), the value is what it holds (like 500). You read a setting by asking the table for a key, and it hands back the value.

Think of a video game's settings menu. The game's code is sealed shut, you cannot rewrite it. But the settings menu lets you change the volume, the difficulty, the language. config.lua is that settings menu, except it is a text file instead of a screen. The author decided which knobs you get, put them all in one place, and the rest of the script reads your choices and acts on them.

Why configs exist

Imagine a script that runs a shop. The price of water is 500. If that number lived deep inside the script's logic, every server owner who wanted a different price would have to dig through code they do not understand, find the right line, and hope they did not break anything else on the way.

That is a terrible experience, so script authors do not do it. Instead they pull every value a normal user might want to change, the prices, the shop locations, the language, the menu key, into one file. You change behaviour by editing that file. You never touch the logic.

This split is the whole point. The risky, complicated code stays sealed in its own files. The safe, changeable values sit together in config.lua with a comment next to each one. Almost every script you download from a store or a community will have a config.lua (or a config/ folder). Learning to read it is the single most useful skill for running a server.

What a Config table looks like

Here is a small but realistic config. Read it top to bottom; it is just a table being filled in one line at a time.

lua
Config = {}
 
Config.Price = 500            -- how much the item costs
Config.UseTarget = true       -- true to open with the target system, false for a key
 
Config.Locations = {
    { label = 'Legion Square', x = 215.0, y = -810.0, z = 30.0 },
    { label = 'Sandy Shores',  x = 1960.0, y = 3740.0, z = 32.0 },
}

Line by line. Config = {} creates an empty table named Config. The {} means "an empty container". Each line after it drops one setting into that container under a name. Config.Price = 500 stores the number 500 under the key Price. Config.UseTarget = true stores the value true under the key UseTarget. Config.Locations stores a list of two places, each with a label and coordinates.

Elsewhere in the script, the code reads these values back. It never writes 500 directly. It writes Config.Price, which means "go look up the key Price in the Config table and use whatever value is there". So when a player buys the item, the logic does something like this:

lua
-- somewhere in the script's logic (you do NOT edit this):
chargePlayer(Config.Price)

Change Config.Price to 250 in config.lua, restart, and now the shop charges 250, without you ever opening the file that does the charging. That is the entire idea. The logic asks the table; you control the table.

Safe edits versus core logic

There is a clean line between what is safe to change and what is not. Learning where that line sits is what separates a server owner who can confidently customize scripts from one who breaks their server every weekend.

What is safe to edit

Inside config.lua, the values are yours. Changing them is exactly what the author intended:

  • Numbers, like a price or a cooldown: Config.Price = 250
  • Booleans, the bare words true or false: Config.UseTarget = false
  • Text in quotes, like a language or a label: Config.Locale = 'fr'
  • Coordinates inside the Config table, like a shop location

These are knobs. Turn them. Worst case you set a number too high and turn it back.

What is risky

Anything outside config.lua is the engine, and casual edits to the engine break things you cannot see:

  • The other files, usually server.lua, client.lua, or anything in a server/ or client/ folder. That is the logic.
  • The body of any function, the lines between function and end. That is how the script actually works.
  • Event names, the strings the script uses to talk between its own files. Change one and two halves of the script stop hearing each other.

If a value is not exposed in config.lua, the author did not mean for you to change it. Touching it is an advanced move, not a setup step.

Edit one

Let us do the real thing: open a script's config, change one value, and watch it take effect. We will use a price as the example, because it is the most common edit you will ever make.

Open the script's config.lua

You are looking at the settings, not the logic.

Open the resource folder of any script you have installed. Find config.lua (some scripts use a config/ folder with a file like config/main.lua). Open that file in VS Code. You should see a Config = {} table with settings under it. You are now in the cockpit, not the engine.

Change one value

Exactly one setting is different, nothing else.

Find a simple value to change. A price is perfect. Change only the number, and leave the rest of the line exactly as it was:

lua
Config.Price = 500     -- before
lua
Config.Price = 250     -- after

Change one thing at a time. If something breaks, you will know exactly which edit caused it.

Save the file

Your change is written to disk.

Save with Ctrl+S. Saving alone does not change the running server yet. The resource read the config once when it started, so it is still using the old value until you reload it. That is the next step.

Restart the resource

The server re-reads config.lua with your new value.

In the txAdmin Live Console, restart just this one resource so it reads the config again. Replace the_resource with the real folder name:

text
restart the_resource

A config edit only takes effect after a restart, because the resource reads config.lua once at start and then keeps using what it read.

See the change in game

The new value is now live.

Join the server and trigger whatever the value controls. Walk up to the shop and check the price. It now reads 250 instead of 500. You changed how the script behaves without opening a single line of its logic.

Common beginner mistakes

Almost every config break is one of these three. Each one comes from forgetting that config.lua is real Lua and follows Lua's rules exactly.

SymptomFix
'}' expected (to close '{' ...) near 'Sandy'You removed a comma or a brace and the table no longer closes. Every entry inside a { } needs a comma after it. Add the missing comma, or add back the } you deleted, on the line just above the one the error names.
The resource will not start at all after your editYou edited the wrong file. You changed a core .lua (like server.lua) instead of config.lua, or deleted a quote. Undo your last edit and confirm the resource starts. If it does, you know your edit was the cause, and you reapply it carefully inside config.lua only.
attempt to index a nil value (field 'SomeName')You renamed a key the code still looks for. If you change Config.Price to Config.Cost, the logic still asks for Config.Price and gets nothing. Never rename a key; only change the value to the right of the equals sign.
A script behaves wrong after you edited it. What is the safest single thing to recheck?

Recheck the one value you just changed in config.lua, and nothing else. Because you only touched one setting, the cause is almost certainly that exact edit: a missing comma after it, a quote you dropped, a key you accidentally renamed, or a number you set to something nonsensical. The fastest move is to undo your single edit, confirm the resource goes back to working, then reapply the change carefully. If you changed several things at once, that is the real lesson here: change one value at a time so there is only ever one suspect.

Try it yourself

What you can do now

  • Explain what config.lua is: a Lua file that defines a Config table of settings, loaded as a shared_script so both sides read the same values.
  • Say why configs exist: they let you change prices, locations, and language without touching the logic, which is why almost every downloaded script has one.
  • Read a Config table and look a value back up with Config.Name.
  • Tell a safe edit (a value inside config.lua) from a risky one (anything outside it: logic, function bodies, event names).
  • Run the loop: open config.lua, change one value, save, restart the resource, confirm the change.
  • Recover from a broken edit by rechecking and undoing the single value you just changed.

You can now make a resource do things, and just as importantly, you can take any script someone else built and bend it to your server without breaking it. That covers the core skills. Next you will meet the tools and libraries you will see in every server you ever open. The next module is "The ecosystem map", and it starts with "Natives: the game's built-in toolbox", the built-in functions the game gives you for free.