The Isle Server Requirements: RAM, CPU and Player Slots Explained
There is no official RAM figure for a The Isle: Evrima server, and an empty server tells you almost nothing about peak time. Here is how to turn your player count and play style into the right RAM, CPU, slot cap, storage and bandwidth, so you neither overpay nor rent a plan that falls over once your community logs in.
Use 8 GB as the comfortable starting point for up to about 20 players, then step to 10 GB+, 12-16 GB+ and 16 GB+ as your real peak grows. Idle memory looks low; live memory does not.
Up to 30 players, aim at 3.0 GHz and 2 cores minimum. From 30-80 players, 3.5 GHz+ and 4 cores is the safer target, with 4.0 GHz+ for 80+ players.
MaxPlayerCount defaults to 100, but that is only a cap. Buy for peak concurrent players, use a queue for overflow, and check the RAM behind any slot-priced plan.
Put the server on SSD or NVMe, allow at least 20 GB and preferably about 40 GB free for patches, logs and backups. For UK groups, server location matters more than raw bandwidth totals.
Why there is no single official requirement
The awkward part with The Isle: Evrima is that there is no developer-published server RAM figure you can treat as a fixed answer. That matters because Evrima on Gateway, built on Unreal Engine 5.6, is much heavier on the server than Legacy. Old advice based on light private Legacy setups often under-sizes modern Evrima servers.
An empty-server test is useful for one thing only: it shows the base overhead of a clean boot. One host reported a fresh 30-slot server with nobody online at about 1.3 GB. That does not mean a live 30-player server only needs a bit more than that. It just means the server has loaded the world and its idle systems, before it has to track lots of connected players, AI, corpse state and hours of accumulated world activity.
- What an empty test tells you: the server starts, the map loads, and the idle footprint is modest.
- What it does not tell you: what happens at peak time, after several hours of uptime, during migrations, or when players spread right across Gateway.
The broad rules in our game server hardware guide still apply, but The Isle is more sensitive than most to live simulation load. That is why the right way to size it is to work backwards from community size and play style, not forwards from an idle memory reading.
What actually loads a The Isle server
If you want to size the server properly, think in terms of what the process is simulating every second. The load is not just “players online”; it is players plus all the AI and world state their presence causes the server to maintain.
Look for how each factor leans on a different resource.
| What changes | Main CPU thread | RAM | Network | Disk |
|---|---|---|---|---|
| More players online | Yes | Partly | Yes | – |
| Players spread across Gateway | Yes | Yes | Partly | – |
| Higher AIDensity | Yes | Yes | – | – |
| Migrations | Partly | – | Partly | – |
| Persistent corpses | – | Yes | – | – |
| Long uptime | – | Yes | – | – |
| Patches, logs and backups | – | – | – | Yes |
Players
Every connected player adds movement, status, interactions and state that has to be updated and sent to others. That mostly hits the main thread CPU and bandwidth, with some RAM for keeping each player’s state in memory. Higher player counts also make spikes more likely: fights, group movement and sudden concentration at one point on the map are harder than a handful of quiet players spread over time.
AI groups around players
AI is the biggest consumer of both CPU and RAM. Each creature needs behaviour, pathfinding and physics, so the server is doing real simulation work, not just storing a number in a database. The expensive part is that AI groups spawn around players. If your population spreads out across Gateway, the server tends to support more separate pockets of AI activity at once. If players cluster together, fewer separate pockets of AI are needed, though a crowded fight is still heavy work for that one moment.
The biggest sizing dial is AIDensity. Its default is 1, and the usable range is 0 to 2.
[/Script/TheIsle.TIGameSession] AIDensity=1
Higher values ask the server to maintain more AI presence, which means more main-thread CPU time and more RAM. Lower values cut that cost, but the trade-off for players is a sparser world. For planning purposes, treat 1 as the normal ceiling once you get into larger populations: host guidance is to keep it at 1 or lower on servers with 50+ players, and at 100+ slots to reduce it to 0.5 or lower.
Migrations, corpses and uptime
Migrations pull movement and population into more active patterns. That can push up CPU and network load because more things are happening at once and more state needs to be exchanged. Persistent corpses add more world state for the server to track over the life of the session, which increases memory pressure. Uptime matters for the same reason: memory accumulates over time, which is why scheduled restarts (every 6 to 12 hours) are part of sizing, not an afterthought.
How much RAM by community size
The most practical way to buy RAM for Evrima is by peak concurrent players, then adjust within that band for AI density, how spread out your players tend to be, and how often you are willing to restart.
Use this as the working sizing table.
| Community | Players | Practical RAM | What matters most |
|---|---|---|---|
| Small private group | Up to about 20 | 6-8 GB, with 8 GB the comfortable start | AIDensity, how far people roam from each other, and restart cadence |
| Growing community | 20-50 | 10 GB+ | Keeping AI sensible, avoiding long uptime, and sizing for real peaks rather than advertised slots |
| Busy public server | 50-100 | 12-16 GB+ | Conservative AI, restarts nearer 6 hours, and tight control of peak concurrency |
| 100+ project | 100+ | 16 GB+ with careful tuning | Reduced AI density, very strong single-thread CPU, and acceptance that this is the unstable end |
If you are choosing inside a range, ask three questions. First, will players usually travel as one or two groups, or scatter all over Gateway? Spread-out players tend to multiply AI work and memory use. Second, will you leave the server up for long stretches? More uptime means more accumulated memory. Third, are you keeping AIDensity conservative, or expecting a rich AI population? That single setting changes the amount of work the server creates for itself.
That is why small-group advice ranges from 6 GB to 8 GB. A short-session private server with restrained AI can live at the lower end; 8 GB is the safer buy if people roam, if you want fewer restarts, or if you simply do not want to run with little headroom. For the same reason, 10 GB+ is where regular community play starts to feel more realistic than bargain entry plans.
If RAM regularly sits above 80% after sensible tuning, add memory. That works because it gives the server more heap headroom for live entities and accumulated state instead of pushing towards out-of-memory conditions. The player-side trade-off is just cost, and the sign it helped is straightforward: fewer late-session disconnects, fewer crashes, and stable usage that no longer creeps into the danger zone. If you are comparing current package sizes and caps, see our The Isle server hosting comparison.
CPU: buy clock speed before extra cores
Evrima’s simulation runs mostly on one dominant main thread. Extra cores still help with saving, networking and asset streaming, but they do not remove a single-thread bottleneck. In plain terms: one fast core does more for peak stability than several slower ones.
| Peak concurrent players | CPU target | Why this matters |
|---|---|---|
| Up to 30 | 3.0 GHz, 2 cores minimum | Enough for small private use if AI and uptime stay modest |
| 30-80 | 3.5 GHz+, 4 cores | Stronger main thread plus spare cores for support tasks during busier periods |
| 80+ | 4.0 GHz+, 4-6 cores | Main-thread speed becomes critical; extra cores help around the edges, not at the centre |
Several hosts treat 4 cores or 4 vCPU as the minimum for a stable server. That is a sensible floor, but it is not the whole story. If those cores are slow, the main simulation thread can still saturate and produce lag even while the panel claims there is spare total CPU left.
That panel behaviour catches a lot of people out. If one vCPU is pinned but the others are quieter, the average can still look healthy. The result in-game is desync, delayed hit registration or rubber-banding at busy times, even though RAM looks fine and the dashboard does not appear full. A faster CPU helps because it shortens the time the main thread needs to process each update cycle. More slow cores do not fix that.
The trade-off is simple. Paying for higher clocks usually costs more, while lowering AI density or slot cap protects performance but changes the player experience. You can tell a CPU-focused fix worked when the server stays smooth at the same RAM usage and the same restart schedule, but peak-time desync falls away.
How many slots should you pay for?
MaxPlayerCount defaults to 100, and community experience generally treats going above 100 as unstable or not recommended. The important point is that the slot cap is only a ceiling. It does not reserve RAM. It does not reserve CPU. A 100-slot configuration on hardware sized for 30 players can sit quietly overnight and then fall over when peak time arrives.
Most of the relevant fields live in Game.ini under [/Script/TheIsle.TIGameSession]; for the wider list, see The Isle server settings explained.
TheIsle/Saved/Config/LinuxServer/Game.iniTheIsle/Saved/Config/WindowsServer/Game.ini
[/Script/TheIsle.TIGameSession] MaxPlayerCount=100 bQueueEnabled=true QueuePort=10000
Buy slots for your peak concurrent players, not your community’s total membership and not the biggest number a host can print on a plan card. If your server is smooth at capacity and the queue is active, that is often a sign you sized it correctly. Raising the cap just because the queue exists is only sensible if RAM and main-thread headroom are both still healthy.
The queue is a better answer than an inflated cap because it controls concurrency without forcing you to pay for a worst-case crowd all day. VIP bypass helps you protect access for admins, staff or supporters without adding permanent extra slots. The trade-off for players is waiting, but the benefit is that the people who do get in are far less likely to land on a server that turns unplayable at peak.
Be especially careful with slot-priced plans. Some include a fixed RAM allowance, such as “up to 5 GB included”, and sell memory upgrades from 8 GB to 32 GB as paid extras. A 10-slot plan with 5 GB is below what even a small Evrima group should run. For Evrima, check the RAM and CPU behind the slot count before you look at the headline number.
Storage and bandwidth
Storage is not the expensive part of The Isle hosting, but it still needs a bit of thought. The install is roughly 8-15 GB depending on build, and it grows as content patches arrive. Buy the server on SSD or NVMe, not hard-disk storage.
- Disk space: 20 GB is the minimum worth considering, while about 40 GB free is the practical target for patches, logs and backups. Some host guides suggest 50 GB, which is simply extra breathing room.
- Save data: player progress is stored per SteamID64 under
TheIsle/Saved/Databases/, and that folder stays small, usually only a few megabytes even on a busy server. - Backups: keep copies of
DatabasesandGame.ini. Those are the pieces that matter most when you need to recover quickly. - Logs: busy servers can grow logs far more than they grow the actual player database.
Fast storage helps because server updates, asset streaming and save-related tasks all involve disk I/O. The trade-off is not about player-facing features; it is about avoiding cheap slow storage that drags on operational tasks. You do not need a huge quota, but you do want SSD-class performance and enough room that patches and backups are not squeezing the drive.
Bandwidth is more modest than many expect. A rough estimate is about 50-150 KB/s per player. That works out at about 2-3 Mbps sustained for 20 players, 5-7 Mbps for 50 players and 10-15 Mbps for 100 players if you self-host, with upload being the important side. If you are renting, throughput limits are rarely the first problem; latency and location matter more.
For UK groups, choose London or a nearby EU location. Constant high ping is usually a distance problem, not a problem solved by buying more bandwidth. The sign you picked the right location is that players in your region report consistently lower and steadier ping without you having to change the hardware at all.
Can you self-host on your own PC?
Yes, but self-hosting on the same machine you play on is much less forgiving with Evrima than it sounds. The dedicated server is a separate free Steam app, 412680, installed from the evrima beta branch with SteamCMD using anonymous login. Native Linux and Windows server builds exist, and players still need their own game copy, app 376210.
The catch is that your gaming PC now has to satisfy the game client and the dedicated server at the same time. The client minimum is a quad-core 3.0 GHz CPU, 8 GB RAM, 25 GB storage and a dedicated GPU such as a GTX 960 or R9 280X. The client recommendation rises to a quad-core 3.4 GHz CPU, 16 GB RAM and a GTX 1070. The server then competes with the game for memory and, more importantly, for the fastest CPU core.
That is why a PC that only just meets the game’s own spec is a poor combined host. You can run a very small private session this way, but as soon as AI load and player count rise, the main-thread fight between client and server becomes the limiting factor.
You also need enough upload bandwidth for your expected peak, the machine must stay on whenever the server should exist, and you must forward the correct ports.
UDP 7777-7779 TCP 10000 TCP 8888
Those cover the game, the queue and RCON. If you want the wider pros, cons and setup considerations, read our guide to self-hosting a game server. For most public or always-on communities, renting wins simply because the hardware, network and uptime are separated from your play PC.
Reading the signs after launch
Once the server is live, your job is to work out whether you need tuning, more RAM, a faster CPU or simply a more realistic slot cap. Start with symptoms, make one change at a time, and use the result to decide what the real bottleneck is. For exact tuning steps, especially around AI and related settings, see how to reduce lag on a The Isle server.
| Symptom | Likely cause | First fix |
|---|---|---|
| RAM regularly above 80% after tuning | Not enough memory for current player spread, AI load or uptime | Add RAM, or shorten restarts towards the 6-hour end if the server is busy |
| Desync at peak while total CPU still looks spare | Main thread saturated on one core | Reduce AI or peak concurrency first, then move to a higher-clock CPU if needed |
| Smooth after restart, then worse later | Accumulated memory and world state over uptime | Restart more often and review the AI-related load that builds across a session |
Many players hit UNetConnection::Tick: Connection TIMED OUT at once | Server overload or crash, often tied to memory exhaustion | Check for out-of-memory signs, then either add RAM or reduce the live load |
| High ping for everyone, all the time | Wrong region rather than weak hardware | Move the server closer to the player base, such as London or nearby EU for UK groups |
| Queue always full but the server itself stays smooth | Demand is above cap, not a performance collapse | Raise the cap slowly only if RAM and CPU headroom remain healthy at the old limit |
Each of those fixes works for a different reason. More RAM prevents the process running out of working space. Lower AI or fewer concurrent players reduce how many live entities the main thread has to simulate. Shorter restarts clear accumulated memory. Moving region cuts travel time for packets. The best sign that you picked the right fix is that the symptom disappears without a different one replacing it.
What it costs and which plan size fits you
The cheap end of the market can look attractive for The Isle, but this is where people get caught by slot-first pricing. Most entry plans still sit below the 8 GB that suits even a small group, and some slot-billed options hide a low RAM allowance behind the slot number. The regular monthly prices below are entry plans from our comparison data.
| Entry plan | Monthly price |
|---|---|
| 6 GB plan | £6.76/month ($8.99) |
| 10 slots with up to 5 GB RAM included | £9.99/month ($13.29) |
| 10 slots | £10.25/month ($13.63) |
| 16 GB / 125 slots | £11.28/month ($15.00) |
| 6 GB plan | £12.02/month ($15.99) |
| 7 GB plan | £14.17/month ($18.84) |
| 11 GB plan | £15.03/month ($19.99) |
Conversion used: £1 = $1.33
Note the spread: the 16 GB plan costs £11.28 a month while a 7 GB plan costs £14.17, so price and memory do not move together. Compare the RAM figure first, then the price. The wider lesson is that a low monthly price often buys less RAM than Evrima really wants. A small private group can sometimes get by on 6 GB, but 8 GB is the comfortable start. That means many bargain entry plans are only good value if you are sure your sessions are light, short and conservative on AI.
| Your group | RAM to target | CPU priority | Slot cap |
|---|---|---|---|
| Private friend group with up to about 20 peak | 8 GB start, 6 GB only if you are keeping load modest | 3.0 GHz minimum, favour higher clocks if plans are close in price | Your real peak plus a few spare places, not 100 |
| Regular community in the 20-50 range | 10 GB+ | 3.5 GHz+ and 4 cores | Cap around your normal peak and let the queue absorb overflow |
| Busy public server in the 50-100 range | 12-16 GB+ | Strong single-thread speed first, with 4 cores as the baseline | Only push towards 100 if AI is conservative and restarts are disciplined |
| 100+ project | 16 GB+ with careful tuning | 4.0 GHz+ and 4-6 cores | 100 remains the sensible ceiling; above 100 is not recommended |
Compare RAM limits, CPU allocation and slot pricing before you rent. For Evrima, the best buy is usually the plan with enough memory and a faster core, not the biggest slot number on the page.
Compare the best The Isle server hostsThe Isle server FAQ
Is 8 GB of RAM enough for a The Isle server?
Usually yes for a small private group, and it is the comfortable starting point for up to about 20 players. It is a much safer choice than plans sitting at 5-7 GB because idle memory is misleading and live memory rises with players, AI, corpses and uptime. If the server regularly runs above 80% RAM after sensible tuning, move up.
How many players can a The Isle server handle?
The default MaxPlayerCount is 100, but that is only a cap, not a guarantee of performance. Practical capacity depends on AI density, player spread across Gateway, restart schedule and, above all, CPU speed. Community experience also treats going above 100 as unstable or not recommended.
Does The Isle server need a fast CPU or more cores?
A fast CPU matters more because Evrima runs most of its simulation on one dominant main thread. Extra cores still help with networking, saving and other support work, but they do not solve a saturated main thread. That is why higher clock speed beats piling up slower cores.
How much storage does a The Isle Evrima server need?
The install is roughly 8-15 GB depending on build, but planning for about 40 GB free is the sensible target because patches, logs and backups need room. 20 GB is the minimum worth considering. Use SSD or NVMe, and back up Databases plus Game.ini.
Can I host a The Isle server on the PC I play on?
Yes, for a very small and lightly used private server, but the server and the client then compete for RAM and for the fastest CPU core. That makes peak-time performance much worse than the same hardware would suggest on paper. For public, always-on or busier community use, a separate rented server is usually the cleaner option.
More The Isle server guides
Compare hosts, tune your settings or fix lag on a live server.
Evrima updates can change how heavy the server is. If your server behaves differently after a patch, recheck RAM use at peak before you upgrade, and follow your host’s panel where its labels differ from this guide.
