For server owners · 6 min read · updated on Oct 9, 2026
ESX vs. QBCore vs. Qbox: which FiveM framework should you choose?
A fair look at ESX, QBCore and Qbox: what a FiveM framework actually does, where each one shines, and which fits your first server, a migration or a custom dev team.
Before you set up your first job or install your first car script, there's one decision that will stick with your server for a long time: the framework. ESX, QBCore and Qbox are the three names you'll run into almost immediately. This guide explains what a framework does, how the three differ, and how to make a sensible choice for your situation – without picking sides in a flame war.
What a framework does on a FiveM server
FiveM gives you the plumbing: players connect, resources load, client and server talk to each other. What it doesn't give you is the game logic of a roleplay server. That's the gap a framework fills. It's the foundation almost every other script builds on.
Typical framework responsibilities:
- Characters: players create one or more characters with a name, date of birth, appearance and progress.
- Money: cash, bank accounts, often dirty money too – plus functions to add, remove and transfer it.
- Jobs: police, EMS, mechanics and more, with grades, paychecks and permissions.
- Inventory: items, weight, using and trading – built in or provided by a separate resource, depending on the framework.
- Database: saving and loading all player data, usually via MySQL or MariaDB.
- APIs: functions and events other scripts use, for example to check which job a player has.
That last point matters most for your decision: scripts are almost always written for a specific framework. When you pick a framework, you're also picking the ecosystem of resources that comes with it.
ESX: the veteran with a long history
ESX is one of the oldest roleplay frameworks for FiveM. The actively maintained version is called ESX Legacy. Thanks to its long history, there's a huge selection of resources out there – free and paid, great and not so great.
Worth knowing:
- Plenty of older tutorials and scripts target outdated ESX versions. Make sure a script is meant for ESX Legacy.
- Many developers already know its structure, so help is easy to come by.
- Official docs live at docs.esx-framework.org.
ESX is a solid choice if you want to rely on proven scripts or your team already has ESX experience.
QBCore: widely used, with lots of scripts
QBCore came along later and spread quickly. Many script developers publish their resources for QBCore, often alongside ESX versions. It ships with a lot of core features out of the box, so you can get a playable server up fairly fast.
Worth knowing:
- The default resources cover many typical RP features, which makes getting started easier.
- Because it's so widespread, there are plenty of community guides and examples.
- Official docs live at docs.qbcore.org.
QBCore is a good fit if you want to launch quickly and tap into a broad script market.
Qbox: newer, built on QBCore ideas
Qbox is the youngest of the three. It builds on QBCore's ideas and includes a compatibility layer so many QBCore scripts keep working. At the same time, it leans heavily on the Overextended ecosystem, such as ox_lib and related resources.
Worth knowing:
- Many QBCore resources work, but not necessarily all of them without tweaks. Test before you go live.
- If you like the ox resources, you get a cohesive package here.
- Official docs live at docs.qbox.re.
Qbox is worth a look if you want a modern starting point without giving up the QBCore script catalog.
Side-by-side comparison
This table is intentionally high level. All three frameworks are still evolving and details change – when in doubt, check the current docs.
| Aspect | ESX (Legacy) | QBCore | Qbox |
|---|---|---|---|
| Ecosystem / resources | Very large, lots of old and new scripts | Large, many current scripts | Growing, plus many QBCore scripts via compatibility |
| Learning curve | Familiar, but outdated tutorials can trip you up | Beginner-friendly thanks to many default resources | Easy if you know QBCore or ox_lib |
| Community / docs | Long-standing, knowledge spread widely | Very active, lots of guides | Smaller but active, modern docs |
| Compatibility | Scripts must support ESX | Scripts must support QBCore | Native scripts plus many QBCore scripts |
Which one fits your situation?
Your first server
Go with the framework where you'll get help most easily. Look at the scripts you absolutely want (phone, inventory, garages, etc.) and check which framework they support. If you have friends or teammates with experience, their framework is often the best pick – know-how on your team beats any feature list.
You're planning to switch
Switching frameworks isn't an update, it's a rebuild. Player data, items and scripts all need to be moved over or replaced.
- List every resource you use and check whether it exists for the new framework.
- Set up a separate test server with a copy of your database.
- Plan how you'll migrate characters, money and inventories – or decide whether a clean wipe is the more honest option.
- Announce the switch to your community early.
Going from QBCore to Qbox is usually a shorter trip thanks to the compatibility layer than jumping between ESX and the QB world. Either way: test, test, test.
You have your own dev team
In that case, the codebase matters more than ready-made scripts. Have your developers dig into the docs and source code of each option. Useful questions: How clean are the APIs? How actively is it maintained? How easily can you plug in your own code without modifying the core?
What about a custom framework?
Some servers run a custom framework – written from scratch or heavily modified. That gives you full control, but it also means off-the-shelf scripts usually won't work without changes, and you have to build and maintain every feature yourself. For an experienced team that can make sense. For a first server, it's almost always too much.
Mix scripts carefully
Many scripts advertise support for multiple frameworks or ship with "bridges." That's handy, but it has limits:
- One framework per server. Running ESX and QBCore side by side leads to chaos with money, jobs and inventories.
- One inventory, one phone, one targeting system. Duplicate systems clash fast.
- Check dependencies. Read the install instructions before dropping a script in.
- Test server first. Never try new resources directly on your live server.
Set your framework on GS2THETOP
When you list your server on GS2THETOP, you can add your framework as a tag. That way players can filter for it – say, if they prefer ESX servers or are curious about Qbox. Listing takes about 30 seconds: just paste your cfx.re join link and the data is pulled from the public server list. List your FiveM server here.
To see which servers are already listed and how they present themselves, check the FiveM overview. More tips for running your server are in our guides.
Bottom line
ESX, QBCore and Qbox are all serious foundations for a roleplay server. ESX brings a long history and a massive catalog, QBCore wide adoption and a quick start, Qbox a modern approach with QBCore compatibility. Choose based on your team, the scripts you want and how much testing you're willing to do – then stick with it instead of hopping around.