FiveM frameworks: ESX, QBCore and Qbox compared

Pick one framework and build everything on it. ESX Legacy has the largest pool of free resources and puts jobs in the database. QBCore is the default choice for new roleplay servers and keeps almost everything in Lua files you can read. Qbox is QBCore rebuilt on the ox_* stack, cleaner and faster but with fewer ready-made resources. All three run on the same FXServer, all three now expect oxmysql and ox_lib underneath them, and none of them will run each other's job scripts without work. The framework is the one decision on a FiveM server that is genuinely expensive to change later, which is why it is worth twenty minutes before you install anything.

What a framework actually is#

FXServer on its own gives you a multiplayer GTA session with no rules: players spawn, and that is it. A framework is a bundle of resources that adds the things a roleplay server assumes exist - a persistent character tied to a database row, money in accounts, an inventory, jobs with grades, a way for one resource to ask another whether a player is a police officer.

It is a convention as much as code. When a resource author writes "requires ESX", they mean their script calls ESX's shared object and expects ESX's event names, its database tables and its item definitions. That is the whole reason mixing frameworks does not work: an esx_ resource asking for xPlayer.getJob() gets nothing at all from qb-core, because the function does not exist there.

A framework server is therefore not one download. It is the core plus a database schema plus somewhere between 60 and 400 other resources, which is where both the fun and the failure modes live. The FiveM server and txAdmin post covers the layer above this one; this post is about what you put inside resources/.

ESX, QBCore and Qbox side by side#

ESX Legacy is the maintained line of the oldest framework still in wide use, published as esx_core - one repository that contains es_extended plus its menu, notification and progress-bar resources. Recent versions require oxmysql and ox_lib; older ones used mysql-async, and a tutorial that tells you to install mysql-async is out of date. ESX's distinguishing habit is that jobs and grades are rows in the jobs and job_grades tables rather than lines in a config file, which means adding a job means writing SQL or clicking through phpMyAdmin. Some people like that. Most find it the single most annoying thing about ESX.

QBCore is the framework most new roleplay servers start on, and the one most tutorials, YouTube videos and paid scripts target. Its configuration lives in plain Lua under qb-core/shared/ - items.lua, jobs.lua, gangs.lua, vehicles.lua, weapons.lua, locations.lua - so adding a job is one table entry and a restart. The trade is that the codebase grew fast, quality across the qb-* resources varies, and a lot of what people run is a fork of a fork.

Qbox is a continuation of QBCore rebuilt on the Overextended stack: ox_lib, oxmysql, ox_inventory, ox_target, ox_doorlock. It drops the things QBCore kept for compatibility, requires Lua 5.4 and a current FXServer build, and moves item definitions out of the core into ox_inventory/data/items.lua. It ships a compatibility layer that answers to qb-core, so a fair number of qb-* resources run unchanged - but not the ones that touch the inventory, and not the ones that write directly to QBCore's tables. If your resource list is mostly things you will write or heavily edit yourself, Qbox is the nicer place to work. If your resource list is mostly things you downloaded, QBCore will fight you less.

Two others you will see named. ox_core is Overextended's own framework: small, opinionated, very little prebuilt content, aimed at people who want to write their own server. vRP is the ancestor of most of this and is best left in the past. Whatever you read on a forum, there is no framework that is "the fastest" in a way you will feel - a framework costs a fraction of a millisecond per tick, and the 200 resources you stack on it cost everything else.

What has to sit underneath all three#

None of the frameworks are standalone. Before the core starts, these need to be running:

• `oxmysql` - the database bridge every current framework uses. It reads a connection string from a convar and exposes query functions to every other resource. Full detail in FiveM databases and oxmysql.
• `ox_lib` - a shared library for callbacks, notifications, context menus, progress bars, zones and points. Loaded as a shared script with @ox_lib/init.lua, and required by an increasing number of resources whether or not you chose Qbox.
• A voice resource - pma-voice is the usual free choice, and it needs mumble traffic, so leave it alone unless you know why you are changing it.
• The Cfx base resources - mapmanager, chat, spawnmanager, sessionmanager and hardcap, shipped in the default server data. Frameworks replace the spawn and character flow but still expect the session and chat pieces to exist.
• `screenshot-basic` - small, and txAdmin uses it for player screenshots.

