You picked ESX, downloaded the files, dropped them in your resources folder, and the server still will not boot cleanly. That is the single most common support thread in ESX communities, and it almost never comes down to a broken script. It comes down to load order: something started before the thing it depends on.

Short answer: install oxmysql first, then the esx_core repository, import the legacy.sql database schema, and load resources in this exact server.cfg order: oxmysql, es_extended, then the [core] resource category. That single sequence, plus a correctly formatted mysql_connection_string, resolves most of the errors new ESX installs run into on first boot.

What ESX Legacy actually is

ESX Legacy is the actively maintained version of ESX, published under the esx-framework/esx_core repository on GitHub. ESX describes itself, on that same repository, as being used by more than 12,000 communities, and the core resource, es_extended, is currently on major version 1.13 in the framework's own fxmanifest.lua. It is the oldest of the mainstream FiveM roleplay frameworks and still the one with the largest library of ready-made scripts, which is why it remains a default starting point for new server owners.

The repository is not just es_extended. It ships a whole category of resources bundled inside a folder literally named [core], including esx_menu_default, esx_menu_list, esx_menu_dialog, esx_multicharacter, esx_identity, esx_loadingscreen, and several others. Understanding that structure matters, because it changes how you write your server.cfg.

Each of those [core] resources has a specific job, and none of them are cosmetic extras you can safely skip:

  • esx_menu_default, esx_menu_list, esx_menu_dialog: the shared menu system almost every other ESX addon script calls into.
  • esx_identity: the character-detail form (name, date of birth, and similar fields) shown before a player spawns in.
  • esx_multicharacter: the multi-character selection and creation screen, maintained as a separate submodule.
  • esx_loadingscreen: the loading screen shown while assets stream in on connect.
  • esx_notify, esx_progressbar, esx_textui: the shared UI primitives (notifications, progress bars, text prompts) that other ESX scripts expect to already be running.
  • skinchanger and cron: character appearance handling and a scheduled-task utility used internally by other core resources.

ESX also maintains a separate, official addons layer beyond [core], covering things like a police job, a banking system, and a vehicle shop. Those addons are optional by design, unlike anything inside [core] itself, which the framework assumes is present. Add them one at a time and restart between each addition; installing five addon scripts at once and then troubleshooting a single error across all five is far slower than confirming each one boots cleanly on its own first.

Prerequisites before you touch a resource folder

  • A working FXServer install with a recent artifact build. Cfx.re publishes this through its own txAdmin setup flow; see the official setting up a server with txAdmin guide if you have not gone through it yet.
  • A MySQL or MariaDB database server you can create a schema and user on, reachable from the machine running FXServer.
  • A free server license key from Cfx.re Keymaster, which every FiveM server needs regardless of framework.
  • OneSync enabled. es_extended requires it starting with ESX Legacy 1.7.5, and it is a standard requirement for any modern roleplay server regardless of player count.

Step 1: install oxmysql before anything else

es_extended's own fxmanifest.lua lists oxmysql as a direct dependency, and it loads its database client through @oxmysql/lib/MySQL.lua. That is not incidental. If oxmysql is missing, disabled, or starts after es_extended in your server.cfg, ESX cannot reach the database at all and every character-related feature fails immediately.

Download the current release from github.com/overextended/oxmysql, drop it into your resources folder, and set your connection string in server.cfg. Either format works:

set mysql_connection_string "mysql://user:password@localhost/esx_database?charset=utf8mb4"

Avoid special characters such as @ : / ? & = + $ # in your username or password. If your password contains one, it will silently break the connection string parser and produce a database error that has nothing to do with your credentials being wrong.

Confirm oxmysql actually connected before installing anything else on top of it. Start the server with only ensure oxmysql present and watch the console: a clean start prints no MySQL errors. If it fails here, fix the connection string or database availability first, since every ESX error later on that mentions the database traces back to this exact step.

Step 2: install es_extended and the [core] category

Clone or download esx_core into your resources folder. The repository uses git submodules, most notably esx_multicharacter, so if you clone it with plain git clone you need to also run git submodule update --init --recursiveafterward, or pull the full source zip from the repository's releases instead, which already includes everything.

