What is ESX?

Ask around a FiveM server owners’ Discord what ESX is and the answers pile up fast. It is a framework. It is the reason so many script names start with esx_. It is a GitHub organisation, a txAdmin recipe, and the thing half the paid resources on any marketplace list under “supported frameworks”. All of those are true at once, which is why the question keeps getting asked. This post takes the framework apart: where it came from, what the core does when a player joins, how a script talks to it, what ships free, and what you still end up buying once the free stack is running.

The short version

ESX is an open-source roleplay framework for FiveM, the platform that lets people run modified Grand Theft Auto V servers with their own rules and content. It is written in Lua, released under the GPL-3.0, and maintained by the esx-framework organisation on GitHub. The current line is called ESX Legacy. Its job is to give a server the things a roleplay city cannot run without: persistent characters, money and bank accounts, jobs with grades, an inventory, and a common way for every other script on the server to read and change those things.

The name covers three layers people tend to blur. There is es_extended, the single core resource that holds the player object, the config and the shared functions. There is the set of first-party resources that ship in the same repository, from esx_identity and esx_multicharacter to the default inventory and menus. And there is the ecosystem of third-party scripts written against the same conventions, which is where most of the content on a mature server comes from. That third layer has a home of its own: ESX Tebex is the official Tebex store for ESX, where independent creators collaborate to sell scripts that support ESX Legacy, and every listing there states the framework build it was tested against.

Where it came from

ESX started in 2017 as EssentialMode Extended, a layer bolted onto EssentialMode, an early FiveM base that handled little more than identifiers and money. Contributors kept adding what a roleplay city actually needed until the extension mattered more than the thing it extended, and the project’s own documentation still dates it to that year. The 1.1 and 1.2 releases from that era are running on old servers to this day, still handing the framework to scripts through the esx:getSharedObject event, and they are behind a good share of the “this script does not work” threads you will read.

ESX Legacy is the rewrite that cut the EssentialMode dependency out entirely. The esx_core repository that holds today’s code was created in May 2021 and now contains the core and sixteen supporting resources in one tree. Legacy moved database access to oxmysql, added multicharacter support, and kept the player API that thousands of scripts already depended on, which is the main reason the ecosystem followed it instead of splintering. Development has not slowed down either. Version 1.13.5 landed in May 2026, 1.14 in July, and 1.15.0 on 1 September 2026, with the last two moving shared helper code into a bundled esx_lib resource and replacing the loading screen.

One more piece of lineage explains the marketplace you will be shopping in. QBCore, the other big FiveM framework, came out of the same ESX-shaped world of the late 2010s and reused many of its conventions. The two diverged in player model and inventory philosophy, but they are close enough that many creators ship one script with a bridge for both, so a listing that says “ESX and QB” is usually telling the truth. If you are weighing the two, the store’s QBCore scripts on Tebex page shows what the other side of that fence looks like.

What the core does when a player joins

When a player connects, es_extended looks up their identifier (the Rockstar licence by default, controlled by the esx:identifier convar), loads or creates a row in the users table, and builds an xPlayer object on the server. Everything a script does to a player goes through that object. It has functions to read and change money across the configured accounts, get and set the job and grade, add and remove inventory items with a weight check, manage weapons, send notifications, and store arbitrary metadata against the character.

The defaults tell you a lot about the design. A fresh character starts with $50,000 in the bank and nothing in hand. The configured accounts are cash, bank and black money, and every job paycheck runs on a seven-minute timer, halved when the player is off duty. The built-in inventory enforces a maximum carry weight of 24, in whatever unit your items table uses, unless you swap it for something else, and the core ships a bridge for ox_inventory because so many servers do exactly that. Multicharacter switches itself on when esx_multicharacter is present. Admin rights come from configurable groups rather than a hard-coded list.

Underneath it is a plain MySQL or MariaDB schema. The legacy.sql file that ships with the core creates the users table and the tables the first-party resources expect: jobs and job_grades, items, owned_vehicles, addon_account and addon_inventory for society funds and stashes, datastore, billing, user_licenses, and a handful more. The framework owns the schema, and every add-on assumes those tables exist with those names, which is why “works with ESX” on a listing is a meaningful promise rather than a marketing line.

How a script talks to it

Getting hold of the framework used to be a ritual of its own. Legacy made it a one-liner: add shared_script '@es_extended/imports.lua' to a resource’s fxmanifest and the ESX table is there on both the client and the server, wired to the exports of es_extended. Under the hood that file does exactly what you would write yourself, ESX = exports["es_extended"]:getSharedObject(), and it also keeps a client-side copy of the player data in sync through the esx:setPlayerData event.

From there most scripts use three building blocks. Server callbacks let the client ask the server a question and wait for the answer, which is how a shop menu learns what the player can afford. Usable items let something in the inventory do work when a player uses it. And the player object’s own functions do the rest. A vendor that sells bread looks like this on the server:

ESX.RegisterServerCallback('shop:buyBread', function(source, cb, count)
    local xPlayer = ESX.GetPlayerFromId(source)
    local price = 5 * count
    if xPlayer.getMoney() < price or not xPlayer.canCarryItem('bread', count) then
        return cb(false)
    end
    xPlayer.removeMoney(price)
    xPlayer.addInventoryItem('bread', count)
    cb(true)
end)

