FiveM server RAM: sizing by resources

A FiveM server needs 2 to 3 GB of memory for a freeroam, drift or racing server of up to about 32 players with a modest resource list, 4 to 6 GB for an ESX, QBCore or Qbox roleplay server of 48 to 64 slots, and 8 to 12 GB for a large roleplay server with hundreds of resources and well over 64 players. The number of slots is the weakest predictor in that sentence. FXServer's memory follows the resources you install and the state they keep, so a half-empty server running two hundred scripts uses more than a full one running forty, and a single badly written script can outgrow everything else on the server by the end of the day. Size by your resource folder, then prove it with numbers.

What FXServer keeps in memory#

FXServer is the server binary; the game logic you run on it is almost entirely resources. Memory comes from five places:

• The core server. Networking, the HTTP endpoint that serves files to clients, and the server-side game state. Small on its own: a stock server with the default resources idles in a few hundred megabytes.
• OneSync state. With OneSync on, the server tracks every networked entity - players, vehicles, peds, objects - and their state. More players and more spawned entities mean more state, and population settings decide how many ambient entities exist.
• Script runtimes. Each resource's server scripts run in a runtime: Lua (the default and by far the most common), JavaScript on a bundled Node/V8 runtime, or C# on Mono. Every resource with Lua server scripts gets its own Lua state with its own heap.
• What scripts hold. Player objects cached by the framework, inventories, job data, vehicle registries, phone messages, housing data and anything a script loaded from the database and kept. This is where most of the memory on a roleplay server lives.
• Streaming asset bookkeeping. Custom vehicles, maps, clothing and MLO interiors are served to clients from the server's cache folder. Their bulk is on disk and in transit, but the server indexes them at start, so very large stream folders lengthen startup and add some memory.

If you run txAdmin, it supervises the game server as a separate process and adds a little memory of its own. It is worth every byte, but it counts against the same limit.

RAM by server type#

Three things move a server up the table faster than players do.

1. Resource count and quality. A curated list of eighty well-written resources on a modern framework can use less than forty old ones copied from forums. Memory per resource varies by a factor of a hundred.
2. What the framework caches. Frameworks keep each connected player's data in memory, and some resources keep data for every character ever created, loaded once at start. A server with ten thousand characters in its database can be paying for all of them.
3. Uptime. Lua heaps and caches grow during the day. A server that starts at 3 GB can be at 5 GB eight hours later, and whether that is normal growth or a leak is the subject of a later section.

FiveM frameworks: ESX, QBCore and Qbox compares the frameworks themselves; for sizing they behave similarly, and the add-on resources around them decide the outcome.

Slots, OneSync and population#

Slots are set with sv_maxclients, and anything above 32 requires OneSync. OneSync moves entity ownership and state to the server, which is what makes large servers possible and what makes the server's memory track the entity count.

set onesync onsv_maxclients 64sv_entityLockdown strictensure oxmysqlensure qb-coreensure [qb]ensure [standalone]

What matters for memory here:

• Every networked entity costs state. Players, their vehicles, ambient traffic and pedestrians, props spawned by scripts, and anything clients create. A server with fifty players who each spawn a car and leave it costs more than one where vehicles are stored in garages.
• `sv_entityLockdown` controls whether clients may create networked entities themselves. strict blocks client-side creation entirely, which closes a classic abuse path where a modified client spams entities until the server is full of them. It is primarily a security setting, but on a busy server it is also a memory one. It can break older scripts that spawn entities client-side, so test it.
• Population. Ambient traffic and peds are networked entities too. Many roleplay servers reduce population density through a resource, both for performance and for gameplay; the server holds fewer entities as a result.

OneSync and player slots goes deeper into the entity side, and server.cfg explained covers every line around these.

Leaking scripts: the usual culprit#

Most FiveM servers that run out of memory are not too small. They have a resource whose memory only ever goes up. The pattern is almost always the same: a table keyed by player that is filled when someone joins and never cleared when they leave, a cache that loads every row it ever saw, or a loop that creates closures or timers faster than they end.

The classic fix is one handler:

local playerCache = {}AddEventHandler('playerDropped', function()    playerCache[source] = nilend)

Without it, every join for the life of the server adds an entry that is never freed. On a server with frequent reconnects that is thousands of entries a day, each holding whatever the script stored.

To find which resource is growing, measure each resource's Lua heap from inside. A small debug resource or a temporary line in a suspect script will do it:

CreateThread(function()    while true do        Wait(60000)        local mb = collectgarbage('count') / 1024        print(('[%s] Lua heap: %.1f MB'):format(GetCurrentResourceName(), mb))    endend)

collectgarbage('count') returns the current Lua heap of that resource in kilobytes. Leave it running for a few hours of normal play. A resource whose figure rises and falls is healthy; one whose figure only rises is leaking. Remove the debug line afterwards.

Measuring before you buy#

Four tools, in the order to use them.

