Qbox, QBCore or ESX: which framework in 2026

For a new FiveM server in 2026, start on Qbox: it runs almost all QBCore scripts, builds on ox_lib and oxmysql, and is what Freedom Roleplay runs on. Pick ESX Legacy when the scripts you want are written for ESX, and if you already run one of the three, stay on it unless something specific forces a move.

That is the short answer. The rest of this post is why, and what to check before you commit, because the framework decides how every script on your server talks to it.

The three in one paragraph each

• Qbox. Started in September 2022 as a QBCore fork, with backwards compatibility for almost all QBCore scripts as a stated goal. The core needs OneSync, ox_lib and oxmysql, and the database has to be MariaDB 10.9 or newer: the Qbox docs say MySQL is not supported. Installed through a txAdmin recipe.
• QBCore. The framework Qbox forked from. It ships its own resources, such as qb-inventory, qb-target and qb-menu, and scripts reach the framework through one core object. Also installed through a txAdmin recipe, with MariaDB in its own install guide.
• ESX Legacy. The current line of ESX, the oldest of the three: ESX started in 2017. The core covers identity, multicharacter, menus, notifications, skins and text UI, and the ESX docs list 50+ pre-built systems for jobs, the economy and gameplay. The current core runs on oxmysql.

Qbox and QBCore are close, not identical

The Qbox docs put compatibility with existing QB scripts at 99%, and qbx_core declares itself as qb-core, so a resource that lists qb-core as a dependency still finds it. Most QBCore scripts start on Qbox without changes.

The last percent is where the bugs live. Qbox has no core object; data comes through exports and modules instead. Job and gang grades are numbers rather than strings. Multijob is built in and cannot be switched off, and the docs warn against external multijob scripts that are not made for Qbox. Inventory is ox_inventory, and moving over means converting that data. A QBCore script that reaches into any of these needs a small port, not just a restart.

The rule I keep on Freedom: never paste a snippet from a QBCore or ESX guide into a Qbox resource without checking the Qbox equivalent first. Close is not the same as interchangeable.

ESX is a different family

ESX is not related to the other two. An ESX script gets its player through ESX.GetPlayerFromId and works on the xPlayer object; a QBCore script asks the core object for QBCore.Functions.GetPlayer. Everything a script does with money, jobs or items goes through that object, so moving a script between the families means rewriting those parts, in either direction.

What carries over is everything that never touched the framework: standalone resources, most NUI work, and ox resources such as ox_lib, ox_target and oxmysql, which work on either side.

ESX Legacy can carry a real server. Alberti Roleplay, my previous server, ran 50+ custom scripts on it and had 100 peak players while it was live.

How to choose

• List the scripts you cannot do without, paid ones first, and check which frameworks each supports. That list decides more than any comparison table, this one included.
• Check your database. Qbox needs MariaDB 10.9 or newer. If your host only offers MySQL, either change host or pick something else.
• Think about who maintains it. A developer who knows one framework well is worth more than the small differences between Qbox and QBCore.
• If nothing on that list ties you down, start on Qbox with the ox stack. You keep access to almost every QBCore script and get ox_inventory and ox_lib from day one.

Should you switch?

Usually not. Moving means porting every script that touches the player object, converting inventory and job data, and testing all of it again. Do it when the framework is blocking something you need, not because another one is newer.

If you do move from QBCore to Qbox, the Qbox docs recommend installing through their recipe, and their SQL changes alter the players table, so back up the database first and run the conversion on a development server before the live one. Moving from ESX to either of the others is a rebuild of every framework-facing script, and should be priced as one.

What I build on

Freedom Roleplay runs on Qbox with ox_lib, ox_inventory, ox_target and oxmysql. Alberti Roleplay ran on ESX Legacy. I still build for ESX Legacy, along with standalone resources that run anywhere.

Which framework and version you run is one of the first questions before any quote, because it decides how a script talks to your server. Unsure which one you have? Look in your resources folder: qbx_core means Qbox, qb-core means QBCore, es_extended means ESX.