What it is
ESX is the oldest still-maintained FiveM roleplay framework. It originated as a community fork around 2018, and over the next several years it became the default substrate for the vast majority of public FiveM scripts on Tebex, Cfx forums, and GitHub. The phrase "compatible with ESX" on a script's product page typically means: it expects an ESX environment to provide a player object, an inventory, a money system, and identity utilities.
Internally, ESX exposes a server-side ESX object and a client-side ESX object. On the server you call ESX.GetPlayerFromId(source) to get an xPlayer table, then call methods like xPlayer.addMoney, xPlayer.getInventoryItem, xPlayer.triggerEvent. On the client, ESX.PlayerData reflects the cached state. This pattern is verbose but extremely well-documented across thousands of community resources.
Two large families exist in the wild: the Legacy line (1.x through 1.10+) which most older scripts target, and a modern fork actively maintained by the ESX-Org community. The two are largely API-compatible at the xPlayer level but diverge in shared exports, callback handling, and database adapter expectations.
When to choose ESX
- You are buying or porting Tebex scripts where the largest catalog of compatible work exists.
- Your team has prior ESX experience and the cost of retraining outweighs the benefits of a newer framework.
- Your server inherited an ESX codebase and a full migration would block other roadmap work.
- You want the broadest possible pool of community tutorials, YouTube content, and forum answers when something breaks at 2 AM.
Version timeline
ESX 1.1 / 1.2
2019
Early stable line, mysql-async, esx_menu_default UIs.
ESX Legacy (1.7–1.10+)
2021
Stabilization phase, oxmysql adoption growing, shared exports refined.
Modern ESX fork
2024
Community-driven cleanup, Lua 5.4 patterns, ox_inventory recommended.
Signature code patterns
Get a player and add money
local xPlayer = ESX.GetPlayerFromId(source)
if xPlayer then
xPlayer.addMoney(500)
xPlayer.showNotification("You received $500")
endServer callback (legacy)
ESX.RegisterServerCallback('myresource:hasItem', function(source, cb, itemName)
local xPlayer = ESX.GetPlayerFromId(source)
local item = xPlayer.getInventoryItem(itemName)
cb(item and item.count > 0)
end)Common pitfalls
Shared exports timing
Calling exports['es_extended']:getSharedObject() before the framework finishes loading returns nil and silently breaks downstream code. Wrap in a wait loop or use the AddEventHandler('esx:getSharedObject') pattern your specific ESX line ships with.
Identifier vs source confusion
source is the player's runtime network ID; identifier (license:..., steam:..., discord:...) is the persistent key. Database tables key on identifier, runtime events use source. Mixing them is the single most common bug in junior ESX code.
mysql-async vs oxmysql
Older scripts ship with mysql-async syntax (MySQL.Async.execute). Newer scripts assume oxmysql (MySQL.execute or exports.oxmysql:execute). Running both in the same server works but doubles your DB pool and complicates connection limits.
Quasar Academy support for ESX
First-class support
Quasar Academy supports ESX end-to-end: weekly code review on Elite covers ESX-specific patterns, the Developer path includes ESX-targeted milestones, and our Store team builds against ESX as a first-class target.
Common questions about ESX
- Is ESX Legacy still maintained?
- Yes. The ESX-Org community continues to push patches and security fixes to the Legacy line, and a separately maintained modern fork ships ongoing improvements. "Dead" framings circulating in 2022–2023 are out of date as of 2025–2026.
- Should I migrate from ESX to QBCore or QBox?
- Only if a concrete pain point demands it (specific script ecosystem, team preference, performance ceiling). The migration cost is non-trivial — see our /compatibility/esx-vs-qbcore and /compatibility/esx-vs-qbox decision pages for the trade-off math.
- Does Quasar Academy support ESX 1.10 / 1.5 / Modern?
- Yes for all three. Code review and milestone work targets whichever ESX line your server actually runs. Tell us in onboarding which version you're on and we route you to the right examples.
- Can I run ESX scripts and QBCore scripts side by side?
- Technically yes, by running both frameworks and routing per-resource. Practically no — you double your shared object surface area, double your DB load, and create two competing player object lifecycles. Pick one.
- Should new servers in 2026 still pick ESX?
- If the ecosystem of compatible scripts you want to run is biggest on ESX, yes. If you're starting clean and want a more opinionated, performance-tuned base, QBox is worth a serious look. See /compatibility/esx-vs-qbox.