The FiveM 48-player limit and what OneSync changes

Where the 48 comes from

Two rules meet at 48. The first is technical. The server commands reference says sv_maxClients accepts 1 to 2048, but values starting at 32 need onesync set to on or legacy, and values above 64 need it set to on. Without OneSync, the game uses its original peer-to-peer model and the server only relays traffic.

The second rule is the license. According to the OneSync documentation, OneSync is free up to 48 slots. Above that you need a subscription on the Cfx Portal, starting from the tier called Element Club Argentum. The Cfx.re server issues page says the same: more than 48 slots requires Element Club Argentum or higher.

What OneSync changes

OneSync is Cfx.re's own sync system for GTA V. Instead of clients telling each other about the world, the server keeps the state of entities (players, vehicles, peds, objects) and decides which client gets which data. The onesync convar has three values:

• off: no state awareness. Clients use the game's peer-to-peer networking and the server is a relay.
• on: full state awareness and server-determined entity routing. This is the mode to use.
• legacy: a compatibility mode for scripts that expect every player to exist on every client. Cfx.re does not recommend it because of performance issues and graphical glitches.

On FiveM for GTAV Enhanced the choice is gone: it uses a client-server model, and OneSync big mode is the only mode.

Infinity and culling

OneSync Infinity is the part that makes large servers possible, and onesync_enableInfinity is on by default. Cfx.re lists support for up to 2048 players and says there are servers with more than 1000 at once. It raised the limit on object IDs from 8192 to 65535 and added culling: clients do not create players or entities outside a focus zone of 424 units around the player. That is why the server, not the client, has to know about everyone, and why player loops have to run on the server.

License keys and going past 48

Every public server needs a license key from portal.cfx.re, set with sv_licenseKey. If you set up with txAdmin, the recipe deployer asks for it; on a plain FXServer it goes in server.cfg. A minimal block for a server up to 48 players, matching the example server.cfg:

# license key from portal.cfx.re
sv_licenseKey "your-license-key"

# server-side state awareness and entity routing
set onesync on

# the free limit
sv_maxclients 48

To go past 48, the server issues page lists three steps: use the latest server build, set sv_maxclients above 48 within your subscription tier, and restart.

# 1. update FXServer to the current recommended build
# 2. raise the slot count to what your subscription tier allows
sv_maxclients 64 # example value
# 3. restart the server

The setup guides also note a common mistake: if the console says no license key was specified, you are usually running the server from the wrong folder or without +exec server.cfg, so the key line was never read.

For a private test server there is sv_lan true. The reference says it makes the server LAN-only: it does not appear in the public server list and license key checks are skipped. It suits testing scripts on your own machine, not a server that players join over the internet.

Routing buckets

Routing buckets, added in server pipeline 3245, split one server into separate worlds. A player or entity in a bucket only sees players and entities in the same bucket, and each bucket has its own grid for population. Cfx.re suggests them for multi-mode servers, sessions or parties, and character selection screens. It explicitly says they are not meant for interiors.

Each bucket has a lockdown mode that controls what clients may create:

-- server-side Lua: put a player in bucket 1, a separate world
SetRoutingBucketEntityLockdownMode(1, "strict") -- clients cannot create entities
SetRoutingBucketPopulationEnabled(1, false)      -- no ambient population
SetPlayerRoutingBucket(source, 1)

What changes for your scripts

Moving a server from legacy or off to on breaks scripts that assume every client sees every player. These are the patterns Cfx.re recommends instead:

• Loop over players on the server. A client only knows players inside its focus zone, so a client-side loop over all players misses most of them on a busy server.
• Create entities on the server. Server-created vehicles, peds and objects stay under the server's control. Set the orphan mode so the server does not delete them.
• Use state bags to share data about an entity, instead of events sent to every client.
• Avoid the scope events. playerEnteredScope and playerLeftScope fire once for every player in scope on every enter and leave, so their cost grows with the player count. In the Cfx.re example, 32 players in one player's scope means 32 calls.
• Lock down entity creation with a strict bucket if clients have no reason to spawn things. Cfx.re presents this as the way to stop clients from spawning entities for malicious purposes.

-- server-side Lua: create the vehicle on the server and keep it
local vehicle = CreateVehicleServerSetter(GetHashKey("blista"), "automobile", x, y, z, heading)
SetEntityOrphanMode(vehicle, 2) -- the server will not delete it

What it costs the server

With OneSync on, the server does work that clients used to do: it holds every entity's state and decides what each client needs. More players means more of that work, and more of your own scripts running per player. Cfx.re does not publish hardware figures per player count, so treat any number you see online as a guess and measure your own server with your own resources.

A few convars trade accuracy for less work. Their defaults are below; change one at a time and watch the effect:

# OneSync convars with their default values
set onesync_enableInfinity true       # startup only
set onesync_distanceCulling true
set onesync_distanceCullVehicles false
set onesync_population true           # false: no NPCs spawn

• onesync_distanceCulling removes entities from sync when they are far away and out of view. Leave it on.
• onesync_distanceCullVehicles applies the same culling to vehicles. Cfx.re notes it can improve performance.
• onesync_population controls NPC spawning. Turn it off only if your server should have no ambient traffic or pedestrians. To switch population off in one place only, such as a character selection screen, use SetRoutingBucketPopulationEnabled on that bucket.
• On FiveM for GTAV Enhanced, sync updates are processed in parallel by default (onesync_multithreadedPacketProcessing), which Cfx.re says lifts the main limit on how many players a server can hold.

Script load grows with the player count, so check that the server holds up at its current slot count during peak hours before you raise it.

Checklist before you raise the limit

1. Look up how many slots your Cfx Portal tier allows, and subscribe before you change the config.
2. Update FXServer to the current recommended build.
3. Set onesync on. Anything above 64 slots requires it, and legacy is not recommended.
4. Search your resources for client-side loops over all players and for playerEnteredScope or playerLeftScope handlers, and move that logic to the server.
5. Watch the FXServer process's CPU use at your busiest hour with your real resources, not a fresh test server.
6. Raise sv_maxclients, restart, and check the slot count shown for your server in the server list.

FiveM on Evorxa

The FiveM hosting page lists Evorxa plans for FXServer: VPS plans with shared cores and VDS plans with dedicated high-frequency cores, which suit a server with many players and scripts. You get root access to install FXServer or txAdmin and to set every line in this guide; the Cfx.re license key and any subscription stay in your own Cfx account. Plans start at $2.99 a month, prepaid monthly, for six months or yearly, and servers run in one region, Eygelshoven in the Netherlands.

Sources

The facts in this guide come from these pages.

1. Cfx.re docs: OneSync
2. Cfx.re docs: Server commands (sv_maxClients, onesync)
3. Cfx.re docs: Server issues (48 slots)
4. Cfx.re docs: Setting up a vanilla server
5. Cfx.re: example server.cfg