Your FiveM resource won't load? Check these fxmanifest.lua fields first

Every FiveM server owner has seen it: ensure my_resource prints Could not find resource, or the resource starts and then does nothing. Before you touch a single line of Lua, check the manifest — most of these failures live there, and the console error rarely points at the actual line.

These are the six things I check first, in this order.

1. fx_version is missing or misspelled

fx_version 'cerulean'
game 'gta5'

No fx_version, no resource. It is not optional, it is not inferred, and a typo (fx_verison) gives you the same generic failure as a missing file. cerulean is the current value; older manifests use adamant or bodacious and still load, but there is no reason to start a new resource on a retired version.

2. The game line is absent

Without game 'gta5' the resource may load and then behave strangely: natives resolve, entities spawn, and nothing works the way it does in every tutorial you followed. Cheap to check, expensive to debug.

3. Path casing in client_scripts and server_scripts

The classic "works on my machine". You develop on Windows, where client/Client.lua and client/client.lua are the same file, and deploy to a Linux host where they are two different paths and only one exists.

client_scripts {
    'client/main.lua',   -- must match the real filename exactly
    'client/ui.lua'
}

Same rule for shared_scripts, files and server_scripts. If a resource loads but one feature silently never runs, suspect casing before logic.

4. lua54 is still in the manifest

lua54 'yes'

This flag does nothing today — every FiveM Lua script runs on Lua 5.4 and the manifest documentation marks the opt-in as deprecated. It is not the bug itself, it is a fossil: a manifest nobody has revisited. Where it shows up, look for the neighbours of an old setup — a __resource.lua that was renamed instead of converted, node_version values that no longer exist, or code that still assumes Lua 5.3 number semantics.

5. dependencies instead of hoping for the best

dependencies {
    'ox_lib',
    'oxmysql'
}

Without it, your resource starts in whatever order server.cfg happens to load, and every call into a dependency that has not started yet throws at runtime. Declaring dependencies makes FiveM refuse the start with a clear message instead of letting you debug a nil export at 2 a.m.

Two gotchas: the name must match the dependency's folder, not its display name, and an optional integration should not be listed — declare only what the resource cannot run without.

6. escrow_ignore when the resource is sold

If the resource is protected with escrow, any file a customer is supposed to edit — config.lua, locale files, framework bridges — has to be listed in escrow_ignore. Miss one and the customer edits a file that never executes, reports a bug, and nobody can reproduce it because the developer's own copy is unencrypted.

The two-minute pre-flight

Before every restart:

1. fxmanifest.lua sits at the resource root, and is not secretly fxmanifest.lua.txt.
2. fx_version and game are present and spelled correctly.
3. Every path in client_scripts, server_scripts, shared_scripts and files exists with exact casing.
4. A glob in files matches at least one file — an empty glob is silent.
5. Dependencies are declared by folder name, not assumed.
6. Escrow-protected resources list every editable file.

I got tired of checking this by hand, so I wrote a dependency-free linter that reads manifest syntax as text and never executes Lua: fivem-fxmanifest-lint. Python 3.10+, no third-party packages, no network access, non-zero exit code for CI.

For a quick check in the browser without cloning anything, there is a hosted fxmanifest.lua validator and generator.

Either way: fix the manifest first. Most of the time, the Lua was fine.