If you're new to running or developing for FiveM, the whole thing can feel like a black box — you drop scripts into a folder, add lines to a config, and somehow a multiplayer server appears. Understanding what's actually happening under the hood makes everything else easier: debugging, optimizing, and writing your own code. Here's how a FiveM server really works.
The client/server split
Every FiveM server has two sides, and almost every bug or feature involves the boundary between them.
The server runs on a machine somewhere (your PC, a VPS, or a host like ZAP-Hosting). It's the authority — it holds the truth about the game world: who has what money, which jobs players hold, what's in the database. Nothing a player *claims* is trusted until the server verifies it.
The client is each player's own game running on their PC. It handles what they see and do locally — rendering, input, animations, UI. But the client can be tampered with, which is why the server must never blindly trust it.
This split is the single most important concept in FiveM. When a player robs a store, their client says "I want to rob this" — but the server decides whether they can, gives them the money, and tells everyone else. If you write a script that lets the client decide how much money to give itself, cheaters will exploit it in minutes.
Resources: the building blocks
A FiveM server is really just a collection of resources. A resource is a folder containing scripts, assets, and a manifest file (fxmanifest.lua) that tells the server what's inside and how to load it.
Your framework (QBCore or ESX) is a resource. Your inventory is a resource. Every job, every map, every UI is a resource. The server starts them based on the ensure lines in your server.cfg, and load order matters — a script that depends on your framework must start *after* it.
Inside a resource, scripts are declared as:
- client scripts — run on each player's machine
- server scripts — run on the server
- shared scripts — run on both (useful for config and shared data)
How scripts communicate
Because client and server are separate, they can't just call each other's functions directly. They talk through events.
- A client triggers a server event:
TriggerServerEvent('myscript:buyItem', itemId) - The server listens, validates, and responds:
TriggerClientEvent('myscript:itemBought', source, result)
This round-trip is everywhere in FiveM. Understanding it explains a lot of "why doesn't my script work" moments — usually the event name is mismatched, or someone tried to access server-only data from the client.
For same-side communication between resources, FiveM also has exports, which let one resource expose functions to another.
The game thread and why performance matters
The client runs a game loop — a thread that ticks many times per second. Your scripts hook into this with CreateThread and control timing with Wait().
Here's the critical part: if your code runs work on every single tick without pausing, it steals time from the game itself, causing frame drops. This is the number-one cause of FiveM lag. A loop that checks something every frame when it only needs to every few seconds is wasting enormous resources. (We cover diagnosing this in our resmon guide.)
This is why "well-optimized" scripts matter so much — a good script sleeps when it has nothing to do, waking only when needed.
OneSync and player counts
Standard GTA V multiplayer caps at 32 players. FiveM's OneSync system re-architects how the server syncs the game state, allowing servers to run 64, 128, or more players. It shifts more authority to the server (good for anti-cheat) and is required for most modern roleplay servers. It's enabled in your server.cfg.
Putting it together
So the full picture: your server runs a set of resources, each containing client and server scripts. The server holds the authoritative truth; clients handle local presentation. They communicate through events, and everything is bound by the game thread's performance budget. OneSync raises the player ceiling.
Once this clicks, FiveM stops being a black box. You'll understand why scripts are structured the way they are, why server-side validation matters, and why performance is about respecting the game thread.
Ready to add quality resources to your server? At Viper Development we build scripts that respect all of this — proper client/server separation, server-side validation, and clean threading. Browse our FiveM scripts →