How to Install ox_inventory (ESX and QBCore)

Every "best FiveM inventory" thread points to the same resource: ox_inventory. What those threads rarely mention is that it is not a drop-in swap. It expects two other resources already running, a convar telling it which framework you are on, and it behaves differently depending on whether your server runs ESX Legacy, Qbox, or classic QBCore.

Short answer: ox_inventory needs ox_lib and oxmysql installed and started before it, plus the inventory:framework convar set to match your server. Overextended, the developer, officially supports esx, ox_core, qbx (Qbox), and nd_core out of the box. Classic QBCore has no first-party bridge, so QBCore servers either migrate to Qbox, which ships ox_inventory by default, or build a custom bridge using the process the documentation already publishes for unsupported frameworks. This guide walks through dependencies, resource order, per-framework setup, the database, and the conflicts that show up most often.

What ox_inventory actually replaces

Overextended describes ox_inventory as a complete and modern inventory system for FiveM, providing a flexible slot-based inventory with support for shops, stashes, crafting, and vehicle storage. Every interaction, opening a stash, buying from a shop, moving an item between slots, is validated server-side rather than trusted from the client. Weapons are handled as items rather than through the base game's loadout system, which is what enables attachments, ammo types, and durability to work the way they do.

The official docs are direct about the tradeoff: "If you are replacing a built-in framework inventory there will be compatibility errors." That warning is worth reading twice before you install anything. ox_inventory is not an add-on sitting next to your framework's inventory, it fully replaces it, along with any resource that assumed the old item, weapon, or shop system was still there.

Shops support restricted access based on groups and licenses, and can price items in different currencies, black money and poker chips are the two examples the documentation gives. Stashes work the same way: a stash can be tied to a specific identifier, spun up per player automatically, or exposed through a container item like a paperbag or backpack. Vehicle gloveboxes and trunks are stashes too, and unowned vehicles or dumpsters can generate randomised loot if you enable it.

Install the dependencies first: ox_lib and oxmysql

ox_inventory will not start without both of these already running.

• ox_lib: a standalone library of reusable exports that most modern ox and Qbox resources build on. Download the latest release and drop it into your resources folder.
• oxmysql: the MySQL/MariaDB client ox_inventory uses to read and write inventory data. Its own docs recommend MariaDB over stock MySQL 8 for compatibility, and explicitly advise against using XAMPP as a database host beyond local testing. Set your connection string with set, never setr, since it contains credentials.

Both must appear before ox_inventory in your server.cfg. If either is missing, disabled, or errors on startup, ox_inventory fails silently or throws export errors that look unrelated to the real cause.

Installing ox_inventory step by step

Get the release

Download the pre-built ox_inventory.zip release rather than the raw source archive. The inventory UI is written in React and has to be bundled into HTML, CSS, and JavaScript before FiveM can load it; the release zip already contains that bundle, while the raw source does not. If you specifically need to build from source, the documented process is git clone, then cd ox_inventory/web, then bun i and bun run build.

Resource start order

The documentation gives one exact sequence, and skipping a step in it is the single most common cause of a broken first install:

start oxmysql   # this should be one of the first resources
start ox_lib
start framework # the name of your framework (i.e. ox_core, es_extended, qbx_core)
start ox_target
start ox_inventory

ox_target is optional but recommended; it powers the interaction prompts for stashes, shops, and containers. You will also see qtargetreferenced in Overextended's own ESX example server.cfg, and it still works today, but the documentation flags it as deprecated with a note that a future update may drop support entirely. Starting a new build on ox_target now avoids a migration later.

Core convars to set on day one

Configuration runs through convars. The ones that matter before your first boot:

• setr inventory:framework "esx": activates the event handlers and functions for your framework. Supported values are ox, esx, qbx, and nd.
• setr inventory:slots 50: number of slots in a player inventory.
• setr inventory:weight 30000: maximum carry capacity in grams (some frameworks override this).
• setr inventory:police ["police", "sheriff"]: jobs with access to evidence lockers and police armouries.
• set inventory:clearstashes "6 MONTH": how long an unused stash persists before it is wiped.

Installing on ESX Legacy

You need a compatible build of ESX Legacy (1.6.0 or higher). Start ox_inventory immediately after es_extended:

start oxmysql
start ox_lib
start es_extended
start qtarget
start ox_inventory

