DEV Community: RPScripts

FiveM Script Database Migrations: What to Check Before You Install

RPScripts — Mon, 02 Nov 2026 13:53:11 +0000

Most FiveM script problems that show up a week after the install are not script bugs. They are database problems, and they are the reason a resource that looked perfect in the demo behaves strangely on your server.

Every serious FiveM script stores something: a player's job, a vehicle's fuel level, a business balance, a phone contact list. The question is what it does to your database before it does that, and whether it can undo it.

Three things a script can do to your database

1. Create tables. A lot of scripts create their own tables on first start, usually with a name prefix such as scriptname_ or esx_. This is convenient and it is also the reason two scripts can fight: if two packages use the same table name with different columns, the second install silently wins and the first script starts throwing "unknown column" errors.

2. Require you to import SQL. Older and more professional scripts ship a .sql file and expect you to import it. Read the file before importing. The important lines are the CREATE TABLE and ALTER TABLE statements, because they tell you exactly what the script expects to exist.

3. Migrate existing rows. This is the one that hurts. A script that updates its schema on start might run an UPDATE across your player table, for example when a job was renamed from police to lspd. On a fresh demo server that is invisible. On your live server it can rewrite data for hundreds of players while you are reading this sentence.

The check that takes two minutes

Before you install anything, ask three questions:

Does the script create tables, import SQL, or modify existing ones?
Does it use a table name that another script on your server might also use?
Does it need a database user with write access to tables it does not own?

If the answer to the third question is yes, run it on a separate database first. A dedicated test database is the cheapest insurance in FiveM: export your current one, import it into a second schema, point the test server at the copy and install there. If the script breaks the copy, it breaks nothing that matters.

Reading the error instead of guessing

When a script fails after the install, the console usually names the problem directly:

Unknown column 'x' in 'field list' — the table exists but the schema is older than the script expects. Import the newer SQL file or update the column.
Table 'x' doesn't exist — the script expected you to import SQL and did not find it.
Duplicate entry for a unique key — the script is trying to create a row that already exists, often because it ran twice during a failed start.

The static checker in the FiveM script tester catches the file-level problems before install, and the resource catalogue is separated per framework in all scripts, so you can compare what a package expects against what your server already runs.

A short checklist before you press install

Read the SQL, if there is any, and note every table name.
Check those table names against the scripts you already run.
Test the install on a copy of the database, not on the live one.
Keep the export from before the install. Restoring a schema takes seconds; rebuilding lost data does not.
Pair the install with a correct load order in your server.cfg, because a script that starts before its framework will fail on the first query it sends.

None of this is complicated. It is just easier to do before the install than after the first support ticket.

Loading screens in FiveM: why the first player to join sees a black screen

RPScripts — Sun, 01 Nov 2026 17:23:12 +0000

The loading screen is the first thing every new player sees, and it is also the first thing that breaks on a server that was working fine yesterday.

Most "my loading screen is stuck" tickets have the same shape: the resource starts, the player connects, and the screen stays black — or the player lands in the world without ever seeing it.

What the loading screen actually is

A loading screen is a NUI resource. The client loads an HTML page in an overlay while the server assembles the session: character data, inventory, framework state, spawn point. The screen you design is the visible layer over that wait.

Two separate things can therefore be wrong, and they look identical from the outside:

The design never renders. The NUI URL is wrong, the file name does not match, or the resource is not started before the client needs it.
The design renders fine, but the session never completes, so the screen stays up forever.

The second one is not a loading-screen bug at all. It is a broken database query, a missing framework resource or a failed event, and the loading screen is only where you notice it.

The three checks that resolve most cases

Is the resource started? ensure the loading screen in your server.cfg, before the resources that depend on it. A screen that is started after the join flow has already begun will not be shown for that player.

Does the URL match the file? The ui_page in the manifest points at a path inside the resource. A file that was renamed to index.html in a ZIP that unpacks to Index.html is a broken URL on a case-sensitive host, and it works perfectly on the author's Windows machine.

Does the client actually send the event? The standard flow is: the client asks the server for session data, the server answers with the player identifiers, and only then the client hides the screen. If the server never answers, the screen stays up.

What to check when it hangs

Open the browser console on the client with F8 developer mode enabled. You will see the NUI messages the resource sends. If you see the initial message but never the "hide" message, the screen is fine and the session is not.

