Why a FiveM resource refuses to start

A resource that will not start produces one of about six errors, and each of them points at a specific line in fxmanifest.lua that is missing or wrong. Once you can read the manifest, the errors stop being mysterious.

Cfx.re documents the resource manifest in full. This is the short version, organised by the failure rather than by the field.

"resource manifest is not valid"

The manifest has no fx_version line, or has one the current server does not recognise.

fx_version is a compatibility declaration, not a version number for your resource. It tells the runtime which set of behaviours to apply. Resources copied from a tutorial written three years ago declare an older one, and eventually the server stops accepting it.

The second cause is the filename. It is fxmanifest.lua. The older name was __resource.lua, and a folder containing the old name on a modern server is a folder the server will not look inside.

"resource does not support this game"

The games line is missing or lists the wrong one. A resource written for RedM declares rdr3; one for FiveM declares gta5. A manifest with no games line at all is treated conservatively and refused.

This is the error people spend longest on, because the resource works perfectly for the person who published it.

"attempt to index a nil value" on boot

The resource started. Something inside it ran before the thing it depends on existed.

Three separate ordering problems produce this, and they are worth telling apart:

• Script order inside the manifest. client_scripts and server_scripts load in the order listed. A file using a function defined in another file must come after it.
• Resource order in server.cfg. Covered by your ensure lines, not by the manifest.
• A genuine dependency. The dependency and dependencies entries exist so the server can refuse to start a resource whose requirements are absent, rather than starting it into a crash. Most third-party resources do not declare them, which is why so much of this is manual.

"no such file or directory" for a file that is right there

A file exists on disk but is not listed in the manifest, so the resource never loads it, or it is listed with a path that does not match the case on disk.

Linux servers are case-sensitive. Windows development machines are not. A resource that works locally and fails on the box is this, nearly every time, and it is one of the reliably confusing parts of moving from a home test server to rented hosting.

"could not find dependency" for something you have installed

The dependency line names a resource by its folder name, not by its display name or the name in its manifest. A resource renamed on disk (usually to strip a -main suffix from a GitHub download) stops satisfying anything that depends on it.

This is the one worth checking first after a batch install, because the fix is a rename rather than a debugging session, and the error names the folder it wanted.

The client and server split

client_scripts, server_scripts and shared_scripts decide where code runs. Putting a server script in the client list ships your server logic to every player who connects, which is both a bug and a disclosure.

If a resource handles money, inventory or permissions, check that list. This is the cheapest audit available on a roleplay server and it is not part of any standard security checklist, though it belongs with the rest of the basics.

escrow_ignore and encrypted resources

Paid resources are often shipped partially encrypted. The manifest may list files under escrow_ignore that remain readable. Everything else is not editable, and a "fix" you find on a forum that edits an encrypted file will not apply.

Knowing which of your resources are escrowed is worth writing down before you need it, because when one breaks after an artifact update you cannot patch it yourself: you wait for the author, and artifact updates break things on their own schedule.

The habit that prevents most of this

Add resources one at a time. Start the server. Watch the console. A batch of fifteen new resources produces a wall of errors that interact, and separating them afterwards costs more time than adding them slowly would have.

It is the same discipline that makes anything else on a server diagnosable, and the same reason nobody does it until they have lost an evening to a crash they could not trace.