Installing and managing scripts
Most server owners spend more time installing other people's scripts than writing their own. The mechanics are simple: a script is a folder, you drop it in resources, you ensure it in server.cfg, you restart. The trouble is always the same handful of things: a wrong folder name, a missing dependency, or the wrong load order. This lesson makes installing boring and repeatable.
Build it
Unzip and check the folder
Unzip the download. Open the folder and confirm it contains an fxmanifest.lua (older scripts use __resource.lua). That file is what makes it a resource.
Rename the folder to something clean with no spaces, no version numbers, and no -main suffix from a GitHub zip. qs-vehiclekeys-main becomes qs-vehiclekeys. The folder name is the resource name you will ensure.
server-data/resources/qs-vehiclekeys/
fxmanifest.lua
...Install dependencies first
Open the script's README or fxmanifest.lua and read its dependencies. Most modern scripts need oxmysql, ox_lib, and a framework. oxmysql and ox_lib are Overextended community resources, not official Cfx.re built-ins, so you install them yourself like any other script. They must be installed and started before the script that needs them, or it errors on boot.
Organize with categories
Once you run more than a handful of scripts, group them with bracketed category folders so you can load a whole group at once:
resources/
[framework]
[jobs]
[vehicles]
[custom]Then one line loads everything inside a category:
ensure [vehicles]The brackets are a FiveM convention: a folder named [something] is a category, and ensure [something] starts every resource inside it. Keep categories ordered after their dependencies in server.cfg.
A worked example: getting the order right
Order is the single thing beginners get wrong most often, so here is one real install traced end to end. You are installing ox_inventory, the Overextended community inventory. Read its README and you find this dependency chain: it needs oxmysql for the database, ox_lib for shared functions, and a framework (es_extended or qb-core) to know who the player is. Each of those is itself a resource you ensure, and each must already be running before the thing that calls it loads.
The rule is one sentence: a resource must be ensured after everything it depends on. Draw the chain and the load order falls out of it. Arrows point from a resource to what it needs:
ox_inventory # the script you actually want
|
+-- needs --> es_extended (the framework: identifies the player)
| |
| +-- needs --> oxmysql (database layer)
| +-- needs --> ox_lib (shared library)
|
+-- needs --> oxmysql (writes inventory rows to the DB)
+-- needs --> ox_lib (UI + helper functions)Everything at the bottom of the arrows has to start first. Flatten that tree from the leaves upward and you get the exact ensure order for server.cfg:
# server.cfg - load order is top to bottom.
# Leaves of the dependency tree first, the script that needs them last.
ensure oxmysql # 1. database layer, depends on nothing else here
ensure ox_lib # 2. shared library, depends on nothing else here
ensure es_extended # 3. framework, needs oxmysql + ox_lib (both already up)
ensure ox_inventory # 4. the script, needs all three above (all already up)If you flip two lines, the console tells you immediately. Put ensure ox_inventory above ensure oxmysql and on boot you get a red line like attempt to index a nil value or Failed to load resource ox_inventory: it depends on oxmysql, because ox_inventory reached for the database exports before oxmysql had registered them.
ox_inventory failed on boot with attempt to index a nil value, but the folder name and spelling are correct. What is the most likely cause?
A dependency loads too late, or not at all. ox_inventory calls into oxmysql and ox_lib the instant it starts, so if either of them is ensured below ox_inventory in server.cfg (or missing entirely), those exports do not exist yet and indexing them returns nil. Fix the order: ensure oxmysql and ensure ox_lib must sit above ensure ox_inventory. The same logic applies to the framework. Reorder the lines, then restart ox_inventory.
The fxmanifest itself can declare this so you do not have to remember it. A script that lists its needs uses the dependencies key (note the plural and the table, not a single string):
-- fxmanifest.lua inside ox_inventory
dependencies {
'oxmysql',
'ox_lib'
}When a manifest declares dependencies, FiveM refuses to start the resource until those resources are running, and the error names exactly which one is missing. That turns a silent nil into a readable message. It still does not reorder server.cfg for you, so the top-to-bottom rule above is what actually controls startup.
If something went wrong
| Symptom | Fix |
|---|---|
Resource not found / could not find resource | The folder name and the ensure line do not match. Check spelling and remove any -main or version suffix from the folder name. |
attempt to index a nil value, or a missing export/event | A dependency is missing or loads too late. Install and ensure oxmysql, ox_lib, and the framework BEFORE this script in server.cfg. |
Server crash or console warning on start | A syntax error in a file you edited (often the config): check commas, quotes, and parentheses. Revert your edit and re-apply it carefully. |
Escrow / license key error on a paid script | Escrowed assets must be tied to your server's Cfx.re key. Link the purchase to this server's key in your account, then restart. |
Two scripts fight or one stops working | A conflict: two resources doing the same job (two inventories, two target systems). Run one, not both. |
For the full list of red console lines with the exact wording and the precise fix for each, see the FiveM error catalog.
What you can do now
- Unzip a script, confirm it has an fxmanifest.lua, and give the folder a clean name.
- Read a script's dependencies and install them first.
- Ensure dependencies, framework, then the script in that order in server.cfg.
- Use refresh then ensure to add a resource without a full restart.
- Group resources with bracketed [category] folders and fix the four common install failures.