From the server side, the first red line in the console is usually the real answer: a missing dependency, an undefined table in a shared script, a query against a table that does not exist yet.

Build it where you can see it

Designing a loading screen in a text editor means guessing how it looks at 1920×1080, at 2560×1440 and on an ultrawide. The RPScripts Loading Screen Builder lets you lay out the design in the browser, preview it against the messages FiveM actually sends while a player joins, and export a ZIP you can drop straight into a resource. The preview runs the exported files at the real resolution, and the "Simulate FiveM loading" mode sends the same messages the game sends, so the progress bar you see is the progress bar players will see.

You can also export the design as JSON and import it later, which is the difference between iterating on a design and re-implementing it every time.

A note on the "first join" case

The first player to join after a server restart often sees a longer wait, because the server is loading resources and the database is cold. If that is the only case where the screen is slow, the screen is not broken — the server is. Progress reporting helps, but the fix is on the server side.

Disclosure: this post is from RPScripts. The builder linked above is ours and free to use in the browser.

Is that FiveM script safe? What a backdoor scanner can and cannot tell you

RPScripts — Sun, 01 Nov 2026 17:22:39 +0000

Most "this script is a backdoor" claims you find in a Discord chat are unverified. The useful question is not whether a script is called a backdoor, but what its code actually does before you install it on a server that holds real money and real player data.

A static scanner can answer part of that. It cannot answer all of it, and knowing where the line is makes the result usable.

What a static scan can tell you

A scanner reads the files in a resource and looks for code that has no business being in a paid script. The patterns that matter on FiveM are specific:

Code hidden behind whitespace. A loader appended to an otherwise normal line, padded with spaces so that it sits far to the right of the visible editor area. It is invisible in a screenshot of the file and easy to miss in review.

Code downloaded and executed. load() or loadstring() applied to the body of an HTTP response. Whoever controls that web server controls your server, and the control changes the moment the domain expires or is sold.

Runtime-decoded payloads. string.char lists, escaped byte sequences, base64 or hex blobs that only turn into readable code at runtime. A reviewer cannot check what they cannot decode.

Reads of server secrets. sv_licenseKey, rcon_password, sv_tebexSecret, or a database connection string, inside a file that also sends HTTP requests. That combination is what a key-stealing loader looks like.

Requests to raw IP addresses. A script that only talks to a domain can be reviewed. A script that talks to http://185.220.101.7/... cannot be attributed to anyone.

Writes outside its own folder. SaveResourceFile into another resource, io.open in write mode, os.execute, io.popen. A resource that rewrites a different resource is doing something no legitimate script needs.

Executables in the archive. A .exe, .bat or .ps1 inside a FiveM resource has no runtime purpose. So do archive entries that would extract outside their folder.

The RPScripts FiveM Backdoor Scanner checks exactly this list. Drop in a resource ZIP, a category folder or your whole resources folder — it handles Lua files with every check and JS files with the hidden-code check, up to 300 MB. The scan runs in the browser and your files are not uploaded.

What it cannot tell you

Intent. A call to PerformHttpRequest might be a licence check, a heartbeat or an exfiltration. The scanner reports the call; it does not read minds.

What a remote endpoint returns. The dangerous part of a downloader is usually the payload, and the payload arrives after the scan. The scanner can show you that your server would execute whatever that URL returns. It cannot tell you what is served tomorrow.

Runtime behaviour. Static analysis reads code, not execution. A script that behaves differently depending on a date, a license value or the server name passes every static check and is still a backdoor.

Your server's own files. The scan covers the files you hand it. A resource that was already installed, modified in place, or replaced by a later update is outside it.

A workflow that holds up

Scan before you install, not after. The whole point is that the decision to install has not been made yet.
Scan the dependency chain too. A clean resource that depends on a dirty one is still dirty. The scanner accepts a whole resources folder for exactly this reason.
Keep a copy of what you installed. If a file changes later, you want to know which file and when.
Watch the console and the outbound traffic on a staging server first. A script that phones home at boot is visible in the first minute.
Do not store your Tebex or licence keys in a resource that can reach the network. Even for a legitimate script, this is a smaller blast radius.

Disclosure: this post is from RPScripts. The scanner linked above is ours and free to use in the browser. The findings are yours to verify — a scanner is evidence, not a verdict.

