FiveM server: how many players by RAM and CPU?

"How much RAM do I need for 64 players?" is the question we hear most about FiveM. The honest answer is that it depends mostly on your resources, not on the player count. A roleplay server full of badly optimized scripts can lag at 30 players, while a well-kept one handles far more on the same machine. This guide gives practical figures, explains what really uses resources and shows how to measure before upgrading.

1. What really uses resources on a FiveM server

• The main thread: much of the script work runs on one core, so a fast core matters more than many cores.
• Resources: each script that loops, queries the database or creates entities adds load, multiplied by the number of players.
• The database: inventories, vehicles, housing. A slow database blocks the scripts waiting for it.

RAM is mostly used to load resources, custom maps and cache, and it fills up over the hours, especially with added vehicles and MLOs.

2. Practical figures

These ranges assume a modern framework (ESX Legacy, QBCore or Qbox) and properly optimized resources.

3. OneSync: the key above 32 players

Without OneSync, a FiveM server is limited to 32 players. OneSync routes entity synchronization through the server, which lets you go much higher. Check your server.cfg:

set onesync on
sv_maxclients 64

Above 48 players, your Cfx.re licence key must be tied to a subscription that allows that number of slots.

4. The impact of frameworks and resources

5. Measure before upgrading

resmon 1            # client side, F8 console: CPU time per resource
profiler record 500 # server side: records 500 frames
profiler view       # shows the profile in the browser

• server thread hitch warnings in the console signal a tick that took too long.
• Heavy resources: one permanently above 1 to 2 ms on the server deserves to be optimized or replaced.
• RAM after several hours, not at startup: this shows your real need.

The full method is in FiveM server lag: how to find the cause.

6. The often forgotten database

• Host it on the same server or in the same data centre, never far away.
• Add indexes on searched columns, such as the player identifier or vehicle plate.
• Give MariaDB enough memory with innodb_buffer_pool_size. See securing MariaDB.

7. Gain capacity without changing server

• Replace heavy resources found with the profiler.
• Lengthen loops: a server script checking something every 100 ms instead of every frame uses far less.
• Clean up entities: abandoned vehicles and objects never removed.
• Optimize added vehicles and maps: reasonable textures and light models.
• Schedule a daily restart in txAdmin during quiet hours.
• Update server artifacts to a recent recommended build.

8. Plan for growth

1. Size for peak hours, not the average.
2. Keep a margin in memory and computing time: an extra resource or an event should not be enough to saturate the server.
3. Watch the trend every week in txAdmin: peak players, memory used and console warnings.
4. Upgrade before an event, not during it.

A visible server also attracts attacks, so see our FiveM protection and FiveM server plans.

Frequently asked questions