Client Server Architecture in FiveM: A Complete Guide

If you have ever played on a FiveM server and wondered how your character's actions are shared with every other player in real time, the answer lies in a concept called client server architecture. Understanding this system is the foundation of everything you will build as a FiveM developer, and getting it right from the start will save you countless hours of debugging later on.

In FiveM, scripts are split between two environments: the client and the server. Each side has its own responsibilities, its own limitations, and its own set of native functions. Knowing which code belongs where is not optional; it is essential for creating scripts that are stable, secure, and functional.

In this tutorial, you will learn exactly how the client server model works within FiveM, how communication happens between both sides, and how to structure your own scripts correctly. Whether you are writing your very first resource or trying to make sense of existing code, this guide will give you the clear, practical understanding you need to move forward with confidence.

What Is Client-Server Architecture in FiveM

FiveM is built on a client-server architecture, a computing model where a central server handles requests and manages resources while multiple clients connect to it simultaneously. In FiveM's case, that server is a dedicated process running on hosted hardware, responsible for game logic, database operations, and managing every resource installed on your server. Each player who connects runs their own client-side game instance locally on their machine. These two sides of the equation are always communicating, but they are never equal in authority or responsibility.

The Server Is the Authority

The server holds the single source of truth for everything that matters in your game world. It validates player actions, writes data to your database, and synchronizes game state across every connected player at the same time. If a player's client claims they have $1,000,000 in their bank account, that claim means nothing until the server confirms it against its own records. This design exists specifically to prevent manipulation. A modified game client can report anything it wants, but the server operates from its own verified state, independent of what any individual client sends.

What the Client Is Responsible For

The client handles everything the individual player sees and interacts with locally. UI rendering, animations, input detection, and visual feedback all belong to the client side. These operations run on the player's own hardware, which keeps the server from being overloaded with per-player presentation logic. The critical distinction is that the client cannot be trusted to make decisions that affect other players or persistent game data. Its role is to display and receive input, not to authorize.

Two Execution Contexts, One Resource