FiveM load order: why a script can start and still find nothing

RPScripts — Sun, 01 Nov 2026 16:48:28 +0000

The symptom

The resource starts. The console shows it as started. Then nothing happens: the menu never opens, the keybind does nothing, the chat command answers with silence.

This is usually not a broken script. It is a script that asked for something that was not there yet.

`start` and `ensure` are not the same

start qb-core
ensure my_housing_script

start starts a resource once, and errors when the resource is not found. ensure starts a stopped resource, or restarts one that is already running.

Both lines run in the order they appear, but only within the configuration block they live in. If a framework is started in one exec file and your scripts in another, the order between the two files is the order of the exec lines — and it is easy to get wrong without noticing.

The dependency list protects only what it lists

A resource with

dependencies { 'qb-core' }

waits for qb-core before it starts. That is a real guarantee, and it is the best fix for load-order bugs.

It is not a general guarantee. If your code calls an export of a resource you did not list, nothing waits for anything. The call returns nil, and in Lua that nil usually travels further than you expect: it becomes a missing field, then a failed if, then a UI that silently never renders.

List every resource whose API you call: ox_lib, your voice library, your map library, the notification library. If you call it, it is a dependency.

The usual order

A configuration that survives contact with a real server looks roughly like this:

Framework and database driver.
Shared libraries.
Resources that only extend the framework — jobs, housing, inventory add-ons.
Your own gameplay resources.

The RPScripts server.cfg Builder & Checker can review an existing configuration or generate an annotated starter. It runs in the browser.

Disclosure: this post is from RPScripts. The tool linked above is ours and free to use.

When the order is right and it still fails

Two more causes with the same shape:

OneSync. With OneSync enabled, networked entities, state bags and server-side natives behave differently than in single-player. A resource that expects a client-side entity will start fine and do nothing.

Restart-only success. If it works after a manual ensure but not after a cold start, the order is wrong. A resource that depends on state held by another resource must be restarted after that resource, not merely started once.

A short checklist

The console shows the framework as started before the resources that use it.
Every resource whose API you call is in your dependencies list.
ensure and start are used with intent, not interchangeably.
The same order works after a full server restart, not only after a manual start.
The first red line in the console is read before anything is changed.

FiveM dependencies: how to read the dependency list before you install

RPScripts — Sun, 01 Nov 2026 16:47:34 +0000

Every FiveM script comes with a dependency list. It is the cheapest compatibility check you will ever run, and most people read it too late — after the purchase, after the install, after the "Could not find resource" line in the console.

Here is what those lines actually mean, and how to check them before you install anything.

A dependency entry is a name, not a version

dependencies {
    'qb-core',
    'ox_lib',
    'oxmysql'
}

Three strings. The server reads them and does exactly one thing: it refuses to start this resource while one of those named resources is not running. That is the whole mechanism. There is no version check, no API check, no compatibility matrix.

Two consequences follow:

A dependency that exists but is three releases behind satisfies the check perfectly.
A dependency you renamed on disk breaks the check, because the comparison is a literal string match against the resource folder name.

Three kinds of dependency

Framework. es_extended, qb-core, qbx_core. This is the one that matters most, because a script written for QBCore does not run on ESX, and vice versa. The console usually stays quiet here: the script starts, calls an export that does not exist, gets nil back, and every button in the UI does nothing.

Libraries. ox_lib, qbx_lib, voruniverse_lib, pma-voice. Shared helper libraries that several studios depend on. Installing the script without the library produces the same symptom as a framework mismatch: no error, no feature.

Data layer. oxmysql, mysql-async. If the resource opens a database and this one is missing, the failure surfaces on the first query instead of at start.

The name is the folder name

The check compares the string in the manifest with the name of a started resource. If your server folder is called qb-core-old, or you have both ox_lib and oxlib, the manifest will not match. That is why "it worked for him" is not evidence: the other server probably has the exact folder names the script author wrote.

Check it before you install

Open the package, open fxmanifest.lua, and list the dependencies. Then, on your server, list what is actually started. Every name on the first list must exist on the second, with the exact spelling.

If you are buying rather than installing, this list is part of the compatibility answer: a script that targets qbx_core is not a script for a QBCore server, whatever the title says.

