Client-side vs server-side in FiveM

Every FiveM script is split between two computers: the player’s game (the client) and your server. Getting the split right is what separates a script that works from one that works until the first cheater joins. The rule is simple once you see it, and it applies to every framework and every language.

Imagine 64 players. Your server script runs once. Your client script runs 64 times, once inside each player’s game, and each copy only knows about its own player and the world near them. That is the whole difference, and it explains the rest.

• Drawing markers, text, 3D prompts and HUD elements.
• Reading key presses and opening menus or NUI.
• Playing animations, sounds and particle effects for the local player.
• Checking whether the player is near something, to decide when to show a prompt.
• Spawning purely local, cosmetic things only this player sees.

• Money, bank balances, items and inventory changes.
• Reading and writing the database.
• Jobs, grades, licences and permissions.
• Rewards for completing anything — the server decides whether it was completed.
• Cooldowns and limits that must hold for everyone.
• Discord or webhook logging (so API keys never reach players).

A delivery job, done properly: the client reports what the player did, the server checks it and pays.

local DROP = vector3(-1037.8, -2737.4, 20.2)

CreateThread(function()
    while true do
        local sleep = 1000
        local pos = GetEntityCoords(PlayerPedId())
        if #(pos - DROP) < 3.0 then
            sleep = 0
            -- show a prompt here
            if IsControlJustPressed(0, 38) then -- E
                TriggerServerEvent('delivery:complete')
            end
        end
        Wait(sleep)
    end
end)

local DROP = vector3(-1037.8, -2737.4, 20.2)
local PAY = 250
local lastDelivery = {}

RegisterNetEvent('delivery:complete', function()
    local src = source
    local ped = GetPlayerPed(src)

    -- 1. Is the player really there? (OneSync gives the server positions)
    if #(GetEntityCoords(ped) - DROP) > 10.0 then return end

    -- 2. Cooldown so it cannot be spammed
    local now = os.time()
    if lastDelivery[src] and now - lastDelivery[src] < 60 then return end
    lastDelivery[src] = now

    -- 3. The server decides the amount
    -- e.g. exports.ox_inventory:AddItem(src, 'money', PAY)
    print(('paid %s to %d'):format(PAY, src))
end)

AddEventHandler('playerDropped', function()
    lastDelivery[source] = nil
end)

Notice what the client sends: nothing but “I think I finished”. Position, cooldown and amount are all decided on the server. Events are explained fully in FiveM events, and the security side in securing server events.

With OneSync enabled — the default on modern servers — the server tracks entities, so natives like GetPlayerPed, GetEntityCoords and GetVehiclePedIsIn work in server scripts. That is what makes the distance check above possible. Without OneSync the server knows very little, and validation is much harder. Entity ownership and network IDs explains how entities are shared.

A shared_script runs on both sides. It is ideal for configuration both sides need, such as coordinates or item names. Remember that a shared config is sent to every player: never put webhook URLs, API keys or database credentials in it — keep those in server-only files or server convars, as described in convars.