Which ESX Version Am I Running? How to Check…

Someone in your Discord pastes a five line snippet from a tutorial, swears it works, and your server console answers with attempt to index a nil value (global 'ESX'). You paste it into a different resource. Same error. You reinstall es_extended. Same error. The snippet is fine. It was written for a version of ESX you are not running, and nothing on your server is going to tell you that politely.

Half the pain in ESX development is not ESX. It is the gap between the version a guide was written for and the version sitting in your resources folder, and the fact that four quite different things all answer to the name ESX. So this is how to find out exactly which one you have in about two minutes, what changed at each step, and how to read a tutorial written for a different era without losing an evening.

What "ESX version" actually refers to

When people say ESX they usually mean es_extended, one resource that gives you players with money, jobs, an inventory and a pile of events other resources hook into. That resource has had a messy life.

There was the original ESX, the 1.1 line, which is what most of the old video content targets. Then 1.2, which cleaned some of it up. Then ESX Legacy, a community fork that fixed the abandoned parts and became the version everyone means when they say "just use Legacy". Legacy itself has moved a long way since it took over, and now lives in the esx_core repository alongside the menu, multicharacter and context resources that used to be scattered across a dozen separate downloads.

There are also forks of forks, sold inside prebuilt server packs, that call themselves ESX and have had their own patches applied for two years. Those are the fun ones. Your server is running exactly one of these, and the code you copy has to match.

The two minute check

Open resources/[core]/es_extended/fxmanifest.lua, or wherever your es_extended actually lives. Near the top you get something like this:

fx_version 'cerulean'
game 'gta5'

name 'es_extended'
version '1.11.4'

That version line is the honest answer when it is present. If the folder came out of a paid server pack, treat it as a hint rather than a fact. Repackagers edit the number, and they edit the code under it more often.

So confirm with things that are harder to fake:

Check the dependency. If fxmanifest.lua lists mysql-async, you are on the old line. Legacy uses oxmysql. A resource still calling MySQL.Async.fetchAll everywhere is 1.1 era code whatever the version string claims.
Check the items table. Run SHOW COLUMNS FROM items; on your database. A limit column is the old per item count model. A weight column is Legacy's total weight model. This is very hard to fake, because the entire inventory depends on it.
Check for an imports file. Recent Legacy ships an imports.lua and declares it as a shared script, which means ESX is already a global in your resource before your first line runs. If that file exists, most "how to get the ESX object" tutorials are solving a problem you no longer have.
Check the users table. SHOW COLUMNS FROM users; Legacy stores accounts, inventory, job, job_grade, loadout, position and skin on the row, with money and inventory held as JSON. Older setups push some of that into separate addon tables and their own resources instead.

Two minutes, four checks, and you know more about your server than the person who sold it to you.

What actually changed between the eras

The differences that break copied code are few in number and enormous in effect.

Getting the ESX object. The 1.1 pattern was an event with a callback, often wrapped in a while loop waiting for the object to arrive. 1.2 added the export. Recent Legacy hands you ESX as a global through the shared imports file. Three eras, three spellings, one error message when you mix them up.

Money. Old ESX kept accounts in their own table. Legacy keeps an accounts JSON column on the user row, which is why a hand written UPDATE users SET bank = ... from a 2020 guide does nothing useful now. The account names themselves have stayed stable: money for cash in hand, bank, and black_money for the cash you would rather not explain to the tax office.

Inventory. The old limit model counted items per type. Legacy weighs everything against Config.MaxWeight. Both are list based, neither is a grid, and the moment you install ox_inventory you are on a third model again. If you are planning items, the walkthrough of how ESX items get registered covers what changes and what stays put.

Identifiers. Older setups keyed players on steam:, which is why so many old servers lost characters when players launched without Steam running. Legacy defaults to license:, which everyone has.

Menus. esx_menu_default and its friends were the standard UI. Plenty of current script code assumes ox_lib instead. Neither is wrong. Both being half installed is an excellent way to get a job menu that opens as an invisible rectangle.

Reading a tutorial written for a different version

You can date almost any ESX guide from its first code block, which saves you from following it for twenty minutes first.

If you see TriggerEvent('esx:getSharedObject', function(obj) ESX = obj end), it predates the export. The logic underneath is usually still sound. Swap the first three lines and carry on.

If you see MySQL.Async.fetchAll or MySQL.Sync.fetchScalar, it is mysql-async era. oxmysql has equivalents with different names and different return shapes, so a straight find and replace gets you a new error rather than a fix.

If it mixes xPlayer calls with direct SQL updates against columns that no longer exist, close the tab.

If it uses steam: anywhere near a database key, close the tab twice.

The habit worth building is treating a guide as a description of the shape of a solution rather than as something to paste. The order of operations inside a job resource has not changed in five years. The exact API around it has changed three times.

When your version is a fork nobody can name

Prebuilt server packs are where this gets genuinely awkward. You open es_extended and find a version string matching no release, files that exist in no repository, and config options the real project never had.

You are not getting that back onto a mainline version by wishing. What you can do is pin down its behaviour and treat that as local truth:

# from the server root, on the box
grep -rn "getSharedObject" resources/[core]/es_extended/ | head
grep -rnE "oxmysql|mysql-async" resources/[core]/es_extended/fxmanifest.lua

Whatever those two answers are, that is your version for practical purposes. Write it down in the server's own notes, because the next person to ask which ESX this is will be you, in four months, at one in the morning.

The bigger question with a mystery fork is whether to keep it. A fork you cannot identify is a fork you cannot update, and it quietly gates every resource you buy for the next two years.

Should you upgrade, and in what order

For a server with players and a database full of characters, moving es_extended is a project rather than an afternoon. The work is rarely in es_extended. It is in the forty resources written against the old behaviour.

A sane order:

Copy the database. Then copy it again somewhere the server cannot reach.
Stand up a second server on the same box running the new version and nothing else. Confirm you can connect, make a character, and have money.
Add resources back in dependency order, starting with the inventory and anything that touches money. That is where breakage hides.
Convert your own resources last, since those are the ones you can actually fix.
Expect the items table shape to change, and write the migration SQL before the outage rather than during it.

For a server that has not launched yet, the maths is different and much happier. Install current Legacy, take the cleanest starting point on offer, and skip the entire upgrade story. If you are at that stage, the install walkthrough is the one worth following, because it targets what is current rather than what was current when a video was uploaded.

The short version

Your ESX version is a property of your server, not of the tutorial you found, and every "this does not work" argument in every framework Discord starts with those two being different. Read the fxmanifest, check whether your items table has limit or weight, check whether the dependency is mysql-async or oxmysql, and you have your answer.

The five line snippet in your Discord probably does work. It just needs its first line translated out of a dialect your server stopped speaking two versions ago.