Inside the repository you will find a folder named [core] containing es_extended itself alongside every resource listed above. Keep the folder and resource names exactly as they appear in the repo; FiveM matches server.cfg entries against the resource name declared in each fxmanifest.lua, not the folder path, so a renamed folder will not by itself break anything but a renamed resource folder that no longer matches what other scripts expect to ensure against will.

Step 3: import the database schema

The import file lives at [SQL]/legacy.sql inside esx_core. Older tutorials reference an es_extended.sql file; that filename does not match the current esx-legacy repository structure, so if a guide tells you to look for it, treat that guide as stale. Create an empty database matching the name in your connection string, then import legacy.sql into it before you ever start the server.

Step 4: get the server.cfg load order right

This is the part most first-time installs get wrong. The official esx_core repository ships its own reference server.cfg, and the resource section looks like this:

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

## Default & Standalone resources
ensure oxmysql

## ESX Legacy
ensure es_extended
ensure [core]

Note the sequence: oxmysql, then es_extended, then the whole [core] category. The file also sets sv_enforceGameBuild 3095 with a comment referencing the mp2023_02 content update, which is worth keeping in your own server.cfg unless you have a specific reason to target a different build. For the full official file, see it directly in the esx_core repository. If you want the general logic behind how FiveM parses category folders and resource order, Cfx.re's own introduction to resources page explains it directly.

Cfx.re publishes FXServer artifacts on more than one channel: a recommended build, tested and stable, and a newer optional or latest build that carries fixes and features ahead of the recommended promotion. For a live roleplay server, run the current recommended build. Move to a newer build only when a specific script or native you need actually requires it, and treat that as a deliberate, tested upgrade rather than a background update you forget about.

This distinction matters for ESX specifically because es_extended is built and tested against natives available in current builds. An artifact you downloaded months ago and never updated is the most common reason a fresh ESX install throws native errors on the very first boot, before you have added a single addon script.

First boot: what should actually happen

Start the server and watch the console. es_extended should log that it loaded successfully with no red dependency errors above it. Connect with a client, and esx_multicharacter should present a character creation screen, since that is the resource responsible for the first-spawn flow in ESX Legacy. If you never see that screen, the problem is almost always the database connection, not the character resource itself.

Before inviting anyone else, test a handful of basic ESX commands as an admin and confirm your job and money data actually persist across a restart. A server that boots but does not save data has an ESX install that looks finished and is not.

Run through this before you open the server to real players:

  • Create a character through esx_multicharacter and confirm it appears in the database afterward.
  • Give yourself a job with an admin command and confirm the job label and pay show correctly on reconnect.
  • Add and remove money from a player account, then restart the server and confirm the balance held.
  • Restart the server once with no players connected to confirm no resource throws an error on a cold boot, not just a warm one.

The three ESX errors almost everyone hits

Three failure messages account for the overwhelming majority of first-run ESX support requests.

"Native XXXXXXXX is not supported."This means your FXServer artifact build is behind what ESX Legacy expects. Fix it by downloading the current recommended build rather than an older "recommended" build you may have saved from a previous setup.

"ESX Multicharacter couldn't connect to the database."This is a connection string or database availability problem, not a multicharacter bug. Re-check the format against oxmysql's expected syntax and confirm the database server is actually reachable from the machine running FXServer.

"ESX = nil." This means you are running an outdated es_extended build against newer addon scripts that expect a current API. Update es_extended to the latest tagged release from the esx_core repository and the error clears.

Almost every ESX install that fails on day one fails at the same two points: something started before oxmysql, or the connection string has a character in it that should not be there.

Where a clean install stops being enough

Getting ESX to boot is the easy half. The harder half is making dozens of third-party scripts, jobs, and inventory systems coexist without silent conflicts, and that is where most first-time builds actually stall. Scoped ESX builds and compatibility work exist for exactly that gap, when a base install works but the stack on top of it does not.

If you are still deciding between ESX, QBCore, and Qbox before you commit resources to any of them, our framework fit comparison walks through the tradeoffs in more detail than a single install guide can.

The bottom line

ESX Legacy is not a complicated install once you respect the dependency chain: oxmysql before es_extended, es_extended before the rest of [core], and a correctly imported legacy.sql before any of it touches real player data. Most of what looks like an ESX bug on day one is actually a load-order or connection-string problem, and both are cheap to fix once you know where to look.