Every resource you install contains code that runs in one of two contexts: client-side (executes on each player's machine) or server-side (executes once on the dedicated server). Many resources contain both, with the two sides communicating through network events. Understanding this split is the foundational skill for any FiveM developer or server owner.

Misunderstanding which code runs where is, according to the client-server model, the root cause of the most common vulnerabilities in networked applications, and FiveM is no exception. In 2026, the majority of bugs, exploits, and performance problems reported by new server owners trace directly back to this confusion. Authoritative logic placed in client scripts becomes an open attack surface. Player-specific rendering logic placed on the server wastes resources and creates unnecessary synchronization overhead. Getting this right from the start is not optional; it is the foundation everything else is built on.

client.lua vs. server.lua: What Actually Runs Where

When you create a resource in FiveM, you are writing two fundamentally different kinds of code that live in separate execution environments. Understanding this distinction is the single most important concept you need to internalize before writing a single line of Lua.

client.lua runs on every connected player's machine, independently and simultaneously. This is not a figure of speech. If your server has 32 players online, the Lua runtime instantiates your client script 32 separate times across 32 different physical computers. Each instance is completely isolated from the others. A client script has access to GTA V's native functions for that specific player's game session, handles UI rendering, manages local visual effects, and controls what that individual player sees and interacts with. It has no direct visibility into what is happening on other clients or on the server itself.

server.lua, by contrast, executes exactly once inside the dedicated FXServer process. There is one instance, running on your host machine, with exclusive access to database connections (typically through libraries like oxmysql), server-side exports, authoritative player state such as balances and inventory, and the source variable that identifies which specific client triggered an incoming event. This is where your ground truth lives. If you need to know what a player actually owns or has earned, the server is the only place that answer can be trusted.

The fxmanifest.lua file is what enforces this separation. FiveM's resource system reads this file to determine which scripts load in which environment. The declaration is straightforward:

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

Without this file correctly configured, your scripts either will not load or will run in the wrong context entirely. You can learn more about how server-side Lua files are read and executed by reviewing the FiveM community discussion on server.lua execution, which covers real-world manifest patterns including shared config files and third-party database dependencies.

A practical example makes the boundary concrete. Displaying a player's cash balance on a HUD is client-side work; the UI drawing logic belongs in client.lua. However, the cash value itself must be fetched from the database and validated on the server first, then pushed to the specific client using TriggerClientEvent. The client never queries the database directly. For a deeper walkthrough of this pattern, this beginner-focused FiveM scripting guide explains the event-driven communication flow between contexts clearly.

Placing database queries or economy logic inside client.lua is one of the most exploitable mistakes a beginner can make. Client-side code runs on a player's own machine, which means a bad actor can inspect it, modify it, and replay crafted events to the server claiming whatever outcome they want. If your server trusts those events without server-side verification, your economy is compromised. Every sensitive operation, whether it involves money, inventory, or player identity, must be validated on the server before any result is applied or returned.

How Client and Server Communicate: Network Events

Now that you understand what runs on each side, the next critical concept is how those two sides actually talk to each other. FiveM provides a set of native functions specifically designed to send messages across the network boundary, and knowing which function to use in which direction is fundamental to writing any working script.

Sending Requests from Client to Server

TriggerServerEvent is the function you call inside client.lua when you need the server to perform an action on your behalf. The basic syntax looks like this:

TriggerServerEvent("myResource:buyItem", "water_bottle", 1)

This sends a named event upward to the server, along with any arguments you pass. Common use cases include requesting that money be added to a player's account, asking the server to spawn a vehicle, or submitting a form action from a UI. The key word here is "requesting." The client is not performing the action itself; it is asking the server to consider performing it. Before any server-side handler can receive this event, it must also be registered using RegisterNetEvent on the server side, which flags it as a legitimate incoming network event.

Pushing Data Back Down to Players

On the server side, TriggerClientEvent is the function used to send data back down to one or more players. The syntax requires a source parameter that controls targeting:

TriggerClientEvent("myResource:updateHUD", source, playerData)
TriggerClientEvent("myResource:serverAnnouncement", -1, messageText)

Passing a specific player ID targets only that individual client, which is appropriate for things like updating a personal bank balance or triggering a player-specific animation. Passing -1 broadcasts the event to every connected client simultaneously, which is useful for server-wide announcements, weather synchronization, or restart warnings. You should avoid using -1 for anything that contains player-specific data, since every connected client will receive that payload.

Security: Why Network Events Are the Most Common Exploit Vector

Every network event introduces latency and, more critically, a potential attack surface. Cheat menus can fire any registered server event with any arguments they choose. If your server-side handler simply trusts what the client sends without independently verifying it, an attacker can call your event directly and pass fraudulent values. A vulnerable handler might look like this:

-- UNSAFE: trusts client-supplied quantity without checking
RegisterNetEvent("shop:buyItem")
AddEventHandler("shop:buyItem", function(item, quantity)
 AddMoneyToPlayer(source, quantity * -10) -- no validation
end)

Proper event architecture means validating every incoming TriggerServerEvent call on the server side before acting on it. Check that the quantity is within an acceptable range, confirm the player has the required funds or permissions, and never assume the client-supplied data is honest. Additional safeguards include rate limiting with cooldown timers, payload sanitization, and using permission checks like IsPlayerAceAllowed before processing sensitive operations.

Shared Scripts and What Belongs There

Scripts declared in fxmanifest.lua as shared_scripts run in both the client and server contexts simultaneously. This makes them appropriate for constants, enumerations, and reusable utility functions that both sides legitimately need. However, because shared scripts are visible on both sides of the boundary, you must never place sensitive logic inside them. Pricing tables, rate calculations, admin permission checks, and anti-cheat logic all belong exclusively in server.lua. If that information lives in a shared script, a client can read it, which defeats the purpose of server-side authority entirely.

How Your Framework Choice Shapes the Architecture

The framework you build on is not just a stylistic preference. It is a structural decision that sets the ceiling on how well your server separates client-side and server-side logic before you write a single line of custom code. There is no single correct choice for every server: the right framework depends on the script ecosystem you plan to build on, since most paid and free resources target a specific framework's APIs. What is clear is that legacy frameworks carry architectural trade-offs that compound over time.

Why QBOX Enforces Better Server-Side Authority

QBOX was built by former QB-Core contributors who recognized that accumulated technical debt in the original codebase could not be resolved through incremental patches. Rather than continuing that effort, they forked the project and rebuilt core systems around the ox ecosystem, including ox_lib, ox_inventory, and oxmysql. This modular architecture routes sensitive operations through purpose-built, server-authoritative resources rather than bundling that logic into client-side code. In practical terms, that means the server retains control over inventory changes, economy transactions, and state updates, which significantly reduces the attack surface available to exploits. When you compare FiveM frameworks in 2026, QBOX consistently earns recognition as the most architecturally sound starting point for new builds.

The Problem with QB-Core's Client-Side Footprint

QB-Core was a meaningful improvement over ESX when it emerged, introducing a cleaner structure and better organisation. However, its architecture still pushes a meaningful portion of game logic to run on individual player machines. During early development this can feel efficient, because client-side code executes locally without a round-trip to the server. The hidden cost is a larger footprint of executable logic on machines you do not control, which creates more vectors for memory editing, event spoofing, and other manipulation techniques. Tested comparisons of all three frameworks confirm that QB-Core's core development has largely stalled as of 2026, meaning those structural patterns are unlikely to be resolved in future updates.

ESX as a Warning, Not a Starting Point

ESX dominated the FiveM space from roughly 2018 to 2022, and its large legacy install base means it still appears on a significant portion of active servers. For new builds in 2026, however, its aging architecture tells the real story. ESX ships without a modern inventory system, lacks native targeting and interaction tools, and relies more heavily on direct database calls in patterns that reflect older, less secure communication conventions. Starting a new server on ESX means inheriting those patterns and then spending development time working around them rather than building features.

Choosing your framework is ultimately choosing the baseline quality of every client-server interaction your server will ever handle. At FiveM Coach, done-for-you server builds are structured on current frameworks from day one, so clients are not starting their launch on a foundation that requires architectural workarounds before the server even opens its doors.

AI-Generated FiveM Scripts and the Client-Server Risk

The FiveM community's enthusiasm for AI-assisted development is not a minor trend. YouTube videos showing Claude AI generating FiveM servers and scripts accumulated 359K, 128K, and 96K views respectively across separate uploads in 2025 and 2026. That level of engagement signals that thousands of server owners and new developers are actively using AI tools to produce Lua code, often without a deep understanding of where that code needs to run. This is where a serious and underappreciated risk enters the picture.

Why AI Code Looks Safe but Isn't

AI tools are remarkably capable at producing Lua code that is syntactically valid, compiles without errors, and behaves correctly during basic testing. The problem is structural, not syntactic. Research from Georgetown University's Center for Security and Emerging Technology found that nearly half of all code snippets generated by five major LLMs contained bugs that were impactful and potentially exploitable. A separate study giving 80 coding tasks to 100 LLMs found that in approximately 45% of tasks, the model introduced a known security flaw into the output. These are not edge cases. They reflect a systematic weakness: AI models are primarily trained to produce code that runs, not code that is architecturally sound.

In FiveM, this matters enormously. The runtime separation between client.lua and server.lua is not something many AI models handle reliably. FiveM's fxmanifest.lua requires you to explicitly declare whether a script is a client_script, server_script, or shared_script. When an AI generates a full resource, it frequently defaults to patterns from its training data that do not respect this separation. The result is database calls using oxmysql landing inside client.lua, where they either silently fail or, worse, expose query logic to the client runtime. According to security research on AI-generated code vulnerabilities, this lack of architectural awareness is a defining failure mode of LLM-generated code across all platforms, and FiveM's niche Lua architecture makes it especially prone to misclassification.

The Three Most Dangerous AI Script Failures

Three categories of errors appear most consistently in AI-generated FiveM resources. First, database interactions placed in client-side scripts. Any MySQL query executed from client.lua runs in the player's game instance, meaning the query logic, table names, and potentially sensitive data are exposed to every connected client. Second, TriggerServerEvent handlers that accept arguments without validating the player source. A cheating client can call any registered server event with arbitrary parameters, and if the handler trusts that input, the result is money duplication, inventory manipulation, or privilege escalation. Research specifically flagging input validation as a critical gap in AI-generated code confirms this is not a FiveM-specific problem; it is a systemic AI weakness. Third, shared/config.lua files containing economy constants, item prices, or job payout multipliers that should never be readable by the client. These values are trivially accessible to anyone who knows how to inspect client-side Lua state.

Auditing Before Deploying

Before any AI-generated resource goes live on a player-facing server, every script file requires a structured context audit. The checklist is concrete: Does every database interaction occur inside a file declared as a server_script in the manifest? Does every AddEventHandler on the server validate the source parameter before acting on it? Does the shared/ directory contain only genuinely shared logic, with no economy-sensitive constants or permission data? Is any sensitive configuration data ever returned to the client through an event response? These questions sound simple, but a resource that passes casual playtesting can still be failing all of them, and the failure will not become visible until your server is actively exploited.

FiveM Coach's audit service is built specifically for this gap. It provides expert review of client-server separation, event security, and resource performance before a script is exposed to players, giving you the professional-grade assurance that AI tools, and basic testing, simply cannot provide on their own.

Hosting and Hardware: The Infrastructure Layer of Client-Server

The server side of the client-server model performs only as well as the physical hardware executing it. In 2026, the recommended minimum CPU specification for a viable FiveM server is 4 to 6 high-frequency cores with a modern architecture. Crucially, FiveM is primarily single-threaded, meaning one core shoulders the majority of the workload: processing player actions, executing resource scripts, handling entity synchronization, and managing database queries all compete on that single execution thread. This makes clock speed far more important than raw core count. Targeting a processor that reaches 4.5 GHz or higher on a single thread, using a modern architecture like a current-generation AMD Ryzen or Intel Core series chip, will deliver meaningfully better performance than an older server-grade processor with more cores but lower single-thread throughput.

RAM requirements scale directly with your player count and resource load, and undersizing memory is one of the most common mistakes new server owners make. A 20 to 30 player server with a standard framework stack needs a minimum of 8GB of RAM to operate without instability. Larger communities, or any setup running 50 or more custom resources, should target 16GB or more to maintain headroom during peak load. You can review a full breakdown of FiveM server requirements for 32, 64, and 128 player configurations to match your RAM allocation precisely to your planned player slots and resource count before you commit to a hosting plan.

Storage technology is equally non-negotiable. NVMe SSDs deliver read speeds between 3,000 and 7,000 MB/s, compared to roughly 100 to 150 MB/s from a traditional HDD. FiveM demands fast storage for resource loading at startup, local database operations, and map streaming to clients. A server running on an HDD will introduce noticeable lag during startup sequences and database calls, directly degrading the player experience your client-server architecture is designed to deliver.

Hosting tier matters just as much as raw hardware. Budget or oversold shared VPS environments introduce CPU steal time, where the underlying hypervisor reallocates your physical core to another tenant during peak demand. This causes tick rate drops and rubber-banding for your players. Dedicated hosting eliminates this contention entirely, giving your server process uninterrupted access to the resources it requires.

Finally, choosing a provider that specializes in game server or FiveM hosting is strongly advisable over generic cloud or web hosting. FiveM public servers are regularly targeted by DDoS attacks, and game-specialized providers configure their mitigation specifically for UDP game traffic patterns rather than standard HTTP traffic. Their support teams also understand FiveM-specific configuration challenges. Reviewing a complete guide to premium FiveM hosts in 2026 can help you evaluate which providers offer the network routing, protection configurations, and data center locations that match your player base geography.

Optimization Is Not a One-Time Setup Task

One of the most common mistakes new FiveM server owners make is treating optimization as a launch-day task. The server goes live, things seem to run smoothly, and optimization gets crossed off the list permanently. In practice, a FiveM server is a dynamic environment. As your player base grows and your resource list expands, the performance demands on both the client and server sides compound in ways that are invisible during initial testing but become painfully obvious under real load. As one 2026 optimization guide puts it, server performance is "an ongoing process, a symphony of careful configuration, strategic resource management, and intelligent software choices" that must evolve alongside the server itself.

Client-Side Problems and What They Look Like

Client-side performance failures stem from specific, identifiable causes. Scripts that run expensive logic every game tick, excessive world object spawning, and unthrottled NUI callbacks are the most common offenders. NUI interfaces built with frameworks that re-render constantly, or that send data to the UI every single frame instead of only on state changes, compound the client-side load quickly. These problems manifest first as frame rate drops, then as stuttering gameplay, and eventually as player disconnects when the experience becomes unplayable. A player who drops below 30 frames per second on mid-range hardware is not going to file a support ticket; they are going to leave.

Server-Side Problems and What They Look Like

On the server side, the failure mode is different but equally damaging. Blocking database calls are the most severe offender. A single synchronous SQL query that takes 200 milliseconds does not just slow down the player who triggered it; it stalls the entire server thread for every connected player simultaneously. This is why players often report freezes specifically when opening inventories or accessing bank menus. Event flooding, where TriggerClientEvent broadcasts to all players rather than targeted recipients, and server-side loops running at Wait(0) when a one-second interval would suffice, both erode server tick rate and produce desync between players.

Making resmon a Routine, Not an Emergency Tool

FiveM's built-in resmon command gives you a real-time view of CPU time and memory consumption per resource on the client side. For server-side resources, profile with FiveM's profiler or the monitoring built into txAdmin. Any resource consistently consuming more than 10ms or more than 100MB should be flagged immediately for review. The practical recommendation is to run a profiling session after every new resource addition and on a weekly cadence during active growth phases. A server with fewer than 150 active resources, where no single resource exceeds 3ms per tick, is operating within a healthy performance envelope. Waiting until players complain about lag before opening resmon means the damage has already been done.

Why Untested Scripts Are a Hidden Churn Driver

Adding a new script directly to a live server without isolated performance testing is one of the leading causes of unexplained lag spikes. A fresh server with a clean resource list runs well. The same server after accumulating 80 unvetted resources often does not. Players experience the result without understanding the cause, and they attribute the degraded experience to the server rather than a specific resource. The solution is to test new scripts individually in a staging environment, profile them under simulated load, and confirm they meet acceptable tick time thresholds before deploying to production.

This is precisely why FiveM Coach's implementation plans extend beyond the launch date. Post-launch performance guidance is built into the process because a server that performs well during setup but degrades under real player load does not retain players. Consistent performance under live conditions, not just in pre-launch testing, is what drives the stable, growing communities that server owners are actually trying to build.

Why Client-Server Architecture Directly Affects Player Retention

Everything covered in the previous sections builds toward one unavoidable conclusion: architecture is not an abstract technical concern. It is the direct cause of whether players stay or leave.

According to industry data, 34% of gamers quit a game entirely when latency is a persistent problem, and 42% play less frequently due to a server's lag. These are not edge cases. They represent a consistent pattern of player behavior that traces back to a single root cause: how well the client-server relationship is implemented. When the server is not authoritative over game state, when events are not handled correctly, or when client-side logic carries responsibilities it should never have, the result is a server that feels broken even when the code technically runs.

Exploitable client-side logic creates a second, compounding problem. When a server trusts the client to validate actions that the server should be controlling, it creates an opening for griefers and cheaters. These players are not difficult to attract; they actively seek servers with weak architecture. Their presence degrades the experience for legitimate players and accelerates churn specifically in the early stages, when a community is still fragile and every lost player is harder to replace.

Desync compounds this further. When two players see different versions of the same game world simultaneously, it is almost never a random glitch. It is a symptom of improper event sequencing or server tick-rate degradation, both of which are architectural problems with architectural solutions. A server that desynchronizes regularly will lose players regardless of how good the roleplay community or content offerings are.

The pattern observed across more than 2,000 server launches supported by FiveM Coach is consistent: servers built on a correct client-server architecture from day one retain players longer and require fewer emergency interventions in the first 90 days. That 90-day window is critical because it is when a new server's reputation is being formed.

Fixing architecture after launch is significantly more costly than building it correctly from the start, not just in development hours, but in the player trust that erodes while the problems are still live.

Conclusion: Build the Architecture Right From the Start

The core principle running through every section of this guide is straightforward: the client handles presentation, the server handles authority, and every single script on your server must respect that boundary without exception. Violating that boundary does not just create bugs; it creates security holes, desync issues, and performance problems that drive players away permanently.

Framework selection is an architectural decision, not a popularity contest. QBOX represents the strongest structural foundation for new builds in 2026, offering enforcement patterns that legacy frameworks simply cannot match, provided it fits the script ecosystem you plan to build on.

Your hardware and hosting choices are equally part of this architecture layer. If your server-side cannot process events fast enough due to underpowered hardware, the entire client-server model breaks down under load regardless of how clean your code is.

AI-assisted development is a powerful tool, but it is not a substitute for architectural understanding or expert review before deployment. Generated scripts require human verification against proper client-server boundaries every time.

If you want your server built correctly from day one, or need an existing server audited for client-server violations, FiveM Coach's Builder, Elite, and Enterprise plans provide done-for-you builds and expert scripting support backed by over 2,000 server launches.