Set inventory:framework to esx. ox_inventory is a complete replacement for ESX's default item, inventory, and weapon system, which means resources built around the old behaviour,esx_shops, esx_weaponshop, esx_policejob, esx_trunkinventory, and esx_inventoryhud among them, are expected to conflict or become redundant. If you have existing player data, run convertinventory esx from the server console once, optionally follow it with convertinventory esxproperty for owned properties, then restart before touching anything else.

Functions like xPlayer.getInventoryItemstill work after migration for backward compatibility, but the docs mark them deprecated. New code should call ox_inventory's own exports directly instead.

Installing on QBCore and Qbox

This is where the title of this guide needs an honest caveat. Qbox is a fork of QBCore built by former QBCore contributors, and it is the framework Overextended actually documents and ships a bridge for. Their own docs put it plainly: they strongly advise using Qbox as an alternative to QBCore.

If you are on Qbox

Set up qbx_core, add setr inventory:framework "qbx", and start ox_inventory immediately after qbx_core. A fresh Qbox install already ships ox_inventory as its default inventory, so there is often nothing extra to configure beyond your own item list.

If you are on classic QBCore

The current ox_inventory release only ships bridge modules for four targets: esx, nd, ox, and qbx. There is no qb folder. That leaves two real paths if you want to stay on QBCore rather than move to Qbox:

1. Migrate the core resource to Qbox, which already ships the qbx bridge and ox_inventory together. If you are still weighing that decision, our framework fit comparison covers the tradeoffs in more depth.
2. Build a custom bridge yourself. The docs describe the process for any unsupported framework: set setr inventory:framework "custom", copy the ox folder from the bridge directory under a new name, then rewrite its bare functions and event handlers to call your own QBCore exports. The documentation calls this setup "highly opinionated and rigid," which is another way of saying you own the maintenance burden going forward, not Overextended.

Setting up the database

There is no separate SQL file to import for ox_inventory itself. It reads and writes through the player and vehicle tables your framework already uses. For ESX and Qbox, that mapping is handled by the bridge automatically. For a custom bridge, you map it yourself inside modules/mysql/server.lua:

elseif shared.framework == 'custom' then
    playerTable = 'characters' -- table storing player / character data
    playerColumn = 'charid'    -- primary key for identifying the character
    vehicleTable = 'vehicles'  -- table storing owned vehicle data
    vehicleColumn = 'id'       -- primary key for identifying the vehicle

Common conflicts and errors you will hit

• Money as an item conflicts with banking systems. Some frameworks track cash through a separate account system rather than an inventory item, and syncing the two needs explicit bridge support.
• "No such export * in resource ox_inventory." Almost always a start-order problem: either a resource calling the export started before ox_inventory, or ox_inventory itself failed to start because ox_lib or oxmysql errored earlier in the log.
• Stashes or trunks appear not to save. Inventories batch-save on a five-minute interval, when the player count hits zero, and on a proper txAdmin-triggered restart. A hard kill of the server process between those saves loses whatever changed in that window. Use the saveinv console command to force a save manually when you need one.

For the living list of known framework incompatibilities, Overextended tracks them in GitHub issue #1297.

Getting ox_inventory to boot is the easy half. Migrating every third-party job, vehicle, and housing script that assumed a different inventory export is where installs actually stall.

A first-boot checklist before you invite anyone

Start the server and read the console top to bottom before you touch anything else. ox_inventory should log that it started with no dependency errors above it, and there is a inventory:versioncheck convar that compares your build against the latest GitHub release automatically, so an out-of-date install will tell you on boot instead of failing silently later.

Connect with a test client and confirm four things before you consider the install done: your primary inventory opens on its bound key, giving yourself an item with the admin additem command actually places it in a slot, a shop or stash you registered is reachable and restricted the way you configured it, and a fresh restart still shows that item afterward. That last check matters more than it sounds. A server that boots clean but silently fails to persist data is not actually finished, it just has not shown you the problem yet.

Where a clean install stops being enough

A base ox_inventory install can run cleanly and still leave you with a dozen scripts silently pointing at exports that no longer exist. Finding every one of those before your players do is exactly what a script compatibility audit is for. If you would rather have the migration itself handled and verified, a scoped compatibility build is the faster route than debugging exports one resource at a time.

The bottom line

ox_inventory rewards a specific install order: oxmysql, then ox_lib, then your framework, then ox_inventory itself, with theinventory:framework convar matching whichever system you are actually on. ESX Legacy and Qbox get first-party support out of the box. Classic QBCore does not, and pretending otherwise only delays the decision between migrating to Qbox or committing to maintain a bridge yourself. Either way, budget real time for compatibility cleanup before you consider the install finished.