How to Install a FiveM Script: The Full Procedure

What "installing a script" actually means

A FiveM resource is a folder. Everything the server needs to know about it — what to run, what it needs first, what it ships — lives in one manifest file inside that folder, read by the server before any of the resource's own Lua, JS, or C# ever executes. Installing correctly is mostly about respecting that structure: one resource, one folder, one name, referenced consistently everywhere it appears.

Most installation failures aren't mysterious. They're one of a small number of sequencing mistakes — a dependency missing, an import skipped, an order reversed — that produce error text which looks like a broken script but is actually a broken procedure. This guide is that procedure, done in the order that avoids the mistakes.

The five installs that go wrong most often

In rough order of how often we've seen each one reported as "the script is broken":

• A resource nested inside another resource's folder instead of directly under resources/ — it never loads, and the server often doesn't mention it by name.
• SQL never imported, or imported against the wrong database — the resource starts clean and then errors the first time it actually touches the database.
• A dependency installed but started later in server.cfg — see our start-order guide for exactly what this looks like in console.
• An escrowed resource run on a server that never completed the purchase/entitlement step — the console error reads "You lack the required entitlement," which is an account issue, not a code bug.
• A resource added to server.cfg but never actually (re)started — it exists on disk and in the config file, but the running server has never been told to load it.

Reading the console like a checklist, not a wall of text

A clean resource start has a specific shape: a start line for the resource, and nothing alarming in the handful of lines directly after it. Anything reading "error," "nil value," "bad argument," or showing a file path and line number in that window belongs to the resource that just started, even when the message itself doesn't name it.

This is a triage skill, not a debugging skill — you're checking whether the install succeeded, not diagnosing why it didn't. If the console is genuinely unclear, that's what our debugging playbook is for; this guide only needs you to notice that something's wrong.

SQL import, done in a way you can trust

Read the .sql file before running it. You're looking for table names that might already exist from something else you've installed, and for anything that looks like it alters or drops existing data rather than just creating new tables. Import with a client that reports errors line by line — a silent import that fails halfway through is indistinguishable, at a glance, from one that succeeded.

Never run an unread migration or import file against a database you can't afford to lose. Our database and update-checklist guides cover backup and migration discipline in full; the install-time version of that discipline is simply: read it first, back up first, import once.

A pre-flight checklist before calling it done

• Resource folder sits directly under resources/, named to match server.cfg exactly.
• Every dependency in fxmanifest.lua is installed and confirmed running.
• SQL imported and spot-checked (the new tables exist and aren't empty when they shouldn't be).
• ensure line added after every dependency, and the resource has actually been (re)started since.
• Console shows no errors in the lines following the resource's start.
• The feature itself works in-game — not just "no red text."