RAM is the first thing people talk about in FiveM hosting, and it matters, but it is also misunderstood. Some servers run fine with modest RAM. Other servers crash with double the RAM because scripts leak memory or the CPU is weak.
This post gives you a simple way to choose a plan that works.
Table of Contents
- Why FiveM uses RAM
- The simple RAM ranges
- Why assets change everything
- When RAM is not the problem
- Matching RAM to hosting
1. Why FiveM uses RAM
FiveM loads resources, scripts, player data, and runtime state into memory. As players join and scripts do more work, memory usage increases.
If your server runs out of RAM, you do not always get a clean error. You can get freezes, timeouts, or sudden crashes.
2. The simple RAM ranges
If you run a small server with a light framework and minimal assets, lower RAM can work.
If you run a serious roleplay server with a full framework, many resources, and custom content, you need more.
If you want a safe starting point, plan for growth. A server that starts at 10 players often turns into 30 when things go well.
3. Why assets change everything
Custom cars, clothing, MLOs, and big maps increase memory usage. People focus on player count, but assets often matter more.
If you are adding big vehicle packs, be realistic. Your memory needs will jump.
4. When RAM is not the problem
If your server is laggy but RAM is only half used, your CPU is likely the real issue.
If your server crashes at the same time every day, it can be a memory leak in a script.
If your server rubberbands under load, read /blog/fivem-server-lag-and-rubberbanding-fix.
5. Matching RAM to hosting
RAM is only useful if you also get consistent CPU access.
Oversold hosting makes people buy bigger and bigger plans without fixing the real issue.
If you want to compare stable EU hosting for FiveM, see /fivem-hosting.
RAM by player count and resource load
FiveM eats RAM faster than RAM-naive guides claim, because frameworks like ESX and QBCore plus 100+ resources hold a lot of long-lived state.
| Players | Resources | RAM (server) | Notes |
|---|---|---|---|
| 1-8 (testing) | 30 base + 10 custom | 4 GB | comfortable |
| 16-32 RP | 30 base + 60 custom | 6-8 GB | sweet spot |
| 32-48 RP | 30 + 100+ custom | 12-16 GB | needs txAdmin perf graph |
| 48-64 RP | 30 + 150+ custom | 16-24 GB | tighten resources first |
| 64+ heavy | 200+ custom | 32 GB | rare and risky |
CPU usually fails before RAM does. If your txAdmin graph shows tick times rising before RAM hits cap, your resources are heavier than your CPU; adding RAM does nothing.
What actually consumes RAM
| Component | Idle | Per player | Notes |
|---|---|---|---|
| fxserver core | 1.0 GB | +5-10 MB | base process |
| ESX legacy | 200 MB | +20 MB | legacy is heavier than new |
| QBCore | 250 MB | +25 MB | similar story |
| oxmysql + cache | 100 MB | +5 MB | per query bursts |
| 100+ scripts | 1-3 GB | +20-50 MB | huge variance |
| MariaDB | 300 MB | n/a | grows with persistence load |
A vanilla qb-core + 30 custom scripts at 32 players sits around 5-7 GB total RAM use, of which fxserver itself is ~3 GB.
Diagnostic commands
txAdmin > Diagnostics > Performance: shows tick budget %
console: profiler record 100; profiler view
console: resmon (in-game F8)
If profiler shows one resource over 1.5 ms idle, that's RAM you can free by fixing the script (Wait(0) loops are the usual culprit).
What to check before buying more RAM
- Sort resmon by CPU msec; fix the top 3 offenders (or remove them).
- Run
profiler viewand look for hotspots. - Check MariaDB
slow_query_log; one missing index can balloon RAM. - Disable plugins you "might use later" but never invoke.
After all four, most servers find they have plenty of RAM and were CPU-bound the whole time.
