FiveM OneSync and Player Slots Explained (2026 Guide)

If you have ever tried to run more than 32 players on a FiveM server without OneSync, you already know the hard limit. OneSync is the technology that lifts that cap — but it is far more than just a slot counter. It changes how the entire server handles game state, entity ownership, and script execution.

This guide explains what OneSync actually is, how to enable it correctly in your server.cfg, which slot tier makes sense for different server types, and what the real performance implications are for roleplay servers.

What Is OneSync?

In standard GTA Online, game clients sync state directly with each other in a peer-influenced model. FiveM's OneSync replaces this with a server-authoritative model: FXServer itself owns and validates all entity state (players, vehicles, peds, objects). Clients send updates to the server, which then relays authoritative state back. This approach is what makes large player counts possible and is also what allows server-side scripts to reliably read and manipulate the world.

OneSync Modes: Legacy vs On

FiveM has had multiple OneSync modes over the years. In 2026, there are two relevant values you might see in server configurations.

• set onesync on — the current full OneSync system. Server-authoritative, supports up to 2048 slots, required by modern scripts. This is what you should use.
• set onesync legacy — a partial backward-compatibility mode. It provides some OneSync features but is intended for old scripts that break with full OneSync. Avoid this for new builds.
• No onesync set — runs in the classic non-OneSync mode. Hard cap of 32 players. Many modern scripts will not work or will behave incorrectly.

How to Enable OneSync

Enabling OneSync is a single line in your server.cfg. Add it before your resource ensures and before sv_maxclients.

set onesync on
sv_maxclients 64

After adding these lines, restart your server. Check the FXServer console on startup — you should see a line confirming OneSync is active. If you see warnings about scripts not being compatible with OneSync, those are old resources that need updating.

Player Slot Limits Explained

sv_maxclients sets the maximum number of players who can be connected simultaneously. With OneSync on, the technical ceiling is 2048. Without OneSync, the ceiling is 32. The right number for your server depends on your hardware, your network, and the type of roleplay experience you want to deliver.

Server-Authoritative Model: What It Means for Scripts

When OneSync is active, the server is the source of truth for all entity state. This has important implications for how scripts work. Server-side scripts can reliably read the position and state of any entity in the world, not just those near a specific player. NPC and vehicle state is tracked server-wide. This is why modern frameworks like ox_inventory, ox_lib, and qbx_core all require OneSync — they depend on server-side entity ownership to function correctly.

Entity Culling and Population Radius

OneSync also implements entity culling — players only receive sync data for entities within a defined radius of their character. This is what makes large slot counts physically possible without saturating every client's network connection. The server manages which entities each client needs to know about, rather than broadcasting all state to all players.

Choosing the Right Slot Count for Your RP Server

There is a common mistake among new server owners: setting sv_maxclients as high as possible to look impressive in the server browser. In practice, your slot count should match your realistic peak player count and your actual hardware capacity. A 128-slot server that runs smoothly at 80 players provides a better experience than a 256-slot server that lags at 100.

• Serious whitelisted RP (economy, jobs, crime, court): 32–64 slots is ideal. Fewer players means more meaningful interaction and less load on your economy scripts.
• Semi-serious RP with open registration: 64–128 slots gives room to grow without over-committing hardware.
• Large public servers (Miami ghetto map, NYC map, 100k or die packs): 128–256 is realistic if your hardware supports it and your community is active.
• Start lower and increase: it is easy to raise sv_maxclients; recovering from a lag-plagued launch reputation is harder.

Performance Implications of OneSync

OneSync itself does not meaningfully increase CPU usage compared to non-OneSync at the same player count. The performance cost comes from the players themselves — each connected player generates sync traffic, triggers scripts, and consumes server tick time. Monitor your server using the resmon console command to identify which resources are consuming the most CPU. With well-written scripts, a mid-tier dedicated server can comfortably handle 100–150 active players.

Common Issues When Enabling OneSync

• Scripts that use GetClosestVehicle or GetClosestPed in a server loop without OneSync may break — these natives work differently with the server-authoritative model.
• Old menu resources (e.g., esx_menu_default forks from 2019) may have sync issues. Update or replace them.
• If players see entities disappear unexpectedly, check if the relevant script is using entity migration correctly for the OneSync model.
• Always restart the server fully (not just resources) after changing the onesync setting.

Wrapping Up

OneSync is not optional for any serious FiveM server in 2026 — it is the foundation that modern scripts are built on. Setting `set onesync on` and choosing a slot count that matches your community size and hardware is one of the most impactful configuration decisions you will make. CRM Development's server packs come with OneSync pre-configured and tested, with slot counts tuned for each pack type — so you can focus on building your community rather than debugging sync issues.