The RPScripts FiveM Script Tester does that read for you. Paste a resource ZIP, a single Lua file or the manifest text, and it parses the manifest, resolves the dependency list and reports the framework the resource targets. It runs in the browser; nothing is uploaded.

Disclosure: this post is from RPScripts. The tool linked above is ours and free to use. You can also read the manifest by hand.

A short checklist

Every dependency in fxmanifest.lua is started on your server, spelled exactly.
The framework dependency matches your framework, not the one the seller tested on.
Library dependencies are installed, not only the script itself.
The database driver named in the manifest is present.
A dependency you renamed will be renamed back, or the manifest edited to match.

Ten minutes with the manifest before the purchase saves an evening with the console.

FiveM server.cfg vs resources.cfg: the difference that breaks your server on restart

RPScripts — Sun, 01 Nov 2026 13:32:55 +0000

There is a specific moment in every FiveM server's life where it works on Tuesday and does not start on Wednesday, and nothing in the resource changed. The cause is almost always this: server.cfg and resources.cfg are two different files with two different jobs, and the order in which FiveM reads them decides what actually starts.

Let me clear up what each file does, then walk through the failure patterns I see most often.

What server.cfg actually does

server.cfg is the file you pass to the server binary. It is not a resource list, even though it often ends up containing one. Its job is to set the runtime configuration for the instance: your server name, the license key, the set and sets directives, the networking ports, and one or two exec calls.

A minimal server.cfg looks like this:

endpoint_add_tcp "0.0.0.0:30120"
set sv_projectName "My Server"
set sv_maxclients 48
set mysql_connection_string "mysql://user:pass@127.0.0.1:3306/mydb"
sets locale "de"
exec server.cfg

That last line is the part that matters for the rest of this article.

What resources.cfg actually does

resources.cfg is a resource list. It contains ensure directives and nothing else that belongs in a config file. Its job is to say which resources start, and in which order.

ensure mapmanager
ensure sessionmanager
ensure qb-core
ensure qb-policejob
ensure my-custom-script

This file is loaded by exec from server.cfg, or by exec from another exec'd file. The usual convention is a single exec server.cfg in the launch config, and that file does exec resources.cfg.

The order of operations, precisely

This is the part that causes confusion, so here is the sequence in full:

The server binary starts and reads the config you passed on the command line, usually +exec server.cfg.
Every set and sets directive in that file is applied immediately.
exec directives are processed. Each exec'd file is read and processed in turn.
Resources named with ensure are queued.
After the entire config tree has been read, the queued resources start, in the order they were queued.

Step 5 is the important one. Resources do not start as soon as their ensure line is read. They start after all configuration is done. Which means this is legal and does what you expect:

exec resources.cfg

And this is also legal, and does something completely different:

ensure qb-core
ensure my-custom-script
exec resources.cfg

Here the two ensure lines are queued before the exec, so they end up ahead of everything in resources.cfg. The ensure order that determines the startup order is the order of the queue, not the order of the file sections.

Failure pattern 1: the double exec

The single most common mistake I see is exec resources.cfg appearing twice, or appearing in both server.cfg and the command line.

# server.cfg
exec resources.cfg

# start command
+exec server.cfg +exec resources.cfg

Every resource gets queued twice. On the first pass resources start and register their exports. On the second pass the server tries to start them again, and depending on the resource you get one of three outcomes: a clean no-op, a console error about the resource already being started, or a genuine failure where the second start tries to re-create something that already exists.

If your server logs show resources starting twice, or a resource that works fine but whose events fire twice, this is the cause. Check the launch command first, then the config file.

Failure pattern 2: the config that never got loaded

The reverse problem. A resource reads a value from cfg that was supposed to be set in server.cfg:

local apiKey = GetConvar("rpscripts_api_key", "")

If server.cfg is missing the set rpscripts_api_key "..." line, the resource starts with an empty string and quietly does nothing. No error, no crash, just a feature that never activates.

The confusing part is that this often only shows up after a restart, because the developer had the value set in a local config that never made it to production. It also only shows up on the server that has the missing line, which is why it is hard to reproduce.

Two habits prevent this. First, keep every set directive in exactly one file, never spread across the launch command and the config. Second, after editing a config, check the effective values rather than the file: the server console exposes the running configuration, and a set you cannot find there is not set.

Failure pattern 3: ordering across framework and content