Load order is not cosmetic. A resource that calls MySQL.query while oxmysql is still starting throws, and a job resource that asks for the shared object before the core is up gets nil and silently does nothing for the rest of the session. In server.cfg, that means:

ensure oxmysqlensure ox_libensure es_extended        # or qb-core, or qbx_coreensure ox_inventoryensure pma-voice# anything that depends on the framework goes after the frameworkensure esx_policejob

ensure starts a resource, or restarts it if it is already running, which makes it the right verb in a config file. Every line of the file is taken apart in FiveM server.cfg explained.

Installing one: txAdmin recipes versus doing it by hand#

txAdmin's deployer can build a server from a recipe - a YAML file that downloads repositories, unpacks them into resources/, imports the SQL and writes a starting server.cfg. It asks for a database connection string during setup and will create tables in whatever database you point it at. The recipe list has included the Cfx default template, an ESX Legacy build and community builds, and it changes between txAdmin versions, so read what your install actually offers rather than what a two-year-old video shows.

Recipes are worth using for exactly one thing: getting a first working server up in ten minutes so you can see what a framework looks like when it is not broken. Then look at what it gave you.

resources/  [system]/            # build helpers from the default server data  [standalone]/    oxmysql/    ox_lib/    pma-voice/  [core]/    es_extended/    ox_inventory/  [jobs]/    esx_policejob/    esx_ambulancejob/

FXServer scans resources/ for folders whose names are wrapped in square brackets and looks inside them, recursively. A folder without brackets is treated as a resource itself and must contain an fxmanifest.lua, or it is invisible. ensure always takes the resource name, never the path, so ensure esx_policejob works no matter how deep you nested it.

Doing it by hand is four steps and you should be able to do them:

1. Download the core release for the framework, unpack it into resources/[core]/, and check the folder name matches what the documentation tells you to ensure.
2. Import the framework's SQL dump into your database. Do this before the first start, not after it hangs.
3. Put the connection string in server.cfg and add the ensure lines in dependency order.
4. Start the server with the console open and read every line until the first player can spawn.

The manifest, and what you can tell from it#

Every resource has an fxmanifest.lua. Reading one before you install it tells you more than the forum post it came from.

fx_version 'cerulean'game 'gta5'lua54 'yes'author 'someone'version '1.2.0'shared_scripts {    '@ox_lib/init.lua',    'config.lua',}client_scripts { 'client/*.lua' }server_scripts {    '@oxmysql/lib/MySQL.lua',    'server/*.lua',}dependencies { 'ox_lib', 'oxmysql' }

The @resource/file.lua form pulls a file out of another resource, which is how oxmysql and ox_lib get injected. fx_version 'cerulean' is the current manifest generation; adamant and bodacious are older and still work. lua54 'yes' opts the resource into Lua 5.4 and is required by Qbox resources. An escrow_ignore block means the resource is partly encrypted through Cfx asset escrow, which is normal for paid scripts and means you cannot fix its bugs yourself.

What to look for before running someone else's resource: an os.execute, a PerformHttpRequest to a domain you do not recognise, a long base64 string passed to load, or any add_ace written into a Lua file. Leaked paid scripts are the main way FiveM servers get backdoored, and the payload is usually one of those four things. Keeping a modded server clean is the general version of this argument.

Writing against the framework#

The shape is the same everywhere: get the framework object once, get a player object from a server ID, call methods on it.

local ESX = exports['es_extended']:getSharedObject()RegisterCommand('wage', function(source)    local xPlayer = ESX.GetPlayerFromId(source)    if not xPlayer then return end    xPlayer.addAccountMoney('bank', 500)end, true)

