Complete Guide to fxmanifest.lua

If you have ever dropped a resource into your server's resources folder, added ensure to server.cfg and watched it fail to start, the cause was very often fxmanifest.lua. This guide walks through every directive you are likely to meet in real resources, explains what each one actually does at runtime, and ends with complete examples you can adapt.

What fxmanifest.lua is

A FiveM resource is a folder. The folder becomes a resource when it contains a file called fxmanifest.lua at its root. The server reads that file when the resource is started (or refreshed) and builds the resource's metadata from it: which game it targets, which files run on which side, what the client must download and which other resources have to be running first.

Despite the .lua extension, the manifest is not a normal script. Each line is a directive call — a key followed by a value — that the runtime collects as metadata. Lua's function-call syntax lets you omit parentheses, which is why directives look like server_script 'main.lua' rather than server_script('main.lua'). You can use either form, and you can use Lua tables to list several values at once.

The minimal valid manifest

fx_version 'cerulean'
game 'gta5'

client_script 'client.lua'
server_script 'server.lua'

That is a complete, working resource definition. Everything else in this guide is optional and exists to handle NUI, data files, dependencies, shared code, metadata and distribution.

fx_version

fx_version selects the manifest version, which controls which runtime features and defaults the resource gets. The versions you will see in the wild are adamant, bodacious and cerulean. Use cerulean for anything new: it is the current version and what every maintained framework resource declares. Older values still load, but there is no reason to choose them for new code.

game and games

game declares which title the resource is for: 'gta5' for FiveM, 'rdr3' for RedM, or 'common' for code that touches neither game's natives. A resource that genuinely supports both titles declares them with games instead.

-- FiveM only
game 'gta5'

-- Both FiveM and RedM
games { 'gta5', 'rdr3' }

RedM resources must additionally include the rdr3_warning directive with the exact acknowledgement string Cfx.re publishes; without it the resource refuses to start. Copy it from the official RedM documentation rather than retyping it.

client_scripts, server_scripts and shared_scripts

These three directives are the heart of the manifest. Each has a singular form (client_script) and a plural form (client_scripts); both accept either one string or a table of strings, and both can be repeated. What differs is where the code runs and who receives it.

shared_scripts {
  'config.lua',
  'locales/en.lua',
}

client_scripts {
  'client/utils.lua',
  'client/main.lua',
}

server_scripts {
  '@oxmysql/lib/MySQL.lua',
  'server/main.lua',
}

Including a file from another resource

A path that starts with @ points into another resource: '@oxmysql/lib/MySQL.lua' loads lib/MySQL.lua from the oxmysql resource into this resource's own script environment. This is how most database wrappers and libraries such as ox_lib ('@ox_lib/init.lua') are consumed. The referenced resource has to exist on the server, and it is good practice to list it in dependencies too.

Globs

Paths can contain wildcards: 'client/*.lua' matches every .lua file directly in client/, and 'server/**/*.lua' matches recursively. Globs are convenient during development, but the order in which matched files load is not something you control line by line, and any file added to that folder later will be loaded automatically. For distributed resources, explicit file lists are easier to reason about and easier to review.

Load order

Within a resource, scripts for each side are loaded in the order they appear in the manifest. That is why config files go first: a client or server file that reads Config.Something at load time will fail with a nil error if config.lua has not been loaded yet. Libraries included with @ follow the same rule — list them before the files that call them.

Between resources, order is decided by server.cfg (the order of ensure and start lines) and by dependencies: a resource that declares a dependency causes that dependency to be started first, and refuses to start if it cannot be.

files

files lists everything that is not a script but still has to reach the client: NUI HTML, JavaScript, CSS, images and fonts, plus game data files referenced by data_file. Scripts listed in client_scripts or shared_scripts are already sent to clients and do not need to be repeated. Forgetting to list an NUI asset is the most common reason a UI shows a blank page or loads without its styles.

files {
  'web/dist/index.html',
  'web/dist/assets/*.js',
  'web/dist/assets/*.css',
  'data/vehicles.meta',
}

ui_page

ui_page sets the HTML file the resource renders in the NUI browser layer. The file — and every asset it loads — must also appear in files. Resources built with a front-end bundler such as Vite typically point ui_page at the built index.html, not at the source folder.

ui_page 'web/dist/index.html'

ui_page can also be an http(s) URL, in which case the client loads the page from that server every time. That is occasionally used for hosted dashboards, but it means a third party decides what JavaScript runs inside your players' game at any moment — treat it as a red flag in any resource you did not write.

data_file

data_file registers a game data file with the engine so it is loaded as the right kind of content: vehicle metadata, handling, weapon definitions, map type definitions and so on. It takes a type and a path, and the file itself must also be in files so clients download it.

