Why fxmanifest.lua needs fx_version 'cerulean' and lua54 'yes' (what breaks without them, plus a template)

Open the fxmanifest.lua of almost any current script and the first two lines are the same:

fx_version 'cerulean'
lua54 'yes'

New script authors copy them without knowing what they do, then leave them out of their own resource and hit an error they cannot read. This post explains each line: what it is, why it is required, what breaks without it, and what a correct manifest for an ESX script looks like.

What fxmanifest.lua is

It is the "loading order" FXServer reads before starting a resource: which files run on the client, which on the server, where the NUI page lives, which resources it depends on, and which version of the rules it runs under. The two lines in question are the "rules" part. Before 2019 the file was called __resource.lua and declared its version with resource_manifest_version followed by a long GUID nobody could remember. fxmanifest.lua and fx_version replaced that with names people can read.

What fx_version 'cerulean' means

fx_version tells FXServer which generation of manifest rules this resource was written against. FiveM changes runtime behaviour over time and does not want old scripts to break on update, so behaviour is pinned to the version the author declares. The names are alphabetical:

There has been no version after cerulean since 2020. Every new resource uses this one value.

Leave fx_version out and FXServer does not know which rules to load with; the resource does not start and the console reports an invalid manifest. Use adamant with a modern NUI and the UI that relies on fetch or loads fonts and images over https misbehaves because the origin is still nui://.

What lua54 'yes' means

FiveM runs Lua on its own runtime (CfxLua), which defaults to Lua 5.3. Since 2021 a Lua 5.4 runtime is available, but it is enabled per resource with lua54 'yes', because 5.4 changes some behaviour (string-to-number coercion, integer overflow in for loops) and some old scripts would break if it were forced server-wide.

What Lua 5.4 gives you:

• Speed: a generational garbage collector and cheaper function calls. Scripts with tight loops (HUD, distance checks, zone polling) benefit visibly
• New syntax: local x <const> = 1 (a constant; assigning to it is a compile-time error) and local f <close> = ... (resources closed automatically when the scope ends)
• New functions such as coroutine.close, warn, math.tointeger, and a stricter utf8

Why "required" rather than "recommended": the libraries modern scripts depend on are written in 5.4 syntax and check for it. The most common example is ox_lib. The first lines of @ox_lib/init.lua are

if not _VERSION:find('5.4') then
    error('Lua 5.4 must be enabled in the resource manifest!', 2)
end

Because the runtime is chosen per resource, ox_lib having lua54 'yes' in its own manifest does nothing for you. Your script that does shared_script '@ox_lib/init.lua' needs lua54 'yes' in its own manifest, or you get that error at start. The same goes for ox_inventory, ox_target, qbx_core, and current ESX Legacy, whose es_extended manifest has declared lua54 'yes' from the start.

Symptoms when it is missing but the code uses 5.4 syntax: a load error like '=' expected near '<' pointing at a line with <const> or <close>, or attempt to call a nil value (field 'close') when calling coroutine.close.

And use_experimental_fxv2_oal 'yes'?

The third line usually seen next to them in ESX Legacy is

use_experimental_fxv2_oal 'yes'

It enables the newer, faster native invocation path (one-argument-list). Optional, safe for newly written scripts, and a measurable gain in scripts that call natives very often. If a native returning multiple values behaves oddly, disable this line first.

Example fxmanifest.lua for an ESX script

fx_version 'cerulean'
game 'gta5'
lua54 'yes'
use_experimental_fxv2_oal 'yes'

author 'X3D Developer'
description 'x3d_example: manifest skeleton'
version '1.0.0'

shared_scripts {
  '@es_extended/imports.lua',
  '@ox_lib/init.lua',
  'config/config.lua',
}

client_scripts {
  'client/*.lua',
}

server_scripts {
  '@oxmysql/lib/MySQL.lua',
  'config/config.license.lua',
  'server/*.lua',
}

ui_page 'html/index.html'

files {
  'html/index.html',
  'html/**/*',
  'locales/*.json',
}

dependencies {
  '/server:7290',
  '/onesync',
  'es_extended',
  'ox_lib',
}

Common mistakes:

• game 'gta5' is required. For RedM use game 'rdr3' and add the rdr3_warning line FXServer asks for
• Anything the NUI page opens (images, fonts, sounds) must be listed in files, otherwise it does not load even though the file exists (html/**/* covers the whole folder)
• Files holding server secrets such as config/config.license.lua must never be in shared_scripts, because shared scripts are sent to every client. Server only (every X3D script puts the license config first in server_scripts)
• dependencies entries like /server:7290 enforce a minimum FXServer version and /onesync requires OneSync. If unmet, the resource refuses to start with a clear message instead of failing quietly later
• Order in server.cfg still matters: es_extended and ox_lib must be ensured before any script that imports from them

FAQ

Do old scripts still on __resource.lua need converting? They still run, but rename the file to fxmanifest.lua, replace resource_manifest_version '...' with fx_version 'cerulean', and re-test the NUI.

Will adding lua54 'yes' break an old script? Usually not. The cases seen are code relying on automatic "10" + 5 coercion (5.4 still does it through string metamethods) and integer overflow in for loops, where 5.4 stops the loop instead of wrapping. Test before production.

Is lua54 'yes' on es_extended alone enough? No. It is per resource; every resource that uses 5.4 syntax or imports ox_lib needs its own.

A script I bought says fx_version 'bodacious'. It works, but it signals code untouched since 2020. Check its NUI and its compatibility with current ESX Legacy before relying on it.

Every free X3D script (for example ESX Legacy Core — X3D Build and X3D Phone) uses the manifest layout above; grab the real files from the free FiveM scripts post. Need a script written to spec: custom FiveM script development.