How to Install ESX Scripts

ESX has been through enough versions that "install an ESX script" means slightly different things depending on which ESX you run. Most install problems trace back to a version mismatch rather than a mistake in the steps, so this guide starts there.

Know which ESX you are running

Older scripts obtain the shared object by looping on an event:

TriggerEvent('esx:getSharedObject', function(obj) ESX = obj end)

Current ESX exposes it directly:

ESX = exports['es_extended']:getSharedObject()

A script written for one style running on the other produces a nil ESX object and fails on its first call. If you buy a script and it errors immediately with attempt to index a nil value (global 'ESX'), check which retrieval method it uses before assuming the script is broken — many scripts include both paths and pick automatically, but older free resources often do not.

Start order

As with any framework, es_extended must start before anything that uses it, and the database layer must start before es_extended. A working order looks like:

• ensure oxmysql
• ensure es_extended
• ensure ox_lib — if your scripts use it
• ensure esx_menu_default and the other ESX menu resources, if the script expects them
• …then gameplay resources

ESX menus are a real dependency, not decoration. A script that opens an ESX.UI.Menu will do nothing at all if the menu resource is missing, with no error in the console — the most confusing failure mode in ESX.

Items live in the database, not a Lua file

This is the biggest practical difference from QBCore. Classic ESX stores items in the items table in your database, so adding an item means an SQL insert rather than editing a shared file:

INSERT INTO items (name, label, weight, rare, can_remove) VALUES ('lockpick', 'Lockpick', 1, 0, 1);

If you run ox_inventory on top of ESX — an increasingly common setup — items move back into ox_inventory/data/items.lua and the database table stops being the source of truth. Know which one your server uses, because adding an item to the wrong place produces a script that runs and an item that does not exist.

Jobs and grades

ESX jobs live in the jobs and job_grades tables. A script gated to a job checks xPlayer.job.name, so the job row must exist and the grade must be within the range the script expects. Missing grades are a quiet failure: the job exists, the player has it, and the menu still refuses to open because the grade check falls through.

Import SQL, then restart fully

Run every .sql file the script ships before its first start. Then restart the server rather than hot-reloading — ESX caches player data on join, so a script that adds columns to a player table needs players to reconnect before it sees them.

Where to go next

ATY scripts detect ESX and QBCore automatically, so the same download works on either. If you have not committed to a framework yet, read QBCore vs ESX first. The FiveM Vehicle Shop Script is a good first install on ESX: it touches the database, jobs and the inventory, so getting it working proves the whole chain.

Every ATY script ships with its own setup page in the documentation, and delivery is automatic through Cfx.re Keymaster the moment payment clears. Browse the full catalogue in the store, or open a ticket in our Discord if you get stuck — you talk to the developers who wrote the code.