ESX, QBCore or Qbox: which framework for a FiveM roleplay server?

Anyone starting a FiveM roleplay server sooner or later faces the question of which framework to build it on. Three names come up most often: ESX, QBCore and Qbox. All three are open source, all three solve similar problems and working servers run on each of them. They differ, however, in their script ecosystems, development approach and what they are compatible with. This article won't give you a single winner — it gives you the criteria to choose for yourself.

What a framework does

A FiveM server on its own has no characters, money, jobs or inventory. The framework adds all of that: a set of resources that define player data and how it is stored in the database, the economy, jobs, permissions and the functions other scripts use to interact with all of it. The framework is the foundation everything else stands on — the phone, garages, shops, police and EMS systems.

That leads to the most important practical consequence: scripts are written for a specific framework. An ESX script calls ESX functions and expects database tables shaped the way ESX uses them. It won’t run on QBCore without changes, and vice versa. Switching frameworks later therefore usually means rewriting or replacing a large share of your scripts and converting player data.

ESX

ESX is the oldest of the three and was long synonymous with FiveM roleplay. The currently maintained version is called ESX Legacy and is developed by the ESX team in the esx-framework organisation on GitHub; documentation is at docs.esx-framework.org. It uses oxmysql for database access.

The upside of a long history is a huge number of existing scripts, tutorials and developers who know ESX. The downside is that some older scripts were written for earlier ESX versions and may need changes to run on ESX Legacy. For any older resource, check which version it was written for and whether it is still maintained.

QBCore

QBCore is a younger framework built as a set of modular resources prefixed with qb- (for example qb-core, qb-inventory, jobs and other systems). It is developed in the qbcore-framework organisation on GitHub and documented at docs.qbcore.org. QBCore also uses oxmysql for the database.

Compared with ESX, QBCore ships more ready-made roleplay systems in its base install, so you can reach a playable server faster. A large ecosystem of free and paid scripts has grown around QBCore, and many paid scripts now support both ESX and QBCore. Because the base contains more resources, the default install tends to use more memory.

Qbox

Qbox started as a fork of QBCore. Its core (qbx_core) is built on libraries from the ox ecosystem — ox_lib, ox_inventory and oxmysql — while aiming to stay compatible with QBCore scripts through a backwards-compatibility layer. The project lives in the Qbox-project organisation on GitHub and is documented at docs.qbox.re.

Qbox appeals to those who want access to the QBCore ecosystem but prefer the ox libraries and their approach. Compatibility doesn't mean a perfect match, though: scripts that reach deep into QBCore internals or rely on qb-inventory may need changes. The Qbox documentation lists what is and isn't supported.

Side-by-side comparison

How to decide

Instead of asking “which one is best”, ask yourself these:

• Which scripts do you already own or plan to buy? If you have paid scripts for a specific framework, that is a strong argument. Check which frameworks their authors support.
• What does your developer or team know? A framework your team is comfortable with saves more time than the theoretical advantages of another.
• Do you want a quickly playable base, or to build from a smaller core? QBCore and Qbox ship more ready-made systems; ESX Legacy is leaner.
• Does the ox ecosystem appeal to you? If you want to build on ox_lib and ox_inventory, Qbox is a natural fit; those libraries are also commonly used with ESX.
• How active is development? Look at recent commits and releases in the repositories and at how current the documentation is.

Paid scripts and escrow

Many paid scripts are distributed through Cfx.re's Asset Escrow system. Such a script is tied to the Cfx.re account that bought it and runs on a server using a licence key from that account. When moving a server or switching frameworks, keep in mind that the key and purchases stay with your account, not with the host — and that you may not be able to adapt an escrowed script for one framework to another yourself.

What this means for hosting

All three frameworks need a MySQL or MariaDB database, a Cfx.re licence key and reasonably current server artifacts. For more than 32 players you need OneSync. The server base can be deployed with a txAdmin recipe; each framework’s documentation describes the steps. With us, MySQL and txAdmin come with the service — see the Database and txAdmin guide — and you can change the artifacts version as described in Changing the artifacts version.

Memory depends mostly on the number and quality of resources. The advisor on our FiveM plans page uses a starting point of roughly 4 GB for ESX and 5 GB for QBCore and adds headroom for player count and script load; it assumes one server instance and a database on the same machine. Qbox isn’t a separate option in the advisor — use QBCore as the starting point. If you want to switch frameworks on an existing server, start with a clean install following the Reinstalling a FiveM server guide and export the database first.

Summary

ESX Legacy has the longest history and a large number of scripts, though older ones need a compatibility check. QBCore ships more ready-made roleplay systems and has a broad ecosystem. Qbox builds on the ox libraries and keeps compatibility with most QBCore scripts. Decide based on the scripts you want to use, your team’s experience and development activity — and expect a later switch to be costly. If you’re unsure about plan size, send us your resource list via the contact page and we’ll help.