1. The memory graph over a full day. A FiveM server climbs after start as players join and caches fill, then levels off. A line that keeps climbing until the next restart is a leak. A line that levels off near the limit is a server that is genuinely too small.
2. `resmon` on a client. Press F8 and run resmon 1. It shows each resource's CPU time and memory on that client. It does not show server-side cost, but resources that are heavy on the client are usually heavy on the server too, and client-side bloat is half of what players feel.
3. The server profiler. profiler record 500 in the server console captures 500 frames, then profiler view opens the result. It is a CPU tool rather than a memory tool, but a resource that dominates the profile is often the same one that dominates memory. FiveM server performance and resmon walks through reading it.
4. Per-resource Lua heap, with the snippet above, for the suspects the first three turned up.

What you will not get, if the server hits its memory limit inside a container, is a helpful error. The process stops and the log ends. On RE:NODE a server that reaches its memory limit is stopped and restarted clean rather than left to swap - so a memory problem shows up as unexplained restarts, often at roughly the same time of day.

Restarts, and why roleplay servers schedule them#

Most roleplay servers restart every six to twelve hours, usually at fixed times announced in game. It started as a workaround for exactly the memory growth described above, and it has stayed because it also clears ambient entities, resets scripts that drift into bad states and gives a predictable moment for updates.

txAdmin has a restart scheduler built in: set the times in its settings and it warns players at intervals before each restart. That is better than a blind process restart because it gives scripts a chance to save, and frameworks save player data on drop.

A scheduled restart is a reasonable crutch, not a cure. If a server needs a restart every four hours to stay inside its memory, something is leaking, and the profiling steps above will find it faster than an upgrade will hide it.

Development servers and keeping two copies#

Most roleplay communities end up running two servers: the live one and a development copy where new scripts are tested before they reach players. Sizing the second is easy to get wrong in both directions.

A development server has few players, often just the developers, so it does not need the live server's headroom for a full evening. But it does need to load the same resource list, and since resources rather than players drive FiveM memory, a dev server with the full list idles not far below the live one. A 2 GB plan that cannot even start the live resource folder is no use for testing it.

The useful approach:

1. Size the dev server for the floor, not the peak. Start the live resource list with nobody online and note memory after every resource has started. The dev server needs that plus a margin, typically one tier below the live server.
2. Test new resources there first, with the Lua heap snippet running. A script that leaks shows itself in an afternoon of testing rather than an evening of players being disconnected.
3. Keep the database separate. Point the dev server at its own database, never the live one. A test script that wipes a table should wipe a test table.
4. Use the same server artifact. Memory and behaviour change between FXServer builds, so testing on a different build proves less than it seems to.

On RE:NODE each server has its own limits, its own panel and its own backups, so a dev server is simply a second, smaller plan. Subusers let developers reach the console and files of the dev server without access to the live one.

The database and the disk#

Roleplay frameworks lean on a database for characters, inventories, vehicles and properties. The database is a separate process with its own memory needs, and whether that counts against your game server depends on where it runs. A small roleplay database is comfortable in a few hundred megabytes; a large one with logs tables that nobody prunes grows without limit. FiveM database and oxmysql covers the connection string, slow queries and the tables worth pruning.

Disk is where streaming assets live. A server with a hundred custom vehicles, a dozen MLO interiors and a clothing pack can have a resource folder of 10 to 20 GB, plus the cache folder FXServer builds from it. Leave room for both and for a few server artifacts kept for rollback. MLO maps and streaming assets covers stream limits and why oversized assets hurt clients more than servers.

CPU: the other half of the question#

Memory is rarely what players feel first. FXServer runs scripts on one main thread, so a resource doing expensive work every frame delays everything else, and that shows up as desync and rubber-banding with memory nowhere near the limit. The server console prints a hitch warning when a server frame takes too long, which is the first thing to look for when players complain. One fast core for the main thread plus a second for networking and asset serving is the realistic minimum for roleplay. CPU or RAM: which one is holding your server back is the general method for telling the two apart.

FiveM plans on RE:NODE run from 2 GB to 12 GB, from $9 a month, with two port allocations and txAdmin available. Your Cfx.re key is entered on the Setup tab, because it is issued to your account, and moving up a tier raises the limits on the server you already have.

FAQ#

Is 4 GB enough for a FiveM roleplay server?

For a small roleplay server with a framework and a curated resource list, usually yes, up to around 48 players. A 64-slot server with a typical community resource folder is more comfortable at 6 GB. Watch a full day's memory graph before deciding; the end of the day is the number that matters.

Does FiveM use more RAM with more players?

Somewhat - each player adds entity state, network buffers and framework data. But resources dominate. Doubling players on the same resource list increases memory modestly; doubling the resource list can double it outright.

Why does my FiveM server's memory keep going up?

Usually a resource caching data per player and never clearing it, or loading more and more from the database over time. Measure each suspect's Lua heap with collectgarbage('count'), or restart resources one at a time and watch which restart frees the most memory.

Do custom cars and MLOs use server RAM?

Mostly they use disk and bandwidth, because the server streams them to clients from its cache. The server does index them at start, so very large stream folders add some memory and a longer startup. The bigger cost of heavy assets is on players' machines and connections.

How often should a FiveM server restart?

Most roleplay servers restart every six to twelve hours using txAdmin's scheduler, with warnings in game. That keeps memory flat and clears drifted state. If you need restarts more often than every four hours to stay inside the limit, a resource is leaking and should be found rather than restarted around.