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

Every FiveM resource starts with a small but important file: fxmanifest.lua. It is not the part that makes your job system, vehicle pack, map, or UI exciting—but it is the part that tells FiveM what the resource contains and how it should be loaded.

If a script refuses to start, a browser UI appears as a blank page, or a streamed asset is missing after a restart, the manifest is one of the first places worth checking. This guide explains the moving parts without assuming you are already a Lua wizard.

The examples below describe common FiveM resource patterns, not a universal template for every framework or asset type. FiveM, its documentation, and individual resources can change over time, so this information is partly forward-looking and might not accurately represent current or future events or every project’s requirements. Always check the resource’s own documentation and the current FiveM resource manifest reference before editing a live server.

What a FiveM resource manifest does

A FiveM resource is generally a folder placed in a server’s resources directory. The manifest inside that folder identifies it as a resource and declares the scripts, files, dependencies, and optional metadata FiveM needs to know about.

In practical terms, fxmanifest.lua answers questions such as:

• Which scripts run on the server?
• Which scripts run on players’ clients?
• Which code is shared by both sides?
• Does the resource include an NUI interface?
• Which files must be available to clients?
• Does this resource require another resource to start first?

The manifest does not magically fix broken code or resolve every dependency issue. It is a loading declaration. Think of it as the resource’s packing list and launch instructions.

The smallest useful fxmanifest.lua

A very simple Lua resource can begin with this:

fx_version 'cerulean'
game 'gta5'

client_script 'client.lua'
server_script 'server.lua'

Here is what each line means:

• fx_version selects a manifest version. cerulean is widely used in modern FiveM resources.
• game states the target game. For standard FiveM resources, that is commonly gta5.
• client_script identifies code executed on the player’s game client.
• server_script identifies code executed by the server.

The corresponding folder might look like this:

my_resource/
  fxmanifest.lua
  client.lua
  server.lua

Once the resource is in the correct server resource location, the server configuration must start it, typically with an ensure my_resource entry. The precise folder arrangement and start order depend on the server’s setup, so do not copy a path from an unrelated tutorial and assume it matches yours.

Client, server, and shared scripts are not interchangeable

One of the most common beginner mistakes is treating client and server scripts as if they can do the same job. They cannot.

Client scripts

Client code runs on each connected player’s machine. It is usually responsible for presentation and local gameplay behavior: drawing markers, opening menus, handling key presses, spawning local effects, or communicating with NUI.

Because a player controls their own client environment, client-side values should not be treated as trustworthy proof of money, inventory, permissions, job status, or rewards.

Server scripts

Server code runs in the server environment. This is where authoritative decisions should happen: validating purchases, changing persistent player data, checking permissions, and awarding items or currency through your framework’s supported systems.

A healthy pattern is simple: the client requests an action, and the server validates whether that action is allowed before making the change. That approach also makes debugging easier, because your important decisions are not scattered across every connected player.

Shared scripts

Use shared_script for code needed on both sides, often configuration values, constants, or utility functions designed to be safe in both environments.

For example:

shared_script 'config.lua'
client_script 'client.lua'
server_script 'server.lua'

Keep secrets, privileged logic, and server-only framework calls out of shared files. “Shared” means clients receive it too.

Using file lists without breaking NUI or assets

Some resources need extra files delivered to clients. A browser-based NUI is the clearest example. Your manifest may declare an entry page with ui_page, then list the page and its supporting files using files.

A simplified example:

ui_page 'web/index.html'

files {
  'web/index.html',
  'web/app.js',
  'web/style.css'
}

If the page loads but its buttons do nothing, check the browser console and your NUI callbacks. If the page is completely blank or missing styling, check the paths and file names in the manifest first. Case sensitivity can matter depending on the environment, and a file that exists on a Windows development machine may still be referenced with the wrong capitalization.

For maps, vehicles, audio, and other streamed content, manifest requirements vary by asset type. Do not assume an NUI-style file list is enough for every pack. Follow the original creator’s installation notes and consult FiveM’s documentation for the relevant data-file or streaming format. A rushed manifest edit can leave players with invisible objects, missing audio, or an endlessly restarting resource.

Dependencies and load order: declare what you actually need

A resource may rely on a framework, library, target system, inventory, database bridge, or another shared utility. If the resource has a real hard requirement, its manifest can declare it with dependency or dependencies.

For example:

dependencies {
  'ox_lib',
  'my_core'
}

This is useful documentation, but it is not a substitute for proper installation. The named resources must still exist, be configured, and start successfully. Their own dependencies matter too.

Be precise here. Adding a dependency merely because another script on your server uses it creates unnecessary coupling. On the other hand, omitting a required library makes startup failures harder to understand. Read the resource’s official installation instructions rather than guessing based on familiar names.

Globs can keep larger resources readable

When a resource has many scripts, declaring every file one line at a time becomes noisy. FiveM manifests support wildcard patterns, often called globs, for matching groups of files.

For example:

client_scripts {
  'client/**/*.lua'
}

server_scripts {
  'server/**/*.lua'
}

This can be clean for an organized project with separate feature folders. The trade-off is that broad patterns can hide ordering problems. If one client file must load before another because it defines a value or function used immediately elsewhere, list those files deliberately or structure the code so that load order is no longer fragile.

For a small resource, explicit declarations are often easier to maintain. For a larger project, globs are useful when paired with clear folder conventions.

Five manifest mistakes that waste the most time

1. The manifest is missing or named incorrectly. A resource folder without a valid manifest is not a normal startable resource.
2. A script is assigned to the wrong runtime. Client-only game functions in server code, or server-only logic in a client file, will cause errors or unreliable behavior.
3. Paths do not match the actual folder structure. This commonly affects NUI files after a developer reorganizes a project.
4. A required resource starts later or is not installed. Check the console for the first dependency error, not just the last error that follows it.
5. Files are copied from different versions of a resource. Mixing a new manifest with old scripts—or grabbing a single replacement file from an unofficial repost—can produce confusing failures.

A safe workflow for manifest changes

Manifest edits are small, but they affect startup behavior. Treat them with the same care you would give a framework update.

1. Read the original resource documentation. Confirm the intended manifest format, dependencies, and supported framework version.
2. Back up the working resource folder. Keep a known-good copy before changing paths or loading declarations.
3. Change one thing at a time. If you revise the manifest, update scripts, and alter configuration in one pass, you will not know which change caused the break.
4. Restart and read the console from the first warning. The initial error often identifies a missing file or dependency; later errors may simply be consequences.
5. Test the player-facing feature. A resource that says “started” may still have a broken UI, missing stream, or failed callback.
6. Document local changes. A short note in your server repository or admin documentation will save pain at the next update.

What this means for creators preparing for bigger projects

Good manifest hygiene sounds unglamorous because it is. But it separates a resource that is easy to install, troubleshoot, and update from one that feels like a mystery box. Clear folder names, minimal dependencies, intentional client/server boundaries, and accurate installation notes all help server owners trust your work.

That discipline also travels well. The exact formats and tools used by future GTA modding ecosystems may differ, and no one should assume GTA VI will use FiveM’s current resource conventions. Still, creators who understand packaging, dependencies, asset delivery, and authoritative server logic will be better prepared to learn whatever comes next.

If you are building, testing, or looking for your next server addition, check out the available mod downloads on SixMods. You can also create a free account and join the SixMods Community Forums to compare notes with other players, server owners, and creators.