local QBCore = exports['qb-core']:GetCoreObject()RegisterCommand('wage', function(source)    local Player = QBCore.Functions.GetPlayer(source)    if not Player then return end    Player.Functions.AddMoney('bank', 500, 'weekly-wage')end, true)

Qbox exposes its core directly as exports.qbx_core, so the same job is exports.qbx_core:GetPlayer(source) with the player functions hanging off the result. Older ESX tutorials use TriggerEvent('esx:getSharedObject', ...) instead of the export; it still works in Legacy but the export is what you should write in new code, because it cannot race with resource start order.

The true at the end of RegisterCommand is the restricted flag. It makes the command require an ACE permission instead of being open to everyone, which is the difference between an admin command and a gift to the first person who reads your resource list.

Performance, and where the framework is not to blame#

A framework server that stutters is almost never short of hardware. Measure before you buy anything:

• resmon 1 in a client F8 console lists every resource with its per-frame CPU time. Anything holding above 0.5 ms while nothing is happening is doing work it does not need to do.
• txAdmin's resource monitor gives you the server side, which is where database queries in loops show up.
• The console is the other half of the story. A resource throwing an error every tick will happily eat a core while printing the reason - see reading the console.

Typical figures, for a server with a normal roleplay resource list:

The two things that genuinely cost memory rather than CPU are streamed assets - custom vehicles, MLOs, clothing - and resources that cache large tables per player. Both grow with your resource list and neither shrinks when players leave, which is why a weekly restart is standard practice on roleplay servers.

Updating a framework without losing a weekend#

Framework updates are not like plugin updates. A core release can change database columns, rename events and break every resource written against the old names at once.

1. Read the release notes for breaking changes before downloading anything. A major version bump on ESX or QBCore usually has a migration list.
2. Export the database first. Every core update that touches the schema is irreversible on the way back.
3. Run the new core on a second server with a copy of the database and your real resource list, and log in. A staging server on the same account costs one small plan and saves this exact evening.
4. Update the framework and the resources that depend on it together, not one at a time.
5. Keep the old resources/ folder as an archive until the new one has survived a full player session. What to do when a mod update breaks covers the rollback discipline.

On RE:NODE, FiveM servers have txAdmin available, the file manager unpacks archives in place so a resource release goes straight into resources/, SFTP is on every server for bulk uploads, and the Schedules tab can run the weekly restart. The licence key is yours from the Cfx.re portal rather than ours, so it moves with you.

FAQ#

Can I run ESX and QBCore resources on the same server?

No. They expose different objects, different events and different database schemas. A handful of resources are written to detect both, and Qbox deliberately answers to qb-core for compatibility, but an esx_ job script on a QBCore server needs rewriting, not configuring.

Which framework should a brand new server pick?

QBCore, unless you have a specific reason. Most free resources, most paid scripts and nearly all tutorials assume it, which matters far more when you are stuck at midnight than any architectural argument. Pick Qbox if you intend to write your own resources and are comfortable reading source.

Do I have to pay for resources?

No, but most servers do. The free pool covers jobs, shops, garages and inventories perfectly adequately. Paid scripts buy polish and support. What you must not do is install leaked paid scripts: they are the most common backdoor route onto a FiveM server, and the person who gave you the file is not the author.

Where do jobs come from on each framework?

ESX reads them from the jobs and job_grades tables in the database, so a new job is an insert. QBCore and Qbox read them from a shared Lua file, so a new job is a table entry and a restart. All three then need a job resource to give that job something to do.

How much memory does a framework server need?

Two gigabytes runs a core and a handful of jobs for testing. Four is the realistic floor for a public server, and a full roleplay list at 64 players usually sits between six and eight. If you are above that with fewer than 200 resources, something is leaking rather than being busy.

Do I need my own licence key?

Yes. FXServer will not start without a Cfx.re licence key issued to you from the Cfx.re portal, and it is tied to the address it runs on, so moving a server means reissuing the key rather than copying it.