fx_version 'cerulean'
game 'gta5'

files {
  'data/vehicles.meta',
  'data/carvariations.meta',
  'data/handling.meta',
}

data_file 'VEHICLE_METADATA_FILE'  'data/vehicles.meta'
data_file 'VEHICLE_VARIATION_FILE' 'data/carvariations.meta'
data_file 'HANDLING_FILE'          'data/handling.meta'

Model and texture files (.yft, .ytd and similar) do not need a directive at all: anything placed in a folder called stream is streamed to clients automatically.

dependencies

dependencies (or dependency for a single entry) lists resources that must be running before this one starts. Besides resource names it accepts runtime constraints that start with a slash, such as '/server:7290' for a minimum server build, '/onesync' to require OneSync, or '/gameBuild:3095' for a minimum game build. If any constraint is not met, the resource does not start and the console says why.

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

provide

provide declares that this resource can stand in for another one by name. oxmysql, for example, provides mysql-async so that older resources that depend on mysql-async keep working. It is a legitimate compatibility tool and also a way for one resource to put itself in another's place, so it is worth checking that a provide line matches what the resource honestly is.

lua54

lua54 'yes' opts the resource into the Lua 5.4 runtime. Lua 5.4 adds integer division with //, bitwise operators, const and close variable attributes, and generally better performance. On current server artifacts Lua 5.4 is the default runtime, but the line is still present in most maintained resources and remains necessary on older artifacts — leave it in if you use any 5.4 syntax.

lua54 'yes'

escrow_ignore

Resources sold through the Cfx.re asset escrow system are encrypted for the buyer. escrow_ignore lists the files that stay readable — normally configuration and locale files the buyer is expected to edit. It has no effect outside escrow, and globs are allowed.

escrow_ignore {
  'config.lua',
  'locales/*.lua',
}

From the buyer's side, escrow_ignore is also a map of what you are able to review. Everything else is encrypted, which is why escrow should not be mistaken for a security review — see our article on escrow and obfuscation.

Metadata fields

Any directive the runtime does not recognise is stored as free-form metadata. author, description, version and repository are conventional, and some update checkers read version through GetResourceMetadata(GetCurrentResourceName(), 'version', 0). They change nothing about how the resource runs.

author 'Example Studios'
description 'Garage system with NUI'
version '2.4.1'
repository 'https://github.com/example/garage'

Other directives you will run into

• loadscreen 'html/loading.html' — replaces the loading screen; loadscreen_manual_shutdown 'yes' lets the resource decide when it closes.
• this_is_a_map 'yes' — marks a map resource so the map manager treats it as one.
• exports and server_exports — legacy declarations of exported functions. Modern code registers exports at runtime with exports('name', fn), so new resources rarely need them.

A complete real-world example

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

author 'Example Studios'
description 'Player garages with a React UI'
version '2.4.1'

shared_scripts {
  '@ox_lib/init.lua',
  'config.lua',
  'locales/*.lua',
}

client_scripts {
  'client/utils.lua',
  'client/main.lua',
}

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

ui_page 'web/dist/index.html'

files {
  'web/dist/index.html',
  'web/dist/assets/*',
}

dependencies {
  '/server:7290',
  'oxmysql',
  'ox_lib',
}

escrow_ignore {
  'config.lua',
  'locales/*.lua',
}

Note the split between config.lua (shared, so the UI and client can read prices and labels) and server/config.lua (server only, for anything players must not see). That split is the single most useful habit in this guide.

Common fxmanifest.lua mistakes

Security considerations

The manifest is also the best starting point for checking whether a resource is safe to run, because it tells you which code executes with server privileges. A few rules follow directly from how the directives work:

• Secrets go in server-only files. Every client_scripts, shared_scripts and files entry is downloaded by every player, so a Discord webhook or API key in a shared config is public.
• server_scripts deserve the most scrutiny: that code can reach your database, your convars and the network.
• Globs, paths containing ../, a remote ui_page and unexpected provide lines are all worth a second look in a resource you did not write.
• Files that sit in the archive but are not referenced by the manifest are not loaded by the normal path — but check whether a script loads them some other way.

Best practices

1. 1Start every manifest with fx_version 'cerulean', the game line and lua54 'yes'.
2. 2List shared config first, libraries next, then your own code.
3. 3Prefer explicit file lists over globs in anything you distribute.
4. 4Keep one shared config for values the client needs and a separate server-only config for everything else.
5. 5Declare every resource and server build you depend on, so failures are loud and early.
6. 6Keep version accurate if you publish updates — it is the only version signal most server owners see.