FiveM Resource Start Order: Why It Breaks Servers

Start order is a dependency graph, not a preference

A resource's startup code often does more than register events — it queries the database for its own tables, reads another resource's exported config, or registers itself with a framework that has to already exist to accept the registration. Every one of those actions assumes something else is already running, not just installed. server.cfg doesn't understand your intent; it starts resources top to bottom, in the order the file lists them, and whatever a resource's startup code reaches for has to already be alive when it reaches.

That's why "framework → database → shared libraries → inventory → everything else" isn't a style preference, it's the actual shape of the dependency graph in most FiveM stacks: the framework's own startup often talks to the database, shared libraries sit under both the framework and gameplay resources, inventory sits under the framework and above anything that gives or takes items, and gameplay resources sit on top of all of it.

What wrong order looks like in console

The signatures are consistent enough to recognize on sight, and they're easy to mistake for a broken script rather than a sequencing problem:

• "attempt to call a nil value (global 'exports')" or similar — the resource tried to call another resource's export before that resource had registered it.
• "attempt to index a nil value" naming a framework object or shared table — something the framework provides hadn't been set up yet when this resource's startup code ran.
• A database query erroring or timing out immediately on server start, then working fine for the rest of the session — the database connector resource wasn't ready yet on the one occasion it mattered: startup.
• A resource that starts with no console errors at all, then breaks the instant a player triggers its first interaction with another resource — its own startup didn't need the dependency, but the feature does, and the dependency still isn't running.

ensure vs. start — and why ensure is the server.cfg default

Per the official server commands reference (docs.fivem.net): start only starts a resource if it's currently stopped, and does nothing if it's already running by some other means. ensure restarts the resource if it was already started, or starts it if it wasn't — which makes it idempotent, and is why nearly every server.cfg uses ensure rather than start for its resource list. refresh rescans the resources folder and makes new resources available to start, but doesn't start anything by itself.

The fxmanifest dependency/dependencies field is a separate mechanism: it declares that a resource requires another one to be present, and current docs.fivem.net material describes it as a load-before requirement rather than detailing exactly how far the server goes to auto-resolve start order from it. Treat explicit, ordered ensure lines in server.cfg as the practice you control directly — it's what the rest of the FiveM ecosystem relies on regardless of what a loader might resolve automatically.

A worked server.cfg ordering example

This is a generic, illustrative shape — substitute your actual framework and libraries — showing the layers in the order they need to start:

• Layer 1 — core data and shared libraries: ensure oxmysql, then ensure ox_lib.
• Layer 2 — framework: ensure qbx_core (or your framework's core resource).
• Layer 3 — resources the framework's own startup expects to exist: ensure ox_inventory, ensure ox_target.
• Layer 4 — your bridge/adapter layer, if your stack uses one, sits after the framework and before anything that depends on it.
• Layer 5 — gameplay resources that depend on everything above: banking, jobs, garages, and anything else purchased or built on top of the stack.

Diagnosing an order problem after the fact

If a resource is already installed and misbehaving in a way that looks order-related, the fast check is to move its ensure line to the very end of server.cfg (after everything else) and restart — if the errors disappear, order was the cause and you can now find the real minimum position by moving it earlier in small steps. If two or more resources are involved and it isn't obviously an order problem, that's a conflict rather than a sequencing issue — see our guide to diagnosing FiveM script conflicts for the bisection method that isolates which one.