What OneSync actually is
In the original GTA Online networking model, the game uses a peer-to-peer style topology where one client is the "host" for a given entity and other clients trust whatever that host reports. FiveM inherited this. It works for 32 players, but it has two hard problems: the player cap is locked to the engine's native session size, and the server has no real authority over the world. A modified client can claim a vehicle teleported, that it has full health, or that it owns an object it never created, and the rest of the session believes it.
OneSync replaces that model. Instead of clients arbitrating state between each other, the server holds the authoritative copy of every networked entity and pushes relevant updates out to clients. There are effectively three states you will see referenced:
onesync legacy(sometimes written as the olderonesync_enabled): server-aware sync, but still capped near the original session size and missing the population and culling features.onesync on: the modern OneSync, which raises the player cap and gives you server-side ownership and the scripting API for it.onesync infinity: the same model plus the infinity feature set, which adds area-based culling of entities and population so the server can scale to large player counts without flooding every client with every update.
In current FiveM, when people say "OneSync" they almost always mean the modern onesync on or onesync infinity. Legacy is deprecated and you should not build a new server on it.
Why sv_maxclients above 32 forces OneSync
The convar sv_maxclients sets your slot count. The base game session only supports 32 players. The moment you set sv_maxclients higher than 32, the legacy peer model cannot physically address the extra players, so FiveM requires OneSync to be enabled. If you raise the slot count without enabling OneSync, the server will refuse to start or clamp you. This is the single most common reason people first turn OneSync on: they wanted a 64, 128, or 200+ slot server.
The practical cap with OneSync Infinity is much higher than 32. The exact number depends on your hardware, your resources, and how disciplined your scripts are, but the networking layer itself is no longer the limit.
How to set it up
OneSync is configured in your server.cfg with convars, and increasingly through the Cfx.re portal key settings, but the cfg approach is what you control directly. A minimal setup looks like this:
sv_maxclients 64
set onesync on
set onesync_population true
The onesync convar accepts one of three values: legacy, on, or infinity. You set the mode you want directly on that single convar.
For the infinity feature set on a large server you use:
set onesync infinity
set onesync_population true
Note that onesync is a single convar that takes a mode value: legacy, on, or infinity. There is no separate onesync_enableInfinity switch; you select infinity by setting the onesync convar to infinity, which turns on the culling and large-scale features. The authoritative reference is the OneSync page in the FiveM docs, because behavior can shift across artifact versions and your server build matters.
After you enable it, restart the server fully. OneSync is not something you can toggle on a running session.
Population and culling
onesync_population controls whether the server manages ambient population (peds, traffic, parked vehicles) as networked state. With it on, the server is aware of and can cull ambient entities. With it off, you reduce server load but lose server authority over population, which most roleplay and large servers do not want.
Infinity's culling is the part that makes scale possible. Rather than sending every client the full world state, the server only relays updates for entities within a relevant radius of each player. A player in Sandy Shores does not receive sync traffic for a chase happening downtown. This is what keeps bandwidth and client CPU sane at high player counts, and it is the practical reason infinity exists.
Entity lockdown
Entity lockdown is the security and integrity control that decides whether clients are allowed to create networked entities at all. It is set with:
set sv_entityLockdown strict
The convar is sv_entityLockdown and it takes one of three modes.
relaxed
The default-ish permissive mode. Clients can create networked entities freely, the same way the base game lets a client spawn a vehicle or object. This is the most compatible mode because almost every legacy script that spawns things client-side keeps working. It is also the least secure: a modified client can spawn entities the server never asked for, which is how a lot of entity-spam and crasher exploits work.
inactive
Lockdown is effectively off. Clients create entities and the server does not enforce ownership rules around creation. You generally do not want this on a public server; treat it as a compatibility fallback only.
strict
Clients are not allowed to create networked entities. Every networked vehicle, ped, and object must be created by the server using the server-side creation natives. Any client attempting to spawn a networked entity is denied. This is the recommended mode for a serious server because it closes off client-side entity spam entirely and gives the server true authority over the world.
The cost of strict is that it breaks any script that relied on the client creating entities. That is the trade you are making, and it is the single most common migration pain point.
Server-side entity creation
Under strict lockdown, scripts that need to spawn things move that logic to the server and use the server creation natives such as CreateVehicle, CreateObject, and CreatePed running in a server context, plus CreateVehicleServerSetter for vehicles where you need to set the model on creation. The server creates the entity, assigns it a network ID, and clients receive it through normal sync.
A simplified server-side vehicle spawn looks like this:
-- server script
RegisterNetEvent('myresource:spawnCar', function()
local src = source
local ped = GetPlayerPed(src)
local coords = GetEntityCoords(ped)
local veh = CreateVehicle(`adder`, coords.x, coords.y, coords.z, GetEntityHeading(ped), true, true)
-- hand the entity to the client or set it as their last vehicle
end)
The client asks, the server creates, the server owns. That inversion is the whole point of OneSync, and strict lockdown is what forces your codebase to actually follow it.
How OneSync reshapes script design
Three shifts matter when you build for OneSync, especially with strict lockdown.
First, entity ownership is server-first. You stop assuming the local client can spawn whatever it wants and start routing creation through server events. This is more code, but it is also auditable and exploit-resistant.
Second, network IDs become the currency. Across the network you pass NetworkGetNetworkIdFromEntity and resolve back with NetworkGetEntityFromNetworkId so client and server are talking about the same entity. Raw entity handles are local and meaningless across the boundary.
Third, you respect culling. Because infinity only syncs nearby entities, a client cannot assume an entity that exists on the server is currently streamed to them. If your logic needs to act on an entity far away, do it server-side or force-relevant it deliberately. Server scripts can use functions like SetEntityDistanceCullingRadius and routing-bucket controls to manage what is relevant.
Routing buckets deserve a mention here: OneSync lets you place players into separate routing buckets so they share a server but not a world state, which is how instanced interiors, apartments, and lobbies are built on a single server. That is only possible because the server, not the clients, decides relevance.
Performance reality
OneSync Infinity does not make a badly written server fast. Culling reduces wasted sync traffic, but every networked entity the server tracks still costs CPU on the main thread, and FiveM's server tick is largely single-threaded for sync. The biggest real-world performance wins on a OneSync server come from the same discipline as any FiveM optimization work: keep entity counts bounded, delete entities you no longer need, avoid per-frame loops in resources, and do not let scripts leak networked objects. Infinity gives you the headroom to scale; your resources decide whether you actually use it.
The rule of thumb is simple. Enable OneSync because you need authority and scale. Enable infinity and culling because you have many players spread across the map. Set lockdown to strict because you want integrity. Then spend the rest of your time keeping entity counts low, which is where the frames actually live.