Within resources.cfg, order is dependency order. Frameworks first, then the libraries that sit on the framework, then your content.

ensure mapmanager
ensure sessionmanager
ensure qb-core
ensure qb-multicharacter
ensure qb-policejob
ensure qb-inventory

Get this wrong and you get the classic symptom: a resource that depends on qb-core starting before qb-core exists. It then fails to find the framework object, throws during initialization, and the server moves on without it. The resource is not in the dependency graph at all, so it never restarts by itself.

The robust fix is to declare dependencies in the resource manifest rather than relying purely on the ensure order:

fx_version 'cerulean'
game 'gta5'
description 'My custom script'
version '1.0.0'

dependency 'qb-core'

With dependency declared, the server starts the dependency first regardless of the order of the ensure lines. You keep the file readable for humans, and you get correctness from the manifest. Relying on file order alone works right up until someone reorders the file for tidiness.

Failure pattern 4: the resource that stops the line

One resource throwing during its own initialization can prevent later resources from starting. This is worth knowing because it makes a single broken script look like a whole server problem.

The symptom is a server that starts, prints the first handful of resources, and then goes quiet. You check each resource individually and they all work. The actual fault is usually a resource whose fxmanifest.lua has a syntax error, or which tries to read a database table that does not exist yet. That resource fails, and depending on how the failing resource handles its own error, the resources queued behind it never get their start.

A quick way to bisect this: start the server with only the framework, then add resources back in groups. The resource where the log stops is the one to fix.

A practical validation order

Before you trust a config, check it in this order:

Does server.cfg contain exactly one exec of the resource list, and does the launch command not also exec it?
Are all set values present in the file that is actually being read?
Does every resource that needs a framework declare it as a dependency in its manifest?
Do the ensure lines follow a sane order anyway, so the file reads correctly to a human?
Does the startup log show every resource you expect, exactly once, in a sensible order?

For step 5, and for the checks in step 2, the console is the source of truth, not the file on disk. A server that is currently running has a resolved configuration, and reading that is more reliable than reading your intent.

Where this bites hardest

None of this is exotic. It is the daily mechanics of running a FiveM server, and it is the reason so many "my script is broken" reports turn out to be a config problem rather than a code problem. The free script archive on RPScripts keeps known-good fxmanifest.lua files around for exactly this kind of comparison, and if you are validating a resource before you ship it, the script tester runs your manifest and Lua through the checks that catch most of the above.

If your server.cfg is more than a handful of lines, it is worth having it validated mechanically rather than by reading, because the failure modes above are all invisible in a diff. The server.cfg builder and checker parses the file, verifies that every exec target exists, and flags the duplicate-exec case before it costs you a restart. Once the config is clean, the next thing worth automating is the resource itself: a manifest validator and a Lua checker catch the errors that would otherwise show up as a broken server at 2 AM.

If you have hit the "works Tuesday, broken Wednesday" case, look at the exec structure first. It is the cause more often than not, and it is the fastest thing to check.

Debug a FiveM resource in three passes: configuration, code, then runtime

RPScripts — Thu, 22 Oct 2026 15:49:17 +0000

A resource can have valid Lua and still fail on a FiveM server. The server might not have discovered its folder, a dependency might be missing, or the code might expect a framework API your installation does not provide.

Treat these as separate checks. It makes the next change easier to choose and the result easier to explain.

Disclosure: this post is from RPScripts. The two browser tools linked below are ours and free to use. You can also follow the workflow manually.

Pass 1: Check what the server is being asked to start

Before editing code, write down the resource's exact folder name, required framework, dependencies and installation instructions. Compare that list with the resources actually installed on your test server.

Look for an accidental extra directory level after extracting a ZIP. The resource folder should contain its manifest; a download folder containing another folder containing the manifest deserves a closer look. Check path casing when moving files between Windows and Linux.

Read the active configuration, including any files it loads. Keep dependencies ahead of the resources that use them, according to the resource author's instructions. A line in server.cfg does not install a framework or create database tables.

The RPScripts server.cfg Builder & Checker can help review an existing configuration or create an annotated starter. It runs in the browser. A clean report cannot confirm that your resource files, database or license are correct; those still need a local check. Use placeholders when sharing configuration for support.

Pass 2: Inspect the resource before loading it into your server

