How to Install ESX Legacy in 2026 (FiveM Setup…

Most ESX installs don't fail at the install. They fail three days later, when a resource loads before oxmysql, or a connection string picks up a stray quote, or a 2019 tutorial sends you cloning repositories that have since been archived. Learning how to install ESX takes about fifteen minutes. Learning to install it so it still boots after your tenth script is the part worth reading. This guide covers both install routes, what the database actually stores, how to prove the install worked, and how to add your first job — the only test that really counts.

How to Install ESX Legacy: The Short Version

Deploy the official ESX Legacy recipe in txAdmin, or install manually: create a MySQL database, import legacy.sql, copy esx_core's [core] folder into resources, set mysql_connection_string in server.cfg, then ensure oxmysql, es_extended and [core] in that order. Restart and watch the console for ESX's start line.

The manual sequence in full:

Get fxserver artifacts running and reachable, with txAdmin up.
Create an empty database and a user with full grants on it.
Import [SQL]/legacy.sql from esx_core.
Drop [core] into resources, alongside oxmysql.
Set the connection convar and turn OneSync on in server.cfg.
Ensure resources in dependency order, restart, verify in console.

esx_core vs es_extended vs the Old 1.x Forks

These three names confuse almost every newcomer. esx_core is the GitHub repository. es_extended is the resource inside it that everything else talks to. ESX Legacy is the maintained release line — at the time of writing, tag 1.14.0 from July 2026.

The old ESX 1.1 and 1.2 era scattered functionality across dozens of standalone repositories, each versioned separately, each drifting. That fragmentation is gone. Core resources now ship in one monorepo, and addons live together in ESX-Legacy-Addons under an [esx_addons] folder.

Here's a reliable tell for a dead tutorial: if it tells you to clone esx_bankerjob, esx_holdup, esx_phone or esx_sit as separate downloads, close the tab. Those repositories are archived. So are the old ZAP-Hosting ESX Pack and PlumeESX txAdmin recipes, both marked deprecated in the official recipe index.

Prerequisites: What Has to Exist First

You need four things before ESX enters the picture:

fxserver artifacts, recent enough to support your target game build. The official ESX server.cfg ships with sv_enforceGameBuild 3095.
MariaDB or MySQL. MariaDB is the common choice on Linux boxes and behaves fine with everything ESX does.
oxmysql, the database wrapper. ESX does not talk to MySQL directly.
OneSync enabled. set onesync on is not optional — it has been required since Legacy 1.7.5.

The official config also sets set resources_useSystemChat true, which pulls the chat resource from the artifacts rather than a bundled copy. Leave that alone unless you're replacing chat entirely.

Worth deciding now, not later: which inventory and which UI layer you're standardising on, because most paid resources you'll buy from a store like scripts-tebex.io assume one or the other.

Route 1: The txAdmin Recipe

For a fresh box, the recipe wins. Open txAdmin's setup page, pick ESX Legacy from Popular Recipes, and let it run.

The recipe is maintained by the ESX team in their own esx-recipes repository and indexed by Cfx.re. During setup txAdmin generates a random database name and injects it via a {{dbConnectionString}} placeholder, so you don't hand-edit credentials anywhere. Deployment pulls the core, imports the schema, writes a working server.cfg, and hands you a bootable server.

Two caveats. The recipe gives you the ESX team's opinion of a starter server, so audit what got installed before you build on it. And a deployment can stall on GitHub rate limits mid-download — if that happens, wait a few minutes and redeploy rather than patching the half-finished result.

Route 2: Manual Install from esx_core

Manual is the better teacher, and it's what you'll fall back on for upgrades anyway.

Download a tagged release of esx_core, not a snapshot of the default branch. Copy the [core] folder into resources, keeping the square brackets — that's a FiveM resource category, and it's what makes the folder-level ensure [core] line work. One ensure starts everything inside it.

That folder holds seventeen resources: es_extended itself, plus esx_identity, esx_multicharacter, esx_skin, skinchanger, esx_inventory, esx_loadingscreen, cron, esx_chat_theme, and the UI layer — esx_lib, esx_context, esx_notify, esx_progressbar, esx_textui, and the older esx_menu_default, esx_menu_dialog and esx_menu_list trio.

That UI split matters. Modern ESX ships its own esx_lib with context menus, notifications and text UI. The esx_menu_* family still exists for compatibility with older scripts, which is why you'll see both patterns in resources you buy.

Then import [SQL]/legacy.sql, set your convars, and ensure in order:

set onesync on
set mysql_connection_string "mysql://user:password@localhost/es_extended?waitForConnections=true&charset=utf8mb4"
set mysql_ui true

ensure oxmysql
ensure es_extended
ensure [core]

What the Database Actually Holds

Most guides stop at "import the SQL." Knowing the shape of these tables will save you hours later.

users is the spine. It keys on identifier, and carries group (default user), job (default unemployed), job_grade, plus accounts, inventory, loadout and skin. Those last four are longtext columns holding JSON, not relational data. You cannot join on them, and you cannot cheaply query "every player holding a lockpick" — that constraint shapes every analytics query you'll ever write against an ESX database.

jobs and job_grades define employment: jobs holds name, label, type and whitelisted; job_grades holds job_name, grade, name, label, salary and the two skin columns.

The rest: items for the item registry, addon_account and addon_inventory (with their _data and _items partners) for society money and stashes, owned_vehicles for player-owned cars, datastore for arbitrary per-player persistence, plus billing, licenses and user_licenses.

First Boot: Proving the Install Worked

Restart and read the console. If es_extended starts clean and oxmysql reports a connection, you're most of the way there.

Next, the permissions block. The shipped config does something that trips people up:

add_principal group.admin group.user
add_ace group.admin command allow
add_ace group.admin command.quit deny
add_ace resource.es_extended command.add_ace allow
add_ace resource.es_extended command.add_principal allow
add_ace resource.es_extended command.remove_principal allow

Those last three lines aren't decoration. They grant es_extended itself the right to manage principals at runtime, which is how a player's group column in the database becomes an actual in-game permission when they connect. Delete them and admin groups silently stop applying. Config.AdminGroups recognises owner and admin out of the box.

Give yourself access with add_principal identifier.license:<your_license> group.admin, then test. ESX registers around thirty-five commands, most bound to the admin group: /players, /coords, /car, /setjob, /setaccountmoney, /giveitem, /noclip, /tpm, /saveall, /refreshjobs and /refreshitems. If /car spawns you an Adder — its default vehicle — the core is alive.

Adding Your First Job, End to End

This is the real acceptance test. Two ways to do it, and you should know both.

The SQL route. Insert the job and its grades, then reload without a restart:

INSERT INTO `jobs` (`name`, `label`, `type`, `whitelisted`) VALUES
  ('towing', 'Towing', 'civ', 0);

INSERT INTO `job_grades` (`job_name`, `grade`, `name`, `label`, `salary`, `skin_male`, `skin_female`) VALUES
  ('towing', 0, 'trainee',  'Trainee',   25, '{}', '{}'),
  ('towing', 1, 'driver',   'Driver',    45, '{}', '{}'),
  ('towing', 2, 'dispatch', 'Dispatch',  70, '{}', '{}');

Then run /refreshjobs in console. ESX rereads the tables into memory — no restart, no dropped players.

The runtime route. ESX exposes ESX.CreateJob(name, label, grades, jobType) from a server script, where each grade is a table of grade, name, label, salary, skin_male and skin_female. Resources that ship their own jobs use this so installation is drag-and-drop instead of "run this SQL file." Worth knowing when you're evaluating a script's install quality.

Verify with /setjob <id> towing 1. If your job and grade label appear in-game, the framework, the database layer and the permission chain are all working together. That's a complete install.

Config Conventions That Save You Later

Core settings live in [core]/es_extended/shared/config/main.lua, with adjustments.lua, logs.lua and weapons.lua beside it.

The locale gotcha catches everyone. ESX resolves language in this order: the esx:locale convar, then txAdmin's own txAdmin-locale, then English. Leave esx:locale commented out and your server inherits whatever language txAdmin is set to — which is why servers sometimes boot in a language nobody chose. Set setr esx:locale "en" explicitly.

Other defaults to review before launch: Config.StartingAccountMoney gives every new character 50,000 in the bank, Config.PaycheckInterval pays every seven minutes, Config.OffDutyPaycheckMultiplier is 0.5, and Config.MaxWeight is 24. Ship those untouched and your economy is inflated before day one.

Leave Config.CustomInventory alone — it adjusts itself when ox_inventory is present. And keep your edits tracked in git, because every core update will ask you to merge them. If you'd rather not hand-configure a starter stack at all, prebuilt bundles from buy-tebex.io come with these decisions already made.

Common First-Day Errors

| Symptom | Actual cause |
|---|---|
| couldn't load resource es_extended | Double-nested folder (esx_core-main/[core]/es_extended) — FiveM can't see a manifest that deep |
| oxmysql auth or connect failure | Wrong quoting in the connection string, or localhost resolving to a socket where you meant TCP — try 127.0.0.1 |
| Resources error on boot, work after restart | Something is ensured above oxmysql; database layer goes first, always |
| Players stuck on a black screen | OneSync off, or spawnmanager missing |
| New job doesn't appear | Rows inserted but /refreshjobs never run |
| Server boots in the wrong language | esx:locale unset, inheriting txAdmin's locale |

When ESX Isn't the Right Call

ESX is the better pick if you want a large catalogue of ready-made resources and a job/society model that works out of the box. It's the wrong pick if your team writes most of its own code and wants stricter typing and a tighter core — that's where QBCore and Qbox pull ahead, and the resource ecosystem over at qb-tebex.io reflects that different design philosophy. Pick one and commit, because bridging two frameworks costs more than learning either. Get ESX installed, get one job working, then start buying scripts.