How FiveM works: client and server
You already know what FiveM is: a way to run your own GTA V multiplayer server with custom rules, jobs, and scripts. This lesson opens the hood. Every FiveM server is split into two halves that talk to each other constantly, and once you can see those two halves clearly, almost everything else stops being confusing. By the end you will be able to point at any feature and say which half does what.
The two halves: client and server
FiveM is built out of two pieces that run at the same time, in two different places.
The first piece is the client. There is one client for every player. It runs on that player's own PC, right next to their copy of GTA V. Its job is to draw what the player sees and to talk to the game itself, so it handles the camera, the screen, the keyboard and mouse, the cars on the road, and the menus that pop up.
The second piece is the server. There is only one server, and it is a single machine that stays on around the clock so players can join any time. The server does not draw anything. Its job is to be the one place that knows the truth: how much money each player has, what is in their inventory, what job they hold, who owns which house. When two players disagree about something, the server is right, because the server is the only place those facts actually live.
Hold onto that split, because it is the spine of everything: clients show, the server decides.
Vocabulary
- client
- The copy of FiveM running on a single player's PC. It draws the screen, reads the player's input, and shows them the game world. Every player has their own client.
- server
- The one always-on machine that all clients connect to. It holds the trusted state of the world and tells each client what to display. There is exactly one.
- runtime
- The part of FiveM that actually runs your code while the server or game is live. The server runtime runs your server code; the client runtime runs your client code. FiveM uses Lua 5.4 to run that code.
- native
- A built-in function FiveM hands you for free to talk to the GTA V engine, like spawning a vehicle or moving a player. You call natives instead of writing that low-level work yourself. You will use these constantly later.
- database
- A program that stores data so it survives restarts, like a giant labelled filing cabinet. The server uses one (usually MySQL) to remember money, items, and accounts even after the server turns off and on again.
What your code actually does
Here is the part that surprises new developers: most of your code is not the game. Your code is a set of instructions that the game obeys.
The server side of your code makes decisions. It says things like "spawn a car at this spot," "give this player five hundred dollars," or "open the shop menu for this player." That is it. The server does not paint pixels.
The client side of your code carries out the visible part. When the server says "spawn this car," the client is what actually puts a car on the street using the GTA V engine. When the server says "give this player money," the client is what updates the number the player sees on their HUD. The client turns decisions into something on screen.
And the player just experiences the result. They press a key, a request travels to the server, the server decides, the client renders the outcome, and the player sees a car appear or a balance go up. The whole loop usually finishes in a fraction of a second, so it feels instant. But under the hood it was always two halves passing messages.
A good way to picture it: the server is the referee and the client is the screen. The referee never touches the ball, but the referee is the one who decides whether a goal counts. The screen never decides anything, but it is the only thing the crowd actually watches. Take away the referee and players can cheat freely. Take away the screen and nobody can see the game. You need both, doing their own jobs.
The picture
Here is the whole system in one diagram. Read it top to bottom on the player's side, then follow the network line down to the server.
Player's PC Server (one machine, always on)
+-------------+ +----------------+ +---------------------------+
| GTA V | <--- | FiveM client | | FiveM server |
| engine | | + your | | + your server scripts |
| (draws the | ---> | client scripts| <====> | + MySQL database |
| world) | +----------------+ network| (the source of truth) |
+-------------+ ^ <======> +---------------------------+
you
(the player)The double arrows in the middle are the network: the constant back-and-forth of messages between each client and the server. The client and the GTA V engine sit together on the player's PC, so they talk to each other instantly. The server sits somewhere else entirely, holding the database, which is why anything that has to be remembered or trusted lives over there.
Resources: where your code lives
You do not drop your code loosely into FiveM. You package it into a resource.
A resource is just a folder of code that FiveM loads as one unit. Inside that folder you put your scripts, plus a small file called a manifest that tells FiveM which files to load and where each one runs. You will build a real resource in a later lesson, so do not worry about the manifest's contents yet. The only idea to lock in now is this: everything you add to a server is a resource. A custom shop is a resource. A job system is a resource. A whole framework like Qbox, ESX, or QBCore is a big resource, or a stack of them.
Think of a resource as a single Lego brick of features. Your server is the baseplate. You snap on a brick for the police job, a brick for the car dealership, a brick for the phone. Each brick is self-contained: its own folder, its own code. If a brick misbehaves, you pop it off and the rest of the build keeps standing. That is why FiveM servers are built from dozens of small resources instead of one giant blob of code.
Three places code can run
Inside a resource, every script you write runs in one of three places. You do not have to master this yet. Just meet the three names now, because the next lesson lives entirely here.
- Client side runs on the player's PC. It draws menus, reads key presses, and shows the world. It is fast and personal, but it cannot be trusted, because a determined player can tamper with their own PC.
- Server side runs on the server machine. It holds the truth, talks to the database, and makes the final call on anything that matters, like money or items.
- Shared runs on both sides. You use it for things both halves need to agree on, like a list of item prices, so you write that list once instead of twice.
Common beginner misconceptions
Two ideas trip up nearly everyone at the start, so clear them now.
The second misconception is thinking a feature lives on only one side. Almost every real feature has a piece on each side. Take a car shop. The menu the player clicks through is client side. The check for "can this player actually afford this car, and subtract the money" is server side. If you only build the client half, the shop looks great and gives away free cars to anyone, because nothing trustworthy ever checked the price. Train yourself to ask, for any feature, "what is the client half and what is the server half?"
Where does the trusted source of truth live, the client or the server?
The server. There is only one server and it holds the real data, like money, inventory, and jobs, in its database. The client runs on each player's own PC, which the player can tamper with, so the client can never be trusted with the final word. The client shows things; the server decides and remembers them.
Try it yourself
What you can do now
- Explain the two halves of FiveM: the client on each player's PC and the one always-on server.
- Say what each half does: the client draws and reads input, the server decides and remembers.
- Name the server as the trusted source of truth, and explain why the client cannot be trusted.
- Describe a resource as a self-contained folder of code that FiveM loads as one unit.
- List the three places code runs: client side, server side, and shared.
- Spot the client half and the server half of a feature like a car shop.
Next you will lock in the single most important mental model in all of FiveM, the line between client and server, in a lesson built entirely around it: "Client vs server: the mental model." Get that one into your bones and the rest of the course gets a lot easier.