FiveM fxmanifest.lua Explained: A Practical Guide to Resource Manifests

If you have opened a FiveM resource and immediately landed on a small file called fxmanifest.lua, you have already found the resource’s instruction sheet. It tells the FiveM runtime what the resource is, which scripts to run, which assets to include, and what other resources it needs before it can start.

That makes the manifest one of the best places to begin when you are building, installing, or diagnosing a FiveM resource. This guide explains the common parts in plain English, highlights mistakes that waste hours, and gives you a sensible way to read an unfamiliar manifest without randomly changing files.

What is fxmanifest.lua?

An fxmanifest.lua file is the current manifest format used by FiveM resources. It sits in the top-level folder of a resource and uses Lua-style syntax to declare metadata and files for the Cfx.re/FiveM runtime.

The manifest is not usually the place where a job system, vehicle handling setup, or user interface is actually programmed. Instead, it tells FiveM where those pieces live and how to load them. A resource without a valid manifest cannot be recognized and started normally.

Older resources may use __resource.lua. FiveM’s documentation identifies that as the legacy manifest format; for new work, use fxmanifest.lua. Do not casually convert a working older resource just because the format looks dated—read the creator’s installation notes and test any changes on a local development server first.

The smallest useful manifest

A simple resource might begin like this:

fx_version ‘cerulean’
game ‘gta5’

These lines are declarations, not comments.

• fx_version selects a manifest/runtime version. cerulean is widely used in current examples and documentation.
• game ‘gta5’ declares the target game for a standard FiveM resource.

The official Cfx.re resource manifest reference is the authority for supported directives and their current behavior. It is worth keeping open while developing because directives and runtime behavior can evolve.

Client, server, and shared scripts

Most script resources add one or more script declarations after the basic metadata. The important question is where each script should run.

client_script and client_scripts

client_script loads a script on each connected player’s game client. Client scripts are appropriate for local input handling, drawing UI prompts, client-side effects, and code that must interact with the player’s game session.

For multiple files, creators can use the plural form:

client_scripts { ‘client/main.lua’, ‘client/ui.lua’ }

Order can matter. If one file defines functions or values another file expects at load time, list the dependency first. That said, a clean resource should avoid turning load order into a mystery; keep related code organized and make dependencies explicit where possible.

server_script and server_scripts

server_script runs on the server, not on every player’s client. This is where authoritative logic belongs: validating purchases, updating persistent data, paying salaries, checking permissions, or deciding whether an action is allowed.

A fundamental FiveM rule is simple: never trust data merely because a client sent it. A client can request an action, but the server should validate the request before it changes money, inventory, permissions, or other important state. Putting a file in the manifest does not make its logic secure; the code still needs sound validation.

shared_script and shared_scripts

shared_script makes a file available to both client and server contexts. Shared files are often used for configuration, constants, item definitions, or utility functions that do not rely on client-only or server-only APIs.

Use shared scripts deliberately. A configuration file containing business rules can be convenient on both sides, but exposing sensitive information to every client is not a security strategy. Keep secrets and server-only validation on the server.

Files, user interfaces, and streamed assets

Some assets must be declared as files even though they are not Lua, JavaScript, or C# scripts. The files directive provides that list. A common example is a browser-based NUI interface:

ui_page ‘html/index.html’
files { ‘html/index.html’, ‘html/app.js’, ‘html/style.css’ }

ui_page points FiveM to the interface’s main HTML file, while files declares the files that must be available to that interface. If the HTML loads a stylesheet, JavaScript file, font, or image that was never included, the UI may appear blank or partially broken.

For custom assets such as maps, vehicles, or audio, packaging requirements vary by resource type. Do not assume every asset belongs under a generic files list or that every folder should be renamed to match a tutorial. Follow the documentation for the asset type and the original creator’s instructions. A resource can have a valid manifest and still fail because its actual data files are packaged incorrectly.

Dependencies: declaring what must start first

Many FiveM resources rely on a framework, library, database connector, targeting system, inventory, or another shared utility. The dependency or dependencies directive can declare that relationship.

For example, a resource may declare a dependency on another named resource so the runtime knows it is required. This is clearer than hoping a server owner notices the correct start order in a long configuration file.

Dependencies do not install missing resources, configure them, or guarantee that two versions work together. They only describe a requirement. Server owners still need to:

1. Install the required resource from its legitimate source.
2. Read its version and setup requirements.
3. Ensure it starts successfully.
4. Check framework-specific configuration and exports.
5. Test the dependent resource afterward.

If a resource depends on a framework but the framework is missing, renamed, stopped, or incompatible, the server console will usually give a more useful clue than the in-game symptom. Start with the first relevant error, not the last flood of follow-on errors.

A safe workflow for reading an unfamiliar manifest

When you download a legitimate resource, resist the urge to drag it into your server and hope for the best. Take two minutes to inspect the manifest first.

1. Confirm the resource folder. The folder containing fxmanifest.lua should be the resource root. Extra nesting after extracting an archive is a common installation mistake.
2. Read the metadata. Look for the author, description, version, and project links when they are provided. Metadata is helpful context, but the original download page and documentation remain the better source for installation instructions.
3. Identify the runtime files. Note the client, server, and shared scripts. If a file named in the manifest is absent, the package is incomplete or its folder structure has changed.
4. Check for dependencies. Write down each required resource and confirm the exact resource names. Renaming a dependency folder can break references.
5. Inspect UI and asset entries. A ui_page with missing HTML files, for example, is an immediate red flag.
6. Start it in a controlled environment. Test on a development server or during a maintenance window, watch the console, and keep a rollback copy of the prior working setup.

Common fxmanifest.lua mistakes

Using the wrong folder level

A server may show that a resource cannot be found even though its files are present somewhere in the resources directory. Usually, the manifest is one folder deeper than expected after extracting a ZIP archive. The server needs to see the resource folder that directly contains fxmanifest.lua.

Typos and incorrect paths

Paths in a manifest must match real files and folders. A single typo, changed capitalization, or old filename can stop a script or interface from loading. When updating a resource manually, compare the manifest with the actual package rather than copying only selected files.

Adding every file as a shared script

This is tempting when an error mentions a missing function. It is also a reliable way to create client/server context errors or expose code that should remain server-side. Put each file in the context it was designed for and resolve the actual dependency or import problem.

Editing paid or third-party resources blindly

Changing a manifest can make future updates harder, invalidate support, or breach the creator’s terms. Back up the original, document every change, and ask the creator or their support channel when a requirement is unclear. Never remove licensing checks or attempt to bypass escrow, access controls, or other protections.

Why this still matters as GTA VI modding develops

FiveM’s present resource model is an established GTA V ecosystem, not a confirmed blueprint for GTA VI. It is reasonable for creators to learn the habits behind manifests—clean project structure, explicit dependencies, reliable packaging, and server-side validation—because those practices transfer well across multiplayer modding work.

However, any claim about how GTA VI PC modding, server resources, or future Cfx.re tooling will work is speculative and might not accurately represent current or future events. Use current FiveM documentation for current FiveM projects, and wait for official platform guidance before treating today’s conventions as GTA VI requirements.

Make the manifest boring—in the best way

A good manifest is not flashy. It is readable, accurate, and predictable for the next developer or server owner who has to install the resource at 2 a.m. Keep file paths tidy, declare real dependencies, separate client and server responsibilities, and test changes before pushing them to players.

That small amount of discipline makes troubleshooting faster and collaboration much less painful. For more resources and community help, browse the available mod downloads or create a free account and join the SixMods Community Forums.