Managing fivem server dependencies is one of the most common sources of crashes, broken scripts, and silent failures on new and growing servers. Get the load order wrong, skip a required library, or misconfigure oxmysql, and you’ll spend hours chasing errors that have nothing to do with your actual scripts. This guide cuts straight to what you need to know.

What Are Server Dependencies and Why They Matter

A dependency is any resource that must be running before another resource can function. In FiveM, this is enforced through the ensure statements in your server.cfg and the dependency and server_script declarations inside each resource’s fxmanifest.lua. If a script lists ox_lib as a dependency but ox_lib isn’t started yet when the server boots, every function call from that script into ox_lib will return nil or throw an error. The server doesn’t crash immediately — it just misbehaves in ways that are difficult to trace.

ox_lib: The Foundation Most Scripts Expect

ox_lib is a shared utility library providing caching, math helpers, UI components (context menus, input dialogs, notifications), and network callbacks used by hundreds of community scripts. When a script declares @ox_lib/init.lua in its fxmanifest.lua, it expects ox_lib to already be loaded at startup. Always ensure ox_lib directly after your core framework — never after the scripts that depend on it. Don’t run multiple versions simultaneously; child resources import whichever version loaded first. After updating ox_lib, restart the full dependency chain — hot-reloading ox_lib alone leaves dependent scripts holding stale references.

oxmysql: Async Database Queries Done Right

oxmysql replaces the older mysql-async library with a promise-based async API. Because it opens a connection pool at startup, it must be the very first resource ensured — before your framework, before ox_lib, before everything else. Set mysql_connection_string in server.cfg before the first ensure line. Know the difference between the three main exports: execute (fire and forget), single (one row), and scalar (one value) — mixing these up is one of the most common sources of nil errors. Add set mysql_debug true during development to log slow queries, and remove it in production.

Load Order in server.cfg: The Exact Sequence

The order of ensure lines in server.cfg is your explicit load order. FiveM does not auto-resolve dependency trees at runtime — it follows your list. A working order for most setups: oxmysql first, ox_lib second, your core framework third, framework bridges immediately after, standalone utility resources next, then gameplay scripts (jobs, vehicles, housing, inventory) last.

If you’re getting “attempt to index a nil value” errors in a script that worked before, the first thing to check is whether the resources it depends on are higher in the ensure list. This single mistake accounts for the majority of dependency-related bug reports.

fxmanifest.lua Dependency Declarations

Every resource has an fxmanifest.lua that declares what it needs. Two fields matter for dependencies:

• dependency — lists other resource names that must be running. FiveM will refuse to start the resource if a listed dependency isn’t already running, and will print an error to the console. This is your safety net.
• server_script ‘@ox_lib/init.lua’ — this imports ox_lib’s server-side module directly into the resource’s Lua environment. If ox_lib isn’t loaded, this line causes a fatal resource start error.

When writing or debugging a custom script, always verify your manifest declarations match what the code actually calls. Removing a dependency line doesn’t remove the code that uses it — it just removes the guard that tells you when it’s missing.

The production-ready FiveM systems at store-tebex.io are built with clean manifests and correct load-order documentation — examining how well-engineered scripts declare their dependencies is one of the fastest ways to learn the pattern correctly.

Common Dependency Mistakes and How to Fix Them

• Circular dependencies: Script A depends on Script B, Script B depends on Script A. Neither can start. Break the cycle by extracting the shared logic into a third resource with no dependencies of its own.
• Missing exports at boot time: A resource tries to call an export in a top-level (non-event) context before the exporting resource has finished initialising. Move the call inside an event handler or add a startup check with Wait() polling.
• Ensure order inconsistencies across environments: Treat server.cfg as code — version-control it and keep development and production identical.
• Reinstalling a resource without restarting dependents: If you update ox_lib or oxmysql mid-session, all resources that imported them at boot now hold stale function references. Restart the full dependency chain.
• Framework bridges loaded before the framework: Bridges must come after the framework itself in the ensure list, never before. This trips up almost every first-time server owner.

Testing and Verifying Your Dependency Chain

Before going live with any new script, start the server with a clean console and read every resource start line. Any “dependency not met” warning is a red flag — fix it before adding players. Use resmon 1 to confirm every expected resource shows a green status. For oxmysql specifically, “oxmysql ready” must appear in the console before your framework start line — if it doesn’t, your connection string is wrong.

For scripts sourced from the FiveM asset marketplace at marketplace-tebex.io, read each resource’s readme for explicit dependency declarations before adding the ensure line to your config. Scripts from buy-tebex.io include buying guides with compatibility notes that cover which scripts work well in the same stack — useful when adding to an existing dependency chain rather than building from scratch.

Keeping Dependencies Manageable Long-Term

As your server grows, dependency sprawl becomes a real maintenance burden. Ensure lists balloon, boot times climb, and conflict sources multiply. A few practices keep this under control:

• Audit your ensure list every few months. Remove resources that aren’t actively used — every extra resource is a potential conflict source and adds measurable boot time.
• Prefer scripts that use ox_lib’s built-in utilities over scripts that bundle their own custom versions of the same functionality. Duplicate utility layers cause version mismatches that are hard to diagnose.
• Group your ensure list with comments: databases, frameworks, utilities, jobs, vehicles. It takes five minutes and saves hours of diagnosis later.
• The vetted, optimised FiveM scripts at cfx-tebex.store are tested for clean dependency declarations and won’t introduce hidden conflicts into your load order.

Getting dependencies right is foundational work — it’s not glamorous, but a server with a clean load order and correctly declared manifests runs more stably, crashes less, and is far easier to debug when something does go wrong. Sort oxmysql and ox_lib first, read every manifest before you add a new script, and treat your server.cfg ensure order as a document worth maintaining carefully.