Separate syntax problems from integration problems. A parser can identify malformed Lua, but it cannot establish that a database exists or that a particular vehicle appears correctly in the game.

For each resource, check:

Does the manifest reference the scripts and UI files you actually shipped?
Are client scripts and server scripts assigned to the intended side?
Do required dependency names match the installed folders?
Does an integration call an API supported by your installed framework version?
Does server code validate permissions and derive important values itself, rather than trusting values supplied by a client?

The RPScripts FiveM Script Tester accepts a resource ZIP, a Lua file or pasted code. Its static checks and CfxLua sandbox run in the browser. The separate "Open in RPScripts AI" action sends files to your account, so distinguish that optional action from the local checks.

Read the scope of the result. Simulated frameworks and events help isolate some failures, but game-world natives, OneSync and real database behaviour still require a real server. A successful simulation is one piece of evidence, not a deployment certificate.

Pass 3: Run one controlled test on a staging server

Back up the resource and configuration first. Use a staging server with the dependencies and framework version you intend to deploy.

The official Cfx server-command reference distinguishes these operations:

refresh rescans resource manifests so newly added resources can be discovered.
start resource_name starts a stopped resource.
ensure resource_name starts a stopped resource or restarts one that is already running.

That last distinction matters when other resources depend on state held by the resource you restart. Use a controlled maintenance or staging workflow instead of repeatedly issuing commands on a busy server.

Capture the first relevant server-console error and the corresponding client F8 output. Reproduce one action, change one cause, and repeat the same action. If it works, restart the staging server and test again: success after a manual start does not establish that a cold start has the right order.

Keep a short test record

Record the artifact version, framework and dependency versions, the action you tried, the result and the relevant log lines. Redact credentials before sharing anything.

Configuration checks answer whether the setup looks consistent. Resource checks answer what the code and simulation reveal. A staging test answers what happens in your actual environment. Keeping all three results makes support requests clearer and future updates easier to verify.

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

RPScripts — Thu, 22 Oct 2026 15:38:51 +0000

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:

fxmanifest.lua sits at the resource root, and is not secretly fxmanifest.lua.txt.
fx_version and game are present and spelled correctly.
Every path in client_scripts, server_scripts, shared_scripts and files exists with exact casing.
A glob in files matches at least one file — an empty glob is silent.
Dependencies are declared by folder name, not assumed.
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.

DEV Community: RPScripts

FiveM Script Database Migrations: What to Check Before You Install

Three things a script can do to your database

The check that takes two minutes

Reading the error instead of guessing

A short checklist before you press install

Loading screens in FiveM: why the first player to join sees a black screen

What the loading screen actually is

The three checks that resolve most cases

What to check when it hangs

Build it where you can see it

A note on the "first join" case

Is that FiveM script safe? What a backdoor scanner can and cannot tell you

What a static scan can tell you

What it cannot tell you

A workflow that holds up

FiveM load order: why a script can start and still find nothing

The symptom

start and ensure are not the same

The dependency list protects only what it lists

The usual order

When the order is right and it still fails

A short checklist

FiveM dependencies: how to read the dependency list before you install

A dependency entry is a name, not a version

Three kinds of dependency

The name is the folder name

Check it before you install

A short checklist

FiveM server.cfg vs resources.cfg: the difference that breaks your server on restart

What server.cfg actually does

What resources.cfg actually does

The order of operations, precisely

Failure pattern 1: the double exec

Failure pattern 2: the config that never got loaded

Failure pattern 3: ordering across framework and content

Failure pattern 4: the resource that stops the line

A practical validation order

Where this bites hardest

Debug a FiveM resource in three passes: configuration, code, then runtime

Pass 1: Check what the server is being asked to start

Pass 2: Inspect the resource before loading it into your server

Pass 3: Run one controlled test on a staging server

Keep a short test record

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

1. fx_version is missing or misspelled

2. The game line is absent

3. Path casing in client_scripts and server_scripts

4. lua54 is still in the manifest

5. dependencies instead of hoping for the best

6. escrow_ignore when the resource is sold

The two-minute pre-flight

`start` and `ensure` are not the same

1. `fx_version` is missing or misspelled

2. The `game` line is absent

3. Path casing in `client_scripts` and `server_scripts`

4. `lua54` is still in the manifest

5. `dependencies` instead of hoping for the best

6. `escrow_ignore` when the resource is sold