ox Stack Explained: ox_lib, oxmysql, ox_inventory, ox_target

Why one team's resources became everyone's foundation

Most FiveM servers in 2026 run at least one resource whose name begins with ox, and a Qbox server runs four. They share an origin: the Overextended team built a set of resources that solved the problems every framework was solving separately — a database connector, a shared utility library, an inventory, a targeting system — and built them framework-agnostic, so that ESX, QBCore, and later Qbox could all adopt them rather than maintain their own. Quality and neutrality did the rest; other authors began writing against the ox APIs because they could count on them being present.

That is why understanding the ox stack matters to a buyer as much as to a developer. When a script's listing says 'requires ox_lib' or 'ox_inventory only', it is telling you which foundation it assumes, and whether it fits the one you run. This guide describes each piece, what it replaces, and the one non-technical fact about the ecosystem that every server owner should know: its maintenance lineage.

ox_lib: the shared toolbox

ox_lib is a library rather than a feature — a resource other resources load to get common building blocks: context menus, input dialogs, progress bars, notifications, zones, and the client-server callback pattern (`lib.callback`) that lets a client await a server's answer without every author writing their own registrar. qbx_core requires it, so every Qbox server runs it, and a large share of QBCore and ESX resources adopt it rather than build their own UI layer. A resource built on ox_lib inherits its behaviour and its performance profile, for better and worse; a breaking change in ox_lib ripples into everything above it. The one-page version is at /answers/what-is-ox-lib.

oxmysql: the database pipe

oxmysql is the connector between Lua and a MySQL or MariaDB database. It replaced the older mysql-async and ghmattimysql connectors, is required by Qbox, and is the baseline across current QBCore and ESX builds. Its two properties that matter are that calls are asynchronous — a slow query degrades one feature, not the server thread — and that queries are parameterized, which is the standard defence against injection and the reason a 2026 script building SQL from strings is disqualifying. It offers transactions; whether a banking script uses them is that script's decision, not oxmysql's. It connects via the `mysql_connection_string` convar, and a wrong string is behind a large share of 'the script is broken' reports on fresh servers. The database patterns a buyer should expect are at /guides/fivem-oxmysql-database.

ox_inventory: the item model

ox_inventory owns items: player inventories, vehicle trunks and gloveboxes, stashes, shops, crafting, and a server-side item model with per-item metadata — a specific serial, a durability, an owner name. It requires ox_lib and oxmysql, runs on Qbox, QBCore, ESX, or standalone, and replaces the framework's own inventory rather than sitting beside it, which means disabling qb-inventory or the ESX default and letting ox_inventory own the items table. Because so many other scripts give, take, or check items, the inventory becomes a dependency for half the server, and a script that calls the old inventory's exports directly is a script that needs bridging. When a listing names supported inventories, that is the coupling it is disclosing.

ox_target: pointing at the world

A target system is how a player interacts with things: look at a vehicle, an NPC, a door, or a zone and a menu of actions appears. ox_target is the ox ecosystem's implementation, the successor to the qtarget lineage, and Qbox's standard; QBCore servers historically ran qb-target, and many resources support both through a small compatibility shim. Like the inventory, the target system is a dependency other scripts declare — 'requires ox_target' — so it is part of the stack decision rather than a cosmetic choice, and a script written only against qb-target's API will need a shim or an edit to run on ox_target.

The maintenance question, stated plainly

The ox resources share a lineage, and that lineage has changed hands. The original Overextended organisation archived its repositories; a successor group, CommunityOx, took up maintenance of ox_lib and related resources; and CommunityOx's own GitHub organisation was itself marked archived in April 2026. At the time of writing, no clearly established, actively maintained successor had emerged for the whole set. This is not a claim that the resources are broken — they run, they are widely deployed, and forks exist — but it is exactly the kind of stewardship risk to check directly on GitHub before building a new server on them, rather than assuming a widely used library is automatically a maintained one.

For a buyer the practical implication is narrower than it sounds. A script that depends on ox_lib inherits ox_lib's maintenance status; a script that talks through a bridge can be re-pointed if the foundation moves. Ask a seller which ox resources their script requires, by name and version, and whether the dependency is direct or bridged. That is the same lock-in question as the framework one (/guides/fivem-framework-lock-in), one layer down.

Putting the stack together

Order matters, because each ox resource depends on the ones beneath it. In server.cfg the working order is oxmysql, then ox_lib, then the framework core, then ox_inventory and ox_target, then everything that depends on them. The stack planner and start-order checker at /tools will build and check that order for you; the reasoning is at /guides/fivem-server-start-order and the full layer map at /guides/fivem-server-stack.

• oxmysql — first; the database must be reachable before anything queries it.
• ox_lib — before the framework core, which requires it on Qbox.
• Framework core (qbx_core, qb-core, es_extended) — before any gameplay resource.
• ox_inventory, ox_target — after the core, before anything that gives items or adds interactions.
• Everything else — after its declared dependencies, never before.