server.cfg ensure order: the right resource start order for FiveM

Half your scripts throw nil errors on startup, but they work when you restart them by hand. That pattern usually means the resources start in the wrong order. This guide gives you an order that works for ESX, QBCore and QBox, and explains ensure vs start, bracket folders and duplicates.

#Why order matters

Resources start in the order of the lines in server.cfg. A script that reads the framework when it loads gets nil if the framework has not started yet. The same applies to the database layer and to libraries like ox_lib. You solve it by putting the base layers on top:

1. The database: oxmysql
2. The library: ox_lib
3. The framework: es_extended, qb-core or qbx_core
4. The inventory
5. Everything else

#An order that works

For QBCore:

ensure oxmysql
ensure ox_lib
ensure qb-core
ensure ox_inventory
ensure [qb]

ensure [standalone]
ensure [mic]

For QBox:

ensure oxmysql
ensure ox_lib
ensure qbx_core
ensure ox_inventory
ensure [qbx]
ensure [standalone]

For ESX:

ensure oxmysql
ensure ox_lib
ensure es_extended
ensure ox_inventory
ensure [esx]
ensure [standalone]

Adjust the category names to your own folders. If you use qb-inventory or another inventory instead of ox_inventory, put that one at the same position, right after the framework (or before it, if its own documentation says so).

Tip: keep resources you ensure by name (oxmysql, ox_lib, the framework, the inventory) in folders you do not also ensure as a bracket. Otherwise they are ensured twice, see Duplicates below. Many setups put them in a [core] folder that is never ensured as a whole.

Tip: your txAdmin recipe may have written its own order. Keep what works and only add your scripts below the base layers, instead of rewriting the file.

#ensure vs start

start my_script
ensure my_script

• start starts a resource if it is stopped.
• ensure starts it if it is stopped, and restarts it if it is already running.

On a normal boot, nothing is running, so they behave alike. The difference shows when you run them in the live console: ensure my_script is the one you want to reload a script you just edited. In server.cfg, use ensure everywhere so you only have to remember one word. For the other direction, stop my_script stops it, and refresh makes the server rescan the resources folder for new or changed manifests.

#Bracket folders as categories

A folder whose name is in brackets is not a resource. It is a category, and FiveM looks inside it:

resources/
  [core]/
    ox_lib/
    oxmysql/
    qb-core/
  [qb]/
    qb-garages/
  [standalone]/
    my_other_script/
  [mic]/
    my_script/

ensure [qb] starts every resource inside [qb]. That keeps server.cfg short, and it is how most framework packs ship. Two things to know:

• Order inside a bracket folder is not something to rely on. If qb-garages needs qb-core, ensure qb-core on its own line above ensure [qb], or declare dependency 'qb-core' in the manifest. The core must not wait on luck.
• A resource cannot be nested inside another resource. Brackets are for grouping only. If you put a script folder inside another script's folder, FiveM will not find it. See Couldn't start resource.

A resource inside a bracket folder is still found by its own name, so ensure ox_lib works even though the folder is [core]/ox_lib.

#Dependencies in the manifest

Order lines in server.cfg are one tool. A dependency line in a script's manifest is the other, and it is more reliable:

dependency 'ox_lib'
dependency 'oxmysql'

FiveM then checks that those resources exist and starts them first. If one is missing, you get a clear message instead of a nil error: Could not find dependency X for resource Y. Use both: a good order in the file, and dependencies in the manifests you control.

#Duplicates

Two things go wrong with duplicates:

• The same ensure twice. Ensuring a resource twice in server.cfg starts it, and then restarts it right away. It wastes boot time and can trigger duplicate database writes or events at start. Remove the second line. Check that a bracket folder does not already include a resource you also ensure by name.
• Two folders with the same resource name. If you have resources/[old]/my_script and resources/[mic]/my_script, only one is used, and which one is not something you control. Delete or rename one, and always delete the old version of a script before installing a new one.

When a fix you made seems to have no effect, check that you did not edit the copy that is not running.

#Find the culprit when order is wrong

Start the server, then read the console from the top. The first resource that prints an error is the cause, and everything after it can be fallout. Typical examples:

• oxmysql prints a database error: nothing that uses SQL will work.
• ox_lib fails: every script with @ox_lib/init.lua breaks (ox_lib fix).
• The framework fails: every script that asks it for a player object gets nil.

Fix the first failure and restart.

#Checklist