Dependencies and load order
Here is a secret that saves beginners weeks of pain: most of the scripts that "just will not work" are not broken. They are simply loading in the wrong order. The code is fine. It just ran before the thing it depends on existed. By the end of this lesson you will know what a dependency is, why order decides everything, and exactly where to put each line so the error never happens to you.
What a dependency is
A dependency is a resource your resource needs in order to work. Your script does not live alone on the server. It leans on other resources for things it does not want to build itself. The most common one is ox_lib, a free shared library that gives you ready-made tools like menus, notifications, and database helpers. Instead of writing all of that from scratch, your script borrows it from ox_lib. That makes ox_lib a dependency of your script.
The catch is the whole point of this lesson: if a dependency is missing, or if it loads after your code instead of before, your code breaks. It reaches for a tool that is not there yet, and the server throws an error. Nothing is wrong with what you wrote. The thing it needed just was not ready in time.
Vocabulary
- dependency
- A resource your resource needs in order to run. If it is missing, your script errors. Example: ox_lib is a dependency of almost every modern FiveM script.
- load order
- The sequence in which the server starts resources. The server reads server.cfg top to bottom and starts resources in that order. Dependencies must come first.
- ensure
- The server.cfg line that starts a resource (and restarts it if it was already running). One ensure line per resource. Their order is the load order.
- dependency directive
- A line inside a resource's fxmanifest.lua that names what it needs: dependency 'ox_lib' for one, or a dependencies { ... } block for several. It is a declaration, not a command to start anything.
Why order matters
Think of it like building furniture. You cannot screw a shelf onto a frame that has not been assembled yet. The frame has to exist first. Code works the same way. A resource cannot use ox_lib's functions if ox_lib has not started yet, because those functions simply do not exist in memory until ox_lib finishes loading.
The reason this trips people up is invisible: the server starts resources in the order it reads them. It works through server.cfg from the top line down, starting one resource, then the next, then the next. So whichever resource you list first starts first. If you list your script above ox_lib, your script starts first, looks for ox_lib's tools, finds nothing, and errors. List ox_lib first and the tools are ready and waiting by the time your script asks for them.
"Starts" is doing real work in that sentence. Starting a resource means the server runs its code into memory: it loads the files the manifest names, registers any functions the resource shares, and makes its tools available to everyone else. Until that finishes, the resource may as well not exist. So "loads too late" really means "your code asked for a tool during the brief window before the resource that provides it had finished starting."
Declaring dependencies
There are two separate jobs here, and beginners often confuse them. One is telling FiveM what your script needs (you do that in the manifest). The other is controlling the actual start order (you do that in server.cfg). You usually want both.
In fxmanifest.lua
Inside your resource's fxmanifest.lua, you declare what it depends on. For a single dependency, use the dependency directive:
fx_version 'cerulean'
game 'gta5'
dependency 'ox_lib'
server_script 'server.lua'For more than one, use the plural dependencies block with a list:
fx_version 'cerulean'
game 'gta5'
dependencies {
'ox_lib',
'oxmysql'
}
server_script 'server.lua'These lines are a declaration, not a start command. They tell FiveM "this resource is meant to run alongside ox_lib and oxmysql." If a declared dependency is missing or not started, FiveM warns you in the console instead of letting your script fail silently. That warning is a gift. It points straight at the problem.
Controlling order in server.cfg
The manifest declares the relationship. server.cfg enforces the order. You enforce it by listing each library and framework with ensure above the scripts that use them:
ensure oxmysql
ensure ox_lib
ensure my_shopThe server reads that top to bottom: it starts oxmysql, then ox_lib, then my_shop. By the time my_shop starts, both of its dependencies are already loaded and their tools exist. That is the entire mechanism. Move my_shop to the top of that list and it would start first, reach for tools that are not loaded yet, and error.
The pattern to follow
Once you see it, the rule is simple and it never changes. Libraries and frameworks load first. The scripts that depend on them load after. In practice that means a stack like this, from the top of your ensure block downward: shared libraries (ox_lib), the database bridge (oxmysql), the framework (such as ESX, QBCore, or the maintained Qbox), and only then the scripts you actually installed to add features.
Common beginner mistakes
These three errors all come from the same root cause: something your code needed was not loaded yet. Learn to recognise them and you will fix in seconds what used to cost you an evening.
| Symptom | Fix |
|---|---|
No such export ... in resource ox_lib | Your script asked ox_lib for a tool, but ox_lib had not finished starting yet. Move ensure ox_lib above ensure your_script in server.cfg, save, and restart. |
attempt to index a nil value (global 'lib') | The global lib table that ox_lib creates does not exist yet, so lib is nil. ox_lib is loading after your script. Ensure ox_lib above your script and the lib table will be ready when your code runs. |
No console warning, but the script silently fails | You forgot the dependency line in fxmanifest.lua, so FiveM never warned you the dependency was missing or out of order. Add dependency 'ox_lib' (or a dependencies block) to the manifest so FiveM flags it for you next time. |
Your script uses ox_lib but errors that lib is nil. What is the likely cause?
ox_lib is loading after your script instead of before it. The global lib table is created when ox_lib starts, so until ox_lib has finished loading, lib does not exist and reads as nil. Your script ran first and reached for lib. while it was still empty. The fix is order: move ensure ox_lib above ensure your_script in server.cfg, save, and restart. It is almost never a problem with your code itself.
Try it yourself
What you can do now
- Explain what a dependency is: a resource your resource needs in order to run.
- Say why load order matters: the server starts resources top to bottom, and a resource cannot use a library that has not started yet.
- Declare dependencies in fxmanifest.lua with dependency 'ox_lib' or a dependencies { ... } block so FiveM warns you when one is missing.
- Order your ensure block in server.cfg so libraries and frameworks come first and the scripts that use them come last.
- Recognise the three classic load-order errors and fix them by moving one line, not by rewriting your code.
You now understand the most common reason a perfectly good script refuses to run. Next you will learn a rule that protects your server from a different kind of failure, one caused not by order but by trust: Security: never trust the client. It is the single most important habit a FiveM developer can build, and it starts in the next lesson.