ESX.RegisterUsableItem('bread', function(source)
    local xPlayer = ESX.GetPlayerFromId(source)
    xPlayer.removeInventoryItem('bread', 1)
    xPlayer.showNotification('You ate some bread')
end)

On the client, the matching call is ESX.TriggerServerCallback('shop:buyBread', function(ok) ... end, 2), and the whole interaction fits in a few dozen lines. That simplicity is why ESX has such a deep back catalogue: one developer can write a job in an evening, and thousands have.

The resources that ship with it

Cloning esx_core gives you the core plus sixteen resources: esx_identity and esx_multicharacter for character creation, esx_skin and skinchanger for appearance, the default inventory, the context and menu resources, notifications, a progress bar, a text UI, a chat theme, a loading screen, a cron resource, and the new esx_lib. That is the skeleton. The organs come from the separate ESX-Legacy-Addons repository and the txAdmin recipe, which pull in the resources most servers consider mandatory: esx_society for job accounts and boss menus, esx_billing for fines, esx_vehicleshop for the dealership, esx_ambulancejob for death and revive, and the police job that gives the city its other half.

Everything above is free, and it is good, which is the part newcomers underestimate. A server that runs the recipe and nothing else is a working city. Characters persist, money moves, cops can arrest, medics can revive, and cars can be bought and garaged.

Installing it

The quickest route is the recipe. txAdmin, the web panel bundled with every FXServer download, offers ESX Legacy in its deployer. Point it at an empty MySQL or MariaDB database and it clones the core and addons, imports the SQL, and writes a server.cfg with the resources in the right order. The esx-framework organisation maintains that recipe in its own repository, so what you get is current rather than a year-old snapshot. Give the deployer a fresh database, not one that already holds another framework’s tables.

Manual installs follow the same shape: put oxmysql in place with a connection string in server.cfg, clone esx_core into your resources folder, run legacy.sql against the database, then ensure the resources in the order the bundled server.cfg shows. The core declares only one resource dependency, oxmysql, and it needs a recent FXServer build with OneSync enabled. Keep a copy of the default config next to yours, because updates change keys and the fastest way to diagnose a broken update is a diff. The official documentation covers both routes. If you would rather not assemble a base at all, the readymade ESX servers on ESX Tebex arrive with the framework, the addons and a set of paid scripts already wired together.

What the free stack does not give you

Every owner reaches this point, usually about two weeks in. The recipe gives you a city. It does not give anyone a reason to log in on a Tuesday. Job loops with real progression, heists with planning stages, a phone players use, an inventory that does not look like 2019, a HUD, interiors for the businesses, vehicles beyond the stock GTA lineup: none of that is in the box, and building it yourself is a second job. This is the layer the marketplace exists for, and it is the layer where the framework label on a listing matters most.

It is also the reason ESX Tebex exists. As the official Tebex store for ESX, it is where creators who build for the framework collaborate to sell their work, and the catalogue is organised the way an ESX owner thinks. The ESX scripts shelf lists each resource with the framework build, dependencies and escrow status it ships with, and the creators page lets you shop by the studio whose code you already trust. Tebex itself is the checkout most FiveM creators sell through, and if that word is the unfamiliar one, the store’s guide to what Tebex is covers that side. This store’s own ESX Scripts category carries a broad range as well, so compare both before you settle on a supplier.

ESX or QBCore?

The question comes up in every planning thread, so here is the short comparison. Both are Lua, both sit on oxmysql, and both will run a full city. The differences are in age, conventions and what you will find on the shelves.

	ESX Legacy	QBCore
Started	2017	2021
Core resource	es_extended	qb-core
Getting the framework	shared_script ‘@es_extended/imports.lua’	exports[‘qb-core’]:GetCoreObject()
Server player object	xPlayer from ESX.GetPlayerFromId	Player from QBCore.Functions.GetPlayer
Default accounts	cash, bank, black money	cash, bank, crypto
Where the scripts are	The largest back catalogue, with many older releases	Newer catalogue, more first-party resources

Neither choice is wrong. ESX wins on breadth and on the sheer number of fixes already written for any problem you will hit. QBCore wins if you want more of the city to come from one organisation. Whichever you pick, buy scripts that name the framework build they were tested on, because “works with everything” usually means “tested on nothing”.

Is ESX the right choice in 2026?

If you want the widest choice of scripts, the longest paper trail of fixes, and a framework that is still shipping releases every few weeks, yes. The 2026 releases show a project that is refactoring rather than coasting, and the player API has been stable long enough that a script from 2022 usually still runs. Two honest caveats. The ecosystem is large enough to contain plenty of abandoned code, so check when a resource was last updated before you install it. And the older 1.x servers still out there will mislead you if you copy their snippets, because the esx:getSharedObject event they rely on is gone from Legacy.

Start with the recipe, run it for a week with real players, and write down what they ask for. Then shop for those things one at a time, from creators who state which ESX build they tested against, and lean on the ESX job scripts first, since jobs are what turn a city into a routine. Framework first and purchases second is the order